При внедрении SCRUM часто возникает ситуация, когда в процессе спринта прилетает срочная задача. Например, критичный баг у клиента или на проде, задача от «большого начальника», который не привык ждать, и т.п. Возникает вопрос: «что делать и как с этим жить?».
Стандартно бывают несколько способов решить проблему:
- Если проект большой и над ним работает несколько продуктовых команд, то выделяют отдельную пожарную команду на исправление критичных багов.
- Всем прибегающим отказываем, мотивируя тем, что scope спринта не меняется и все будет, но в следующем спринте.
- Берем задачу в работу, потом в конце спринта констатируем, что вот опять не успели так как нежданчик прилетел. А если нежданчиков много, то можем и в принципе все планы не выполнить.
Разберем каждый из вариантов:
Пожарная команда — это наказание, быть в ней скучно. Чем ей заниматься, если багов не прилетает тоже непонятно. Могут, конечно, править старые баги или техническими долгами заниматься, но это все демотивирует разработчиков.
Не меняем scope спринта. Начнем с того, что всем не откажешь. Всегда есть человек с нужным административным ресурсом, которому отказать не удастся. Но даже если отказывать умеем, то что делать с лежащим продом? Обычно он не готов ждать до следующего спринта, чинить надо здесь и сейчас. Поэтому такой вариант ведет к бесконечным конфликтам с контрагентами, эскалациям, а делать все равно придется.
Берем задачу в работу, а потом жалуемся, что опять не успели и расстраиваемся по этому поводу и оправдываемся перед Product Owner’ом.
по RSS
Последние комментарии