Рефакторинг сорванного Sprint в середине недели
Когда наступает среда, а план на Sprint трещит по швам, не паникуйте и не требуйте сверхурочной работы. Узнайте, как передоговориться об объеме задач, защитить Sprint Goal и перезапустить работу.
К утру среды все обычно становится понятно. Скрипт миграции упал на тестовом контуре, API внешнего подрядчика не совпадает с документацией, или критический сбой выдернул ведущих инженеров на два полных дня. План, составленный в понедельник утром, больше не работает. Команды обычно реагируют на это одной из двух типичных ошибок. Одни начинают выгорать на сверхурочных, пытаясь сотворить чудо любой ценой. Другие делают вид, что все идет по плану, и молча дожидаются вечера пятницы, чтобы признать провал. Ни один из этих подходов не приносит результата.
План не высечен в камне
Многие инженеры относятся к Sprint Backlog как к жесткому контракту, подписанному раз и навсегда. Это заблуждение. В Scrum Guide 2020 года об этом сказано прямо. Sprint Backlog создается Разработчиками для Разработчиков. Это наглядная картина работы в реальном времени, и она обновляется на протяжении всего Sprint по мере поступления новой информации. Содержание работы можно уточнять и обсуждать заново с Product Owner в любой момент.
На Sprint Planning вы берете обязательство достичь Sprint Goal, а не закрыть неизменный список из пятнадцати тикетов. Если ради этой цели нужно выбросить половину первоначальных задач и написать совершенно другие, делайте это без всяких сомнений.
Оценка того, что еще можно спасти
Как только вы понимаете, что неделя идет не по плану, соберите короткую тридцатиминутную встречу между Разработчиками и Product Owner. Не ждите следующего Daily Scrum, если работа заблокирована уже сегодня. Ожидание в такой ситуации становится лишь вежливой формой прокрастинации.
Задайте один прямой вопрос. Сможем ли мы достичь Sprint Goal, если откажемся от всей второстепенной работы? Представьте, что вашей целью была возможность выгрузки ежемесячных счетов в CSV для операционного отдела, но попутно вы планировали сделать экспорт в PDF, отправку по расписанию и выбор дат. Сократите задачу до абсолютного минимума. Сделайте только выгрузку в CSV с базовыми полями формы. Клиент получит обещанную ценность, цель будет закрыта, а команда не станет выпускать в спешке непротестированный код.
Пошаговый план перезагрузки
Вот надежная последовательность шагов, чтобы стабилизировать проблемный Sprint в середине недели:
- Немедленно прекратите брать в работу новые задачи и сосредоточьте усилия на том, что уже начато.
- Пересмотрите Sprint Goal вместе с Product Owner, чтобы убедиться, что она все еще несет практическую ценность.
- Определите минимально жизнеспособную часть функциональности, необходимую для достижения этой цели.
- Верните второстепенные задачи обратно в Product Backlog без чувства вины и долгих согласований.
- Сфокусируйтесь всей командой на оставшихся задачах, отказавшись от изолированной работы поодиночке.
Обратите внимание, что снятые задачи не должны отправляться в отдельную колонку для незавершенной работы. Они возвращаются прямо в Product Backlog. Если эти элементы все еще представляют ценность, Product Owner сможет расставить приоритеты для них в будущих Sprint. Если нет, они просто исчезнут, не захламляя вашу доску.
Когда отмена остается единственным честным выходом
Иногда проблема оказывается серьезнее банальной ошибки в оценке сроков. Внезапное архитектурное решение делает выбранный технический подход невозможным, либо заказчик вовсе закрывает инициативу. Если сам Sprint Goal теряет актуальность, продолжать писать код по привычке бессмысленно.
Scrum Guide дает Product Owner право отменить Sprint, если его цель утратила смысл. Команды редко пользуются этой возможностью, потому что она воспринимается как публичное признание неудачи. Однако продолжать сжигать ресурсы на заведомо бесполезную работу намного хуже. Отмена Sprint очищает доску, открыто показывает реальное положение дел компании и позволяет немедленно спланировать правильное направление работы.