Один из самых популярных вопросов на всех тренингах, вебинарах, конференциях и при личных встречах – это «что делать с незапланированной работой». Представьте себе: мы запланировали работу на 2 недели. Тщательно сбалансировали план, и дали реалистичные (как мы думаем) обещания нашим заказчикам или пользователям. И тут прибегает…

Неважно, кто именно, и все-таки обязательно кто-то прибежит. Это могут быть заказчики с кучей новых идей через 2 дня после начала итерации; или кто-то из поддержки вбежит к разработчикам с криком «ничего не работает»; или даже собственные тестеры найдут ТАКОЕ. И как с этим жить, что делать с нашими планами, как это отразится на скорости работы?

Мои коллеги уже несколько раз просили меня нарисовать простые и понятные комиксы, отвечающие на эти вопросы. У меня не сложилось с рисованием, хотя, к счастью, я слежу за интересными блогами зарубежных коллег. Недавно Сердж Бьюмонт (Serge Beaumont) из Xebia опубликовал свой опыт на эту же тему и с замечательными картинками. Вольным переводом с моими комментариями я и хочу поделиться.

Решение 1. «Всех в сад» или Триаж + отмена.

В одной из предыдущих статей я рассказывал о том, как отдельно от ежедневных встреч, можно проводить встречу «Триаж», где принимаются решения о том, что делать с новыми пожеланиями или дефектами. Суть данного совета проста: убедитесь, что это действительно «аврал» :-). Часто, для того, чтобы быстрее получить своё пожелание, «заказчики» (или все заинтересованные лица вне команды) пытаются повысить приоритет. О да, они быстро понимают суть Scrum подхода и утверждают, что это мега срочно и мега важно, чтобы команда отложила то, что запланировали и все обратили внимание на этот запрос. Но мы то знаем, зачем мы применяли Scrum 😉

В этом подходе очень важен сильный Владелец Продукта, который должен принимать такие решения и говорить заказчику «нет». Ещё хорошо помогают чётко описанные правила «сложности проблемы» (severity). «Вся система валится и пользователь не может выполнить даже простых операций?» – тогда это действительно «аврал» (blocker), хотя, скорее всего это не так и приоритет будет ниже.

Решение 2. «Ждите, мы работаем» или Триаж + отложить на следующий Спринт

– Мы нашли очень большую ошибку! Нужно срочно исправить!

– Правда? А как давно она существует?

– Она тут уже около года, но нашли мы её только что.

– Хм, она тут уже около года и вы не можете подождать ещё две недели? Мы исправим её первым делом в следующей итерации, обещаем 🙂

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

Решение 3. Буфер для неожиданных проблем.

Итак, вы применили Решение 1 и Решение 2, а у вас все равно остались проблемы, которые нужно решать как можно скорее. Одно из лучших решений, которые я знаю, это зарезервировать буфер (во времени или «пунктах»), на которые вы не планируете работу. Это работает особенно хорошо, когда есть некие исторические данные о том, сколько незапланированной работы приходит. Вы можете не знать, что вы будете делать, но запланировать, сколько усилий это потребует.

Но будьте осторожны! При этом подходе есть опасность попасть в отдельную ловушку, связанную с размером буфера. Если буфер занимает существенную часть объёма работы на Спринт (например, больше 20%), то это уже не буфер, а «окно в ад» в ваших планах. Поэтому Правило Для Буфера #1: он не для элементов бэклога. Старайтесь держать буфер как можно меньше.

Вторая опасность с использованием буфера, такая же, как и в Решении 1: как только заказчики почувствуют, что могут обойти обычный порядок, то они тут же воспользуются этим :-). Буфер должен использоваться только для реальных проблем, поэтому делайте качественный Триаж!

Есть ещё третья возможная проблема с буфером. Вы должны следить за тем, как он используется, иначе вы будете неприятно удивлены в конце Спринта.

Решение 4. Улучшите наконец-то качество!

После того, как вы попробовали Решение 1, 2, 3, вы должны сделать самую главную вещь: исправить причины возникновения «авралов» и улучшить качество продукта! В конце концов, это то, что мы должны сделать в любом проекте, даже не обязательно работающему по Agile. И здесь, следует ввести Правило Для Буфера #2: если количество «авралов» превысило буфер, то сделайте «аварийную остановку» Спринта. Ведь если количество поступающих проблем превышает разумные пределы, то глупо надеяться, что появятся новые работоспособные функции. Скорее всего вы только подольёте масла в огонь. Остановитесь и используйте отдельный Спринт, чтобы исправить ключевые проблемы, а потом попробуйте опять.

Кстати, по случайному совпадению, Правило Для Буфера #2 может помочь в борьбе с заказчиками, когда они хотят «повысить приоритет». Спросите их: «Вы действительно хотите, чтобы мы это сделали? Ок, эта работа по нашим оценкам выходит за размеры буфера. Мы останавливаем Спринт, чтобы выполнить ваш запрос, а все те чудесные функции, которые мы планировали, вы получите позже, когда мы устраним проблемы. Что вы говорите, это уже не такая важная проблема?».

Решение 5 (дополнительное). Выбирайте правильный размер команды.

Размер команды напрямую не связан с тем, как вы боретесь с «авралами», в то же время это фактор, который следует учитывать. Маленькая команда работает лучше, потому, что меньше потери на коммуникации, но такая команда менее устойчива к «потере бойца», к болезням сотрудников или даже к тому, что некоторым приходится отвлекаться на борьбу с авралами. В команде из 10 человек, потеря одного сотрудника всего лишь 10% (ок, в упрощённом подсчёте, без учёта производительности). А вот в команде из трёх человек, потеря одного человека будет означать 33%! Лучший размер команды 7-9 человек. Достаточно маленький, чтобы уменьшить потери, и достаточно большой, чтобы быть устойчивым к возможным отвлечениям.

Решение последнее… Подумайте о переходе на Kanban, вместо Scrum.

Если вы обнаружите, что вы занимаетесь больше вопросами поддержки (пусть даже и не «авралами»), чем разработкой новых функций, то подумайте о переходе на Kanban. Это может помочь, потому что «гранулярность» Канбан – отдельные Истории (функции), а не Спринты. Если произойдёт «аврал», то он автоматически будет следующим в плане работ, без каких-либо изменений правил. Канбан ориентирован на поток, в то время как Скрам ориентирован на итерации-забеги. Эти два стиля достаточно близки и я видел Scrum команды, которые переходят в режим «потока», когда нужно заниматься только поддержкой и возвращаются к Scrum, когда работают над запланированным новым выпуском.