Найти тему

Когда можно делать релиз продукта в Scrum?

Оглавление

Вопрос из названия статьи связан с одним частым заблуждением. Считается, что scrum-команды выпускают инкремент продукта только в конце спринта, поэтому релиз новых функций возможен только после ревью. Разберёмся, так ли это.

Из-за этого бытуют убеждения, что Scrum недостаточно гибкий, раз обновлении нужно ждать после спринта, а спринт может длиться до месяца.

Релиз обновления в конце спринта кажется логичным, он хорошо накладывается на расписание scrum-событий. Но говорится ли где-то в ScrumGuide о времени релиза?

Жесткая привязка релиза к концу спринта говорит о том, что в такой команде структура главенствует над целью. Scrum применяется с тем, чтобы решать сложные вопросы в разработке ПО, быстро получать обратную связь и адаптировать её. Работа короткими итерациями позволяет: проверить результаты и принимать решения на базе реального опыта. Scrum пытается минимизировать стоимость ошибки и реализацию неверного решения.

Учитывая это, насколько вероятно, что в Руководстве по Scrum будет сказано, что релиз может быть только в конце спринта?

Спринт создан для того, чтобы у команды было достаточно времени для преобразование элементов бэклога в работающий продукт, который соответствует критериям «Done». Эти критерии должны быть одинаково поняты всеми вовлечёнными в разработку лицами. История может считать готовой при разных условиях: кто-то считает элемент бэклога сделанным, когда код написан и добавлен в общий репозиторий, кто-то считает иначе, и это может меняться от задачи к задаче.

То, насколько завершён инкремент продукта, всё-таки определяется не временем, а качеством функции, которую получают пользователи.

Таким образом, инкремент должен попасть в руки пользователей так быстро, как только все элементы будут иметь статус Done. Это увеличит скорость обратной связи и гибкость. В фреймворке Scrum нет никаких условий против того, чтобы команда делала релизы в течение всего спринта, тем более, если команде и продукту это нужно, а владелец продукта берёт ответственность за релиз.

Scrum поощряет команду постепенно расширять критерии Done: начинать определение «сделанных» историй с малого и постепенно расширять их функционал. Так истории можно наращивать от версии к версии.

Мы поняли, что делать релиз продукта можно в любое время в течение спринта, и в первую очередь это зависит от длины итерации, качества обратной связи и самого продукта.

Откуда появилось недопонимание?

Один из источников мифа — неверная трактовка термина «Инкремент». В ScrumGuide инкремент определяется как «сумма завершенных во время Спринта Элементов Бэклога Продукта и всех инкрементов предыдущих Спринтов». Инкремент может быть и набором новых функций, и суммой функциональности.

Из-за того, что инкремент понимается как результат спринта, некоторые считают, что готовые функции должны демонстрироваться и инспектироваться только в конце итерации, тогда релиз может состояться только после ревью.

Кому-то может показаться, что если релиз может быть постоянно, тогда отпадает надобность в ревью. Но это справедливо, если команда проводит плохое ревью спринта, которое состоит только из демонстрации.

Факт в том, что выпуск функций во время спринта не отменяет ревью. Его основная цель — проверить, что было сделано, собрать обратную связь, решить, что скорректировать и как двигаться дальше. Если функции были выпущены до ревью, на этом событии можно будет собрать более глубокие отзывы о работе с ними.

Что делать scrum-мастеру?

Scrum-мастер должен работать над понятием «DONE» в команде: разбивать задачу на части, например, кодинг, тестирование, релиз, сбор отзывов, документация и т. д. Также полезно применять гибкие практики, такие, как непрерывная доставка. Это позволяет сократить стоимость ошибки.

Ко всему прочему, scrum-мастер должен работать над форматом обзора спринта. Если спринт проводится как демонстрация, перенесите демо на другой день, а ревью используйте так, как задумано в Руководстве — для сбора обратной связи и обсуждения новых вводных, которые повлияют на отбор задач при планировании спринта.

В общем, если команда может выпускать готовый продукт быстрее, чем в конце спринта, не ограничивайте её в этом!