AgiliX: Нулевой спринт – низкий старт Скрам команды

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

С чего начать? Что необходимо сделать в «нулевую» итерацию? Каков минимальный набор для успешного старта Скрам команды и запуска первого спринта?

Что делаем в Нулевом спринте

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

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

Нам понадобится следующий минимум перед началом первого спринта (Vizdos 2005):

Знания о процессе.
Знания о команде.
Знания о продукте.

Нулевой спринт имеет еще одну очень важную характеристику, которая ставит его в особое положение по отношению к другим – особое участие бизнеса и Владельца Продукта. Их роли в нулевом спринте просто критичны.

Узнать о процессе

Даже если мы знаем, что у нас в команде собрались люди, которые прекрасно понимают все тонкости Скрама, обсудить будущий процесс просто необходимо. Мы должны понимать, что количество видений Скрама в команде ровно количеству человек в нашей команде. Каждый будет воспринимать процесс через призму своего прошлого опыта. К тому же на нулевом спринте часто присутствуют представители бизнеса, которые нередко очень далеки от понимания не только Скрама, но и вообще Гибкой разработки в целом.

О чем стоит поговорить:

Аджайл Манифест, его ценности и принципы.
Чем отличается гибкие эмпирические процессы (в частности Скрам) от классической детерминистической модели классического менеджмента. Их преимущества.
Особенности итеративно-инкрементной разработки.
Минимальный Скрам фреймворк.
Роли и ответственности в Скраме.
Скрам надстройки, которые мы планируем использовать в проекте и их форматы (например User Story).

Также Скрам мастер может установить определенные ожидания производительности от команды. Это совсем не значит, что мы должны устанавливать конкретные сроки, через которые производительность должна вырасти в определенное количество раз. Но показать, что это возможно, и что многие команды по всему миру смогли получить состояние гиперпродуктивности, стоит. Отличной динамикой роста Velocity для Скрам команды считается рост порядка 10% за каждый спринт, что означает удвоение изначальной производительности примерно через полгода работы. Для подобной установки я использую модифицированное мною High-performance Tree активность (Coaching Agile Teams, 2010).