Как снова привести работу в движение с помощью лимитов незавершенной работы

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

Dan Radigan Dan Radigan
Browse topics

Что такое лимиты незавершенной работы?

Лимиты незавершенной работы (WIP) применяются в процессе agile-разработки, чтобы ограничить максимальное количество задач на каждом этапе рабочего процесса. Лимитируя объем незавершенной работы, вы можете обнаружить слабые места в рабочем процессе команды. Благодаря этому вы без труда выявите проблемы в потоке поставки продукта до того, как ситуация усложнится.

Почему лимиты незавершенной работы так важны?

Теперь вам захотелось узнать подробнее (я на это надеюсь).

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

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

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

Подсказка

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

Использование лимитов незавершенной работы в agile-командах

Теперь, когда вы осознали ценность лимитов WIP, можно перейти к сути дела.

При формировании нового рабочего процесса обсудите всей командой, какой лимит WIP установить для каждого статуса. Прежде чем устанавливать лимиты, рекомендуем понаблюдать в течение нескольких спринтов, сколько рабочих задач в среднем находится в каждом статусе. Ниже приведен пример agile-доски с лимитами WIP, которую использует обычная команда разработчиков ПО.

Лимиты WIP | Atlassian — тренер по agile

В примере выше лимит незавершенной работы установлен для столбца Code review (Проверка кода). Этот лимит превышен, поэтому фон столбца окрашен в красный цвет.

Поскольку задачи, перемещенные в столбец Done (Завершено), не требуют дополнительных действий, для него лимит WIP не устанавливается. На доске выше статус Ready for dev (Готово к разработке) получают пользовательские истории, которые были тщательно отобраны владельцем продукта и командой. Когда команда разработчиков приступает к выполнению задач, она переносит задачи из столбца Ready for dev в столбец In progress (В работе). Важно, чтобы в статусе Ready for dev всегда находилось достаточно задач, чтобы участники команды разработчиков были задействованы максимально эффективно. При этом на этапе Ready for dev не должно быть слишком много историй, чтобы владелец продукта не ушел далеко вперед в тот момент, когда появятся новые требования, и чтобы программу было проще адаптировать к изменениям.

В статусе In progress находятся задачи, над которыми идет активная работа. Здесь лимиты WIP нужны, чтобы никто не сидел без работы и чтобы никто не занимался несколькими задачами одновременно. На доске, показанной выше, для задач в статусе In progress установлен лимит в 4 задачи, и в этом статусе в настоящий момент находится 3 задачи. Значит, команда может взяться за дополнительную задачу. В некоторых командах целесообразно выбирать такой лимит незавершенной работы, который был бы меньше числа участников команды. Это поможет подготовиться к внедрению надлежащих agile-методик. Когда разработчик заканчивает работу над задачей и видит, что команда уже достигла лимита WIP, он понимает, что пора выполнить несколько проверок кода или стоит присоединиться к другому разработчику, чтобы заняться программированием в паре.

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

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

Благодаря лимитам незавершенной работы непроверенный код не будет накапливаться бесконечно.

Обратите внимание, что на agile-доске выше у команды скопилось слишком много задач по проверке кода, поэтому столбец окрашен в красный цвет.

Плохие примеры, которые лучше не повторять
  • Лимиты незавершенной работы при необходимости повышаются, чтобы команды в них не упирались («потолок долга»).
  • У всех есть большое «фоновое задание», чтобы скрыть время, которое в противном случае считалось бы простоем.
  • Участники команды сидят без работы в ожидании заданий, вместо того чтобы вместе поработать над проблемными местами.
  • Проблемные моменты решаются за счет увеличения количества человеко-часов, а не совершенствования практики разработки или командных процессов.

4 цели для agile-команд, использующих лимиты незавершенной работы

Как и все новое, лимиты незавершенной работы могут сначала показаться неудобными. В среднесрочной перспективе команда должна найти идеальный баланс, а в краткосрочной такое неудобство даже на руку. Благодаря этому команда может осознать слабые места в рабочем процессе. Поработав с лимитами WIP в течение нескольких недель, команда может при необходимости скорректировать их. Не поддавайтесь соблазну увеличить лимит WIP просто потому, что команда постоянно достигает его. Не упустите возможность повысить производительность — в идеале, через обучение команды и развитие новых наборов навыков у каждого участника команды или через повышение эффективности в каком-то аспекте процесса разработки.

Цель 1. Научиться делить работу на отдельные задачи схожего объема. Вычленяя из общей массы работы требования и пользовательские истории, важно следить, чтобы на выполнение отдельной задачи не уходило больше 16 часов. В итоге команда будет увереннее подходить к оценке сложности работы, и проблемных мест станет меньше. Ничто так не замедляет работу команды и не приближает лимиты WIP, как большая задача, вставшая поперек конвейера.

Подсказка

Если лимиты незавершенной работы выбраны командой правильно, время цикла для задачи снизится. Время цикла — это время, за которое задача выполняется. Дополнительную информацию см. на нашей странице, посвященной agile-метрикам.

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

Цель 3. Сократить простои. Если у какого-либо участника команды появилось свободное от работы время, посоветуйте ему помочь коллеге на других этапах работы. Общая продуктивность команды повысится, а заодно и сотрудник чему-нибудь научится!

Цель 4. Сохранить здоровую культуру разработки. Лимиты незавершенной работы нужны не для того, чтобы разработчики спешили, лишь бы на каком-то этапе не произошла перегрузка. Они нужны, чтобы поддержать устоявшиеся практики agile-разработки, которые обеспечивают неизменное качество продукта и исправность базы кода.

продолжение темы
Kanban vs Scrum