Лайза Криспин - Agile-тестирование. Обучающий курс для всей команды

• Название: Agile-тестирование. Обучающий курс для всей команды
• Автор: Лайза Криспин
• Жанр: Управление, подбор персонала
• Год: 2019
• ISBN: 978-5-00117-880-4

Книга ведущих мировых специалистов подробно рассказывает о процессе тестирования с позиции Agile. Вы узнаете о роли обучения и корпоративной культуры, подборе правильных людей, особенностях технической подготовки, моделях планирования и автоматизации тестирования. Подробное практическое руководство будет интересно всем специалистам IT-отрасли, желающим перейти на гибкий метод управления и улучшить показатели.

---

Командам необходимо обозначить опасность неразумных шагов, чтобы руководители компании знали о рисках и последствиях. Иногда нужно сбавить обороты, чтобы заняться техническими недоработками, или изучить новые концепции, или применить новые идеи. В своих презентациях Джанет использует рисунок с застрявшими в пробке суперкарами. Он показывает, как добавление новых элементов, не согласующихся с общей инфраструктурой, может парализовать работу. Зачем добавлять что-то, если система не будет работать, как ожидалось? Когда у вас накапливается слишком много технических недоработок, команда застревает.

НЕ ЖАЛЕЙТЕ ВРЕМЕНИ

Чтобы представить клиентам полезный софт, необходимо подойти к задаче творчески. Людям нужно время, чтобы все обдумать и применить свое мастерство. Мы также должны постоянно осваивать новые технические навыки, изучать новые инструменты. Это помогает проводить небольшие эксперименты, которые могут быть полезны при решении различных задач.

В статье «Медленные идеи» (Gawande, 2013) Атул Гаванде объяснил, почему некоторые инновации, такие как хирургическая анестезия, внедряются быстро, а другим, например антисептикам, требуются годы (а то и вообще этого не происходит). Вывод: изменения происходят только путем обучения, практики и личной заинтересованности. В программах, которые анализировал Гаванде, люди обучались лучше всего, когда сами выполняли новые действия, описывая их своими словами, под наблюдением преподавателя. Может показаться, что дешевле и быстрее нанять тренера, который покажет, как нужно делать, или заставить людей посмотреть обучающее видео, но практический подход обеспечивает реальные стабильные изменения.

В сфере программного обеспечения (как и во многих других) люди порой забывают, что для овладения новыми навыками требуется время и практика. Они часто отказываются от тренера, который бы обучал и направлял сотрудников.

Тратьте время на то, что нужно

Дэвид Эванс, Agile-тренер по качеству, поделился метафорой, к которой прибегает, когда объясняет, что необходимо тратить время на то, что действительно нужно.

Иногда приходится сталкиваться с сопротивлением со стороны менеджмента, когда я предлагаю потратить время на совместное описание приемочного тестирования, прежде чем внедрять то или иное требование. Обычный аргумент: если команда потратит больше времени на приемочные тесты, это замедлит темпы разработки. В некотором смысле, конечно, замедлит, но ровно настолько, насколько замедляет движение автобус, чтобы забрать пассажиров с остановки. Попытки оптимизировать скорость автобуса ни к чему не ведут, если не согласуются с целью усовершенствовать работу общественного транспорта. Представьте, если бы водитель для улучшения показателей предложил не останавливаться для пожилых пассажиров, поскольку они медленнее заходят в двери. Если бы автобус вовсе не останавливался и не брал пассажиров, он бы двигался быстрее. По скоростному шоссе он мог бы даже вернуться в парк!

Это та же ошибочная логика, согласно которой работа над тестами замедляет темпы разработки. Это хорошо иллюстрирует утверждение Кента Бека (Beck, 2002): «Код, который не прошел тестирование, не работает. Это, кажется, самое благоразумное утверждение». Если создание приемочных тестов перед тем, как приступить к разработке кода, что-то и замедляет, то лишь нашу работу над кодом, который не будет функционировать.

Компании, работающие с концепциями бережливого производства, научили нас, что уважение способности каждого сотрудника вкладывать идеи или непрерывно работать над улучшением качества приводит к созданию новых продуктов, которые нравятся клиентам. Команды, имеющие время и поддержку на обучение и эксперименты, справляются с работой куда лучше. Во второй части «Обучение для улучшения тестирования» мы поговорим о некоторых достойных, на наш взгляд, методах.

Гойко Аджич (Adzic, 2013) заметил, что отличный результат получается, когда:

• люди знают, зачем они делают свою работу;

• организации сосредоточены на результате и влиянии, а не на отдельных элементах;

• команды решают, что делать дальше, основываясь на актуальной обратной связи от пользователей;

• никому не наплевать.

Некоторые компании попробовали разгрузить своих сотрудников, чтобы дать им время на обучение, позволяя посвящать свободные рабочие часы личным проектам или собственному профессиональному росту. Лайза работала с командами, практикующими этот метод, и они демонстрировали хорошие результаты, поддерживая низкий уровень технических недоработок и сохраняя объемы производства. Однако важно понимать принципы, стоящие за эффективным использованием и возможностями, иначе команде придется втискивать еще больше работы в жесткие сроки.

Загрузка производственных мощностей

Алексей Жеглов, консультант по бережливому производству и Kanban для организаций, использующих умственный труд, объясняет теорию использования производственных мощностей и учит, как избежать потери 20 % времени. Мы приводим часть его статьи.

Главная причина потери 20 % времени в том, что при неполной загруженности мощности используются на 80 %, а не на 100 %. Подумайте о компании, производящей ПО, как о системе, которая преобразует запрос на элемент в разработку этого элемента. Таким образом, мы можем смоделировать производство, используя теорию очередей.

Теория

Если запросы прибывают быстрее, чем система успевает их обрабатывать, они ставятся в очередь. Когда скорость поступления снижается, очередь уменьшается. Поскольку поступление новых запросов и их обработка происходят непоследовательно, длина очереди меняется.

J-кривая мощностей

Средний размер очереди остается на низком уровне, в то время как эффективное использование поднимается до 0,8, а потом резко возрастает и увеличивается до бесконечности. Это легко понять, представив процессор компьютера: когда мощность на низком уровне, он быстро реагирует на запросы, а когда фоновые задачи доводят ее до 100 %, компьютер начинает работать слишком медленно, чтобы отвечать на каждый клик.

Метод

Именно неполная загрузка сотрудников позволяет системе вовремя отвечать на запросы. Вот несколько практических советов, чего делать не следует.

• Калькуляция издержек (время инженера стоит Х, но компания не может себе этого позволить). Экономические выгоды получаются при сокращении затрат из-за задержек.

• Создание проектной системы, чтобы люди могли в свои 20 % времени заниматься другими текущими проектами.

• Отслеживание 20 % времени путем заполнения ведомостей учета.

• Использование нововведений для того, чтобы занять 20 % времени. Не проблема, если только 20 % проектов выливаются в продукты. Проблема, если ваша компания не может внедрять новые технологии в основное время работы!

• Попытка вдохновить на творчество за счет этих 20 % времени. Утверждая, что вы раскроете творческий потенциал за 20 % времени, подумайте, почему вы до сих пор его не раскрыли в основное время.

• Выделять 20 % свободного времени каждую неделю по пятницам.

Это то, чего не нужно делать. А что же надо?

Окей, как насчет того, чтобы сделать все правильно? Ответим лучшим вопросом, который нам задали во время обсуждений со специалистами: «Если 20 % мощностей заняты задачами, не связанными с запросами в очереди, вы просто снижаете мощность до 80 %, и эти 80 % теперь составляют ваши 100 %, верно?».

Да, «80 – это новые 100». Это утверждение подчеркивает главную проблему, которая подстерегает попытки поддерживать 20 % свободного времени, не понимая сути теории. Вам хочется избежать ловушки снижения мощностей, не застрять в ней и иначе распределить время.

Мощность зависит от двух процессов: входящего (запросы) и сервисного (возможности). На самом деле вы не можете регулировать свои мощности. Они такие, какие есть, потому что процессы такие, а не иные. Однако вы можете поработать над процессами, улучшив возможности разработки софта и начав обрабатывать запросы. Когда у вас это получится, тогда и образуется неполная занятость.

Список литературы к первой части включает источники, из которых вы сможете больше узнать о производственных мощностях и результатах. Важно помнить, что перегрузка мощностей влияет на ход работы, а непосильные задачи на самом деле лишь снижают показатели.

О ВАЖНОСТИ КУЛЬТУРЫ ОБУЧЕНИЯ

Если у вас есть возможность рисковать, и при этом провал не будет стоить слишком дорого, можете учиться на ошибках. Используйте быструю обратную связь, чтобы усовершенствовать ваши тесты для изменения чего-то, что работало «нормально», в то, что будет работать «прекрасно». Если ваша корпоративная культура нетерпима к ошибкам, вряд ли удастся внедрить инновации. Придерживаться одних и тех же процессов, даже если они не работают, всегда безопаснее, так что нет причин что-то менять.