Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban

• Результат. Основная задача планирования заключается в том, чтобы команда и владелец продукта сошлись на том, какой результат будет предоставлен в конце спринта; соответственно, этот процесс в основном вращается вокруг формирования ожиданий. Практически всегда владелец продукта будет хотеть больше, чем команда может дать. В силу этого команде стоит четко понимать свои возможности и здраво оценивать количество работы, которое они могут выполнить в разумные сроки. Первые несколько раз подобные оценки могут даваться нелегко, и это еще один повод держаться безопасной стороны.

Избегайте личностных конфликтов

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

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

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

• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать, лучше дать им такую возможность.

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

• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить. Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия будут отрицательными.

Выработка хороших практик

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

• Никогда не переходите к планированию в отсутствие Владельца продукта и представителей ключевых отраслей.

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

• Не пытайтесь спасти ситуацию, интерпретируя истории, пытаясь связать их и вырабатывая критерии оценки на лету.

• Убедитесь в том, что все проблемы и возможные вопросы разрешены прежде, чем вы будете двигаться дальше. Иногда Владельцу продукта и команде может потребоваться для этого время.

• Если процесс забуксовал, примите меры. Старайтесь сохранять темп. Перейдите к следующему этапу и, если нужно будет, вернитесь к проблемному этапу позже.

• Не разрешайте никому и особенно Скрам-мастеру решать за команду, что делать и диктовать другим свои решения.

Блистательный пример

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