Софт за 30 дней. Как Scrum делает невозможное возможным

Разрабатывать программное обеспечение будет Scrum-команда, состоящая из того, кто хочет получить программное обеспечение (владелец продукта), менеджера (Scrum-мастер), а также разработчиков. Чтобы избежать путаницы, может быть только один владелец продукта, который решает, что будет разработано в каждой итерации, или спринте – в терминологии Scrum, – и оценивает результаты приращения функционала в конце каждого спринта. Scrum-мастер управляет проектом согласно правилам Scrum. Некоторые Scrum-мастера прошли обучение, другие имеют значительный, проверенный опыт в успешном его использовании. Главное – знание, как управлять Scrum-командой и проектом.

Создание Scrum-команды и планирование спринта

Первая задача Scrum-мастера – поиск разработчиков и создание команды разработки. Люди в этой команде должны иметь необходимую квалификацию по превращению потребностей и требований владельца продукта (бэклог продукта) в рабочие инкременты программного обеспечения после каждого спринта.

Все члены Scrum-команды собираются для знакомства, обсуждения предстоящей работы и создания условий для совместной работы. Scrum-команда должна знать видение продукта (необходимый и желаемый результат), какие результаты будут означать успех или неудачу и какие есть ограничения. Команда рассматривает только самые важные требования и выбирает максимальное количество тех, что имеют хорошие шансы быть реализованными в предстоящем спринте. (Разработчики должны иметь опыт по разделению больших требований на маленькие осуществимые фрагменты, которые они смогут завершить в спринте.)

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

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

В силу необходимости двигаться дальше этот начальный этап должен быть протяженностью в один день.

Участники Scrum-команды работают вместе, пока все имеют четкое понимание проблемы и подхода к ее решению, пока все знают, что должно быть разработано в предстоящем спринте. Вещи, которые не были очевидными, станут проясняться, как только команда начнет создавать программное обеспечение.

Спринт за ценностью

Теперь Scrum-команда начинает создавать программное обеспечение, начиная с дня, непосредственно после дня планирования спринта. Инкремент функциональных возможностей программного обеспечения разрабатывается в течение первого спринта. Он может быть больше или меньше того, что прогнозировалось. Все члены Scrum-команды взаимодействует в течение спринта, проясняя задачи. Работа может быть переопределена, требования могут добавляться или удаляться по необходимости, если команда разработки определит, что время остается или оставшегося времени недостаточно.

Каждый день в течение спринта разработчики проводят 15-минутные совещания, называемые Scrum-митингами, чтобы спланировать предстоящую работу, все время стремясь достигнуть того, что было договорено. Чтобы максимизировать продуктивность разработчиков, задачи спринта должны быть согласованы как разработчиками, так и владельцем продукта. Они соглашаются, что создадут столько требуемого функционала, сколько возможно, и могут быть переориентированы перед каждым новым спринтом. Владелец продукта соглашается, что требования, над которыми работает команда, не будут меняться в течение спринта. Все, что не было запланировано (включая, например, участие разработчиков во встречах с потребителями), может подождать до следующего спринта. Производительность разработчиков повышается, когда их не прерывают. Применение более коротких спринтов обычно обеспечивает внесение более частых изменений – об этом мы поговорим в следующей главе.

Проведение обзора спринта