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

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

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

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

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

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

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

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

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

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

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

Теория

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

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

Метод

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

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