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