Лайза Криспин - Agile-тестирование. Обучающий курс для всей команды
- Название:Agile-тестирование. Обучающий курс для всей команды
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:2019
- Город:Москва
- ISBN:978-5-00117-880-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Лайза Криспин - Agile-тестирование. Обучающий курс для всей команды краткое содержание
Agile-тестирование. Обучающий курс для всей команды - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Компании, работающие с концепциями бережливого производства, научили нас, что уважение способности каждого сотрудника вкладывать идеи или непрерывно работать над улучшением качества приводит к созданию новых продуктов, которые нравятся клиентам. Команды, имеющие время и поддержку на обучение и эксперименты, справляются с работой куда лучше. Во второй части «Обучение для улучшения тестирования» мы поговорим о некоторых достойных, на наш взгляд, методах.
Гойко Аджич (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 % свободного времени, не понимая сути теории. Вам хочется избежать ловушки снижения мощностей, не застрять в ней и иначе распределить время.
Мощность зависит от двух процессов: входящего (запросы) и сервисного (возможности). На самом деле вы не можете регулировать свои мощности. Они такие, какие есть, потому что процессы такие, а не иные. Однако вы можете поработать над процессами, улучшив возможности разработки софта и начав обрабатывать запросы. Когда у вас это получится, тогда и образуется неполная занятость.
Список литературы к первой частивключает источники, из которых вы сможете больше узнать о производственных мощностях и результатах. Важно помнить, что перегрузка мощностей влияет на ход работы, а непосильные задачи на самом деле лишь снижают показатели.
Если у вас есть возможность рисковать, и при этом провал не будет стоить слишком дорого, можете учиться на ошибках. Используйте быструю обратную связь, чтобы усовершенствовать ваши тесты для изменения чего-то, что работало «нормально», в то, что будет работать «прекрасно». Если ваша корпоративная культура нетерпима к ошибкам, вряд ли удастся внедрить инновации. Придерживаться одних и тех же процессов, даже если они не работают, всегда безопаснее, так что нет причин что-то менять.
К счастью, б о льшую часть своей карьеры я работала в эффективных командах, где ценили непрерывное совершенствование. Когда сталкиваюсь с коллективами, где не поощряются вопросы и эксперименты, всегда чувствую себя так, словно врезаюсь в кирпичную стену. В одной команде, с которой я работала некоторое время, Scrum-мастер сказал, что я «тормозила весь коллектив», потому что постоянно задавала вопросы. Руководство давило на него из-за ускорения темпов разработки. Он не желал, чтобы его тормозили, и бесконечно указывал, что за три недели так и не создано никаких условий для тестирования. В той компании работали талантливые люди, но им не позволяли в полной мере проявить себя. Мои попытки стать катализатором перемен провалились, так что я поменяла компанию.
Рассказывая о силе ретроспектив (Rising, 2009), Линда Райзинг отметила, что некоторые руководители, сталкиваясь с такими методами, как парное программирование или ретроспективы, отвечают: «У нас нет времени, чтобы думать». Но если мы верим, что можем улучшить работу, у нас получится. Пусть не всё сразу, пусть не за одну ночь, продвигаясь вперед маленькими шажками, но мы найдем лучшие методы.
Читать дальшеИнтервал:
Закладка: