Возвращение «потока» обратно в рабочий процесс с лимитами WIP
Лимита работы в процессе выполнения не предназначены для фактического лимита вашего прогресса. На самом деле, совершенно наоборот.
Каковы лимиты WIP?
В гибкой Agile разработке пределы незавершенного производства (WIP) задают максимальный объем работы, который может существовать в каждом статусе рабочего процесса. Ограничение объема выполняемой работы облегчает выявление неэффективности в рабочем процессе команды. Узкие места в конвеере предоставления команды хорошо видны до того, как ситуация станет ужасной.
ВИДЕО
Почему лимиты WIP важны?
Итак, теперь вы думаете: «Скажи мне больше!» (Ну, я надеюсь, что вы.)
Лимиты WIP повышают пропускную способность и сокращают объем работы, «почти выполненной», заставляя группу сосредоточиться на меньшем наборе задач. На фундаментальном уровне лимиты WIP поощряют культуру «сделано». Более того, лимиты WIP делают блокировщики и узкие места видимыми. Команды могут копаться в блокирующих задачах, чтобы их понять, реализовать и решить, когда есть четкий индикатор того, что существующая работа вызывает узкое место. Как только блокировки устранены, работа в команде снова возобнавляется. Эти преимущества гарантируют, что прирост стоимости будет предоставлен клиентам быстрее, что делает WIP-лимиты ценным инструментом в Agile разработке.
ТВИИТ: Кроме того, многозадачность обманчиво трудоемка.
Во время разработки легко подумать: «О, я остановлюсь на этой одной задаче, а я начну работать на другой». Открытые две задачи означают переключение контекста между двумя разными вещами или передачу работы между товарищами по команде. Разрушение одной задачи и решение другой не является бесплатным - это требует времени и снижает концентрацию внимания. Почти всегда лучше проработать исходную задачу, чем начинать - а не завершать - новую работу. Другими словами, лимиты WIP не позволяют нам препятствовать нашему собственному потоку.
Наконец, лимиты WIP указывают на области хронического бездействия или перегрузки. Они помогают команде увидеть неэффективность всего процесса, а не только конкретной области, в которой они работают.
PRO TIP:
Для команд, плохо знакомых с лимитами WIP, они будут чувствовать себя неловко. Потратьте время, чтобы обсудить их в первых нескольких итерациях. Понять, когда и почему команда превысила лимиты WIP. Не поддавайтесь искушению вначале произвольно настроить их. Если брешь становится постоянной, это признак того, что либо лимиты WIP слишком ограничены, либо процесс команды неэффективен.
Использование лимитов WIP для Agile команд
Теперь, когда вы проданы по их стоимости, давайте приступим к медным тикам.
При внедрении нового рабочего процесса примите групповое решение, чтобы определить лимит WIP для каждого статуса. Мы рекомендуем устанавливать лимиты WIP после отслеживания среднего количества рабочих элементов в каждом статусе за несколько спринтов.
Ниже приведен пример Agile доски с лимитами WIP, используемой типичной командой разработчиков программного обеспечения.
Выше был установлен лимит WIP при проверке кода. Поскольку столбец превышает свой предел, фон стал красным.
Поскольку после того, как задача будет решена, ничего не остается делать, там нет необходимости в лимите WIP. На приведенной выше доске «Готово для разработки» означает, что история полностью проверена владельцем продукта и командой. Команда разработчиков переводит работу из состояния «готово для разработки» в состояние «в процессе», когда они начинают работу над заданиями. Рекомендуется сохранять достаточное количество работы в статусе «готово для разработки», чтобы каждый член команды разработчиков оставался полностью задействованным. Сохраняя только достаточное количество историй в состоянии «готово к разработке», владелец продукта не слишком далеко опережает игру, когда речь идет об уточнении требований, и программа становится более отзывчивой к изменениям.
Списки статусов «в процессе» работают в активной разработке. Цель лимитов WIP в этом случае состоит в том, чтобы гарантировать, что у каждого есть работа, но никто не занимается многозадачностью. На приведенной выше доске лимит на количество элементов в процессе составляет 4, и в настоящее время в этом состоянии находятся 3 элемента. Это говорит команде, что у них есть возможность взять на себя больше работы. В качестве лучшей практики некоторые команды устанавливают максимальный лимит WIP ниже количества членов команды. Идея состоит в том, чтобы приготовить в комнате для хорошей Agile практики. Если разработчик заканчивает работу над элементом, но команда уже достигла лимита WIP, он знает, что пришло время отказаться от нескольких обзоров кода или присоединиться другому разработчику для некоторого парного программирования.
Статус «ревью кода» указывает на истории, которые были полностью написаны, но должны быть просмотрены перед слиянием с базой кода. Своевременные ревью кода - это лучшая практика, которая устанавливает качество, быстрее выводит на рынок новые инновации, облегчает слияния за счет сокращения числа открытых филиалов и распространения знаний среди команды инженеров. Элементы в этом состоянии должны действовать срочно по нескольким причинам:
- Код не гниет, когда члены команды проверяют новый код
- Разработчик не теряет контекста, который он получил при написании исходного кода
- Функция может быть объединена с основной ветвью для релиза
Лимиты WIP гарантируют, что не пересмотренный код не накапливается в куче.
Обратите внимание, что на Agile доске выше, у команды слишком много обзоров кода, поэтому столбец стал красным, чтобы указать на это.
АНТИ-ОБРАЗЦЫ, ДЛЯ НАБЛЮДЕНИЯ:
- Лимиты WIP поднимаются по мере необходимости, поэтому команда больше их не поражает. («Потолок долга», кто-нибудь?)
- У каждого есть большая «фоновая задача» на тарелке, чтобы маскировать времена, когда они в противном случае были бы бездействующими.
- Члены команды сидят без дела в ожидании дополнительной работы, а не в ожидании разборки в узких местах.
- Тратить больше человеко-часов на постоянные узкие места предпочтительнее, чем на усовершенствование инженерных практик или командных процессов.
4 цели для Agile команд, использующих лимиты WIP
Как и любой новый вид деятельности, ограничения WIP могут сначала показаться неудобными. Цель здесь состоит в том, чтобы оптимизировать команду в среднесрочной перспективе, и краткосрочные неудобства на самом деле хорошая вещь. Это заставляет команду чувствовать некоторые болевые точки в их процессе. После того, как команда использует свои лимиты WIP в течение нескольких недель, внесите необходимые коррективы. Не поддавайтесь искушению повысить лимит WIP только потому, что команда продолжает его соблюдать. Воспользуйтесь этой возможностью, чтобы увеличить потенциал - в идеале, обучая команду и предоставляя каждому участнику новые навыки или делая некоторые аспекты процесса разработки более эффективными.
Цель 1: Последовательно измеряйте отдельные задачи. Разбивая требования и истории пользователей, важно, чтобы отдельные задачи выполнялись не более 16 часов. Это повышает способность команды уверенно оценивать и помогает избежать узких мест. Ничто не замедляет работу команды и не усугубляет лимитов WIP, как большой рабочий элемент, замедляющий процесс разработки.
PRO TIP:
Когда для команды работают лимиты работы в процессе выполнения, время цикла задачи будет уменьшаться. Время цикла - это количество времени, необходимое для завершения задачи. Посетите нашу страницу по Agile метрикам, чтобы узнать больше.
Цель 2: Сопоставляйте лимиты WIP с навыками команды. В приведенном выше примере предполагается, что члены команды имеют схожие наборы навыков. Если в вашей команде есть специалисты, лимиты работы в процессе выполнения могут отличаться в зависимости от специалиста. Создавайте статус, специфичный для работы специалиста. Если в этом статусе возникают узкие места, используйте возможность обучить других членов команды, чтобы добавить дополнительные возможности для наборов навыков специалиста и увеличить поток по всей команде.
Цель 3: Уменьшайте безделие. Если у члена команды есть время простоя, попросите его помочь вышестоящему или последующему члену команды. Они будут способствовать общей продуктивности команды и чему-то научатся!
Цель 4: Защищайте устойчивую инженерную культуру. Лимиты работы в процессе выполнения не означают, что разработчики должны торопиться с работой, чтобы избежать перегрузки в конкретном статусе. Они предназначены для поддержки надежных практик Agile разработки, которые защищают качество продукта и работоспособность базы кода.
По материалам Agile Coach "WIP limits"