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

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

Dan Radigan Автор: Dan Radigan
Просмотр тем

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

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

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

Надеюсь, что теперь вам захотелось узнать подробнее.

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

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

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

Подсказка

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

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

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

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

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

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

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

В статусе 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 и Scrum