Уходим в спринт (да, да, мы все еще про Scrum)

Ранее:
Введение в Scrum
Роли при Scrum разработке
С чего начинается Scrum

При удачном стечении обстоятельств, практически не переругавшись, мы получили перечень функционала, который необходимо реализовать. Product Owner поставил ему приоритеты, команда оценки сложности. Начнем писать код?

Пока рано. Сначала нужно определиться, какими итерациями (спринтами) мы будем работать, какие цели будут у этого спринта, какие пользовательские хотелки мы возьмем на первую итерацию и какие задачи нам надо решить, чтобы реализовать эти пожелания.

Но по порядку. Итак, как выбрать длину спринта? Если у вас это первый спринт в жизни, то методом трех П: палец, пол, потолок. Выбирайте любой интервал в диапазоне от недели до месяца. Но вот после того, как вы закончите первый спринт, этот вопрос станет со всей серьезностью. Если вас продолжительность устроила, то все замечательно, так и оставляем. Если вы считаете, что за спринт вы успели сделать очень мало, то добавьте к спринту неделю. Если в начале спринта не смогли его правильно запланировать, взяли много/мало полезностей в работу или еще какие-то проблемы, то сократите спринт. Помните, к каким методологиям относится Scrum? К гибким! А это значит, что вы ДОЛЖНЫ постоянно менять процесс, чтобы он становился лучше. Из того, что я точно знаю, что применяется, это: у нас 2 недели, на новом месте работы Павла Музыки - 3 недели + 1 неделя межсезонья между спринтами, на ретроспективу и подготовку к новому спринту.

Определились? Тогда переходим к взятию командой на себя обязательств. Команда просматривает Backlog отсортированный по приоритету и выбирает, какие из приоритетных функций будет реализовывать. Причем выбор должен быть не тупо, провели черту под N элементами и вперед. Нужно понять, что мы можем сделать большое и чистое за этот спринт. Это большое и чистое должно быть некоторой законченной частью будущей программы, которую неплохо было бы по итогам спринта уже и передать заказчику на посмотреть, пощупать, а может и использовать. Цель должна быть обязательно сформулирована и записана. Чтобы когда спринт закончится, мы могли сказать: да, цель достигнута.

У отобранных элементов Backlog-а статус меняется на "Взятый в обязательства" (Сommitted). Все эти элементы перемещаются из Product Backlog-а в Sprint Backlog. Основное его отличие от Product Backlog-а, заключается в том, что Product Owner к нему доступа не имеет. После начала спринта команда работает только с теми задачами, которые были запланированы в начале. В идеале ничего добавляться в спринт не должно. Как у любой медали, у этой блокировки Sprint Backlog-а есть две стороны:

1. Светлая. Команда взяла на себя обязательства. А раз на спринте другой работы не добавляется, то, что обещали - надо сделать.

2. Темная. Бывают прецеденты, когда команда уже ушла в новый спринт, а тут обнаруживается ошибка в релизе. Нет, не так. Обнаруживается ОШИБКА! И что с ней делать? Ведь менять задачи в процессе спринта вроде как запрещено? Что делать? И, к сожалению, однозначного ответа тут дать нельзя. Хотя вариантов масса, добавить устранение ошибки в спринт, убрав функционал с наименьшим приоритетом. Прервать текущий спринт и устранив ошибку, начать новый. Если команда сознательная и мобилизующаяся, то может они возьмут устранение ОШИБКИ и в текущий спринт без изменения начального перечня, ведь это их ошибка. Первый и последний вариант, это право команды, второй - Product Owner-а. Вообще, об авралах и прерывании спринта, я думаю напишу отдельную статью.

Ок, первые два пункт закрыли. Переходим к последнему: разбиению на задачи. Процесс очень похож на оценку командой Backlog-а, только теперь каждый элемент Sprint Backlog-а, команда разбивает на задачи и каждой из них ставит время, за которое эту задачу можно решить.

Пример:

Sprint Backlog Item:

Реализовать окно логина пользователя в систему (Статус: Committed, Сложность 1)

Задачи:

1. Разработать форму ввода логина и пароля (0,5 часа)

2. Написать метод кэширования пароля (1 час)

3. Написать метод проверяющий введенные учетные данные и возвращающий информацию о пользователе (0,5 час)

---

Таким нехитрым образом, мы получим список задач, которые необходимо решить в процессе работы над текущим спринтом. И только теперь начинаем писать код.

О том, как выбирать задачи, оценивать успеваем или нет, читайте в следующей статье.