При внедрении SCRUM часто возникает ситуация, когда в процессе спринта прилетает срочная задача. Например, критичный баг у клиента или на проде, задача от «большого начальника», который не привык ждать, и т.п. Возникает вопрос: «что делать и как с этим жить?».
Стандартно бывают несколько способов решить проблему:
- Если проект большой и над ним работает несколько продуктовых команд, то выделяют отдельную пожарную команду на исправление критичных багов.
- Всем прибегающим отказываем, мотивируя тем, что scope спринта не меняется и все будет, но в следующем спринте.
- Берем задачу в работу, потом в конце спринта констатируем, что вот опять не успели так как нежданчик прилетел. А если нежданчиков много, то можем и в принципе все планы не выполнить.
Разберем каждый из вариантов:
Пожарная команда — это наказание, быть в ней скучно. Чем ей заниматься, если багов не прилетает тоже непонятно. Могут, конечно, править старые баги или техническими долгами заниматься, но это все демотивирует разработчиков.
Не меняем scope спринта. Начнем с того, что всем не откажешь. Всегда есть человек с нужным административным ресурсом, которому отказать не удастся. Но даже если отказывать умеем, то что делать с лежащим продом? Обычно он не готов ждать до следующего спринта, чинить надо здесь и сейчас. Поэтому такой вариант ведет к бесконечным конфликтам с контрагентами, эскалациям, а делать все равно придется.
Берем задачу в работу, а потом жалуемся, что опять не успели и расстраиваемся по этому поводу и оправдываемся перед Product Owner’ом.
Как ни странно самый правильный вариант — третий, только расстраиваться не надо 🙂
Если ситуация разовая, то тут и делать ничего не стоит. Один раз цели спринта не выполнили, на ретроспективе обсудили, что был форсмажор и поехали дальше.
Если ситуация повторяемая, а в случае реально используемого продукта поток багов от клиентов — это реальность, то алгоритм действия такой. В условный первый спринт берем задачи на некоторое количество story points. Пусть будет 100. По результату спринта, с учетом всех срочных задач, неправильной оценки и прочего оказывается, что сделали, например, 80. Значит в следующий спринт набираем задач на 80. Таким образом, в результате мы получаем, что Capacity команды — это число story point’ов, которые команда может сделать с учетом всех нежданчиков, заранее неизвестных багов, форсмажоров и т.п. Эта та реальность, с которой надо просто смириться. При достаточно крупном и активно используемом продукте, число внезапных проблем более-менее постоянно, оно может меняться в ту или иную сторону, но резких скачков не должно быть.
Что делать, если внезапных задач столько, что вы вообще ничего не успеваете реальная capacity падает до нуля, т.е. вы не сделали ни одной задачи, из взятых в спринт. В этом случае нужно садиться и думать, либо вы не умеете декомпозировать story, либо не умеете оценивать, либо у вас столько проблем, что вам не до разработки нового. Этот факт надо принять и работать над его устранением.
Все новости сайта в телеграм канале: @CTO_in_Action
по RSS
bykps9