Выводы
Когда я рассказал эту историю на встрече скрам-мастеров в Милане в июне 2003 года, Мел Пуллен отметил, что считает практику скрама скрамов противоречащей принципам самоорганизации и самоуправления скрама. Иерархические структуры навязаны руководством, утверждал Мел, а не теми, кто фактически выполняет работу. Почему бы не дать каждой команде выяснить, с какими другими командами нужно сотрудничать и координировать работу и где команды зависимы? Либо скрам-мастер сможет указать на зависимость от другой команды, либо команда разработки сама столкнется с зависимостью в процессе работы. Наткнувшись на зависимость, команда может отправить участника в качестве «цыпленка» на ежедневный скрам другой команды, работающей над зависимостью. Если никто не работает над этой зависимостью, команда может попросить владельца продукта создать соответствующий элемент бэклога продукта с высоким приоритетом. Скрам-мастер может либо позволить первой команде самостоятельно решить проблему зависимости, либо помочь сформировать другую команду для этого.
Это интересное замечание. Скрам основывается на самоорганизации, простых правилах и рекомендациях. Какой вариант больше подходит для координации и масштабирования проектов – примененный Джеком скрам скрамов или предложенное Мелом самостоятельное устранение зависимостей командой? Я пробовал оба и пришел к выводу, что правильное решение зависит от комплексности ситуации. Когда комплексность велика настолько, что самоорганизация не происходит достаточно быстро, простые правила помогают организации достичь своевременного решения. Но если самоорганизация происходит своевременно, я предпочитаю полагаться на нее, потому что руководство вряд ли сможет предлагать адаптации так же часто и хорошо, как это может делать команда. Иногда скрам-мастер может помочь самоорганизации, предложив несколько простых правил, однако в этом случае скрам-мастеру полезнее недоделать, чем переусердствовать.
Приложение A
События и правила скрама
Рассматриваемые в этом приложении правила сводят процесс скрама в единую систему. Это правила игры. Если правила не соблюдаются, время тратится на выяснение того, что делать, как делать, зачем делать. Если правила оспариваются, время теряется, пока все ждут разрешения спорной ситуации. Скрам-мастер отвечает за то, чтобы все прямые и косвенные участники проекта – и поросята, и цыплята – следовали правилам скрама. Правила скрама доказали свою эффективность в буквальном смысле в тысячах успешных проектов. Если хочется, можно изменить правила, используя для этого ретроспективу спринта. Изменения правил должны исходить от команды, а не от руководства. Правила следует изменять тогда и только тогда, когда скрам-мастер убежден, что команда и все участники достаточно глубоко понимают, как работает скрам, и обладают достаточными знаниями и опытом, чтобы осознать потребность в изменении правил и предложить улучшения. Никакие правила не могут быть изменены, пока скрам-мастер не подтвердит, что такое состояние команды достигнуто.
Планирование спринта
Задачи, над которыми будет трудиться команда разработки во время спринта, определяются на планировании спринта. План создается совместными усилиями всей скрам-команды. Планирование спринта ограничено по времени: для спринта длительностью один месяц планирование должно занимать не более восьми часов. Если спринт короче, то и планирование проводится быстрее.
В ходе планирования спринта скрам-команда принимает решения по двум темам:
■ каким будет инкремент продукта в конце спринта;
■ как организовать свою работу, чтобы получить готовый к поставке инкремент.
Ответ на первый вопрос предполагает выбор элементов бэклога продукта, а второй – формирование бэклога спринта. В событии участвуют владелец продукта, команда разработки и скрам-мастер. Сторонние участники могут быть приглашены на планирование для предоставления дополнительной информации или рекомендаций о предметной области или по технологическим аспектам, но после этого они покидают событие. Никто не остается на планировании в качестве наблюдателя. Владелец продукта должен подготовить достаточное количество элементов бэклог-продукта до планирования. В отсутствие владельца продукта или достаточного количества элементов бэклога продукта скрам-мастер готовит соответствующие элементы и замещает владельца продукта на событии.
Тема первая: что будет сделано?
Команда разработки прогнозирует объем функциональности, который будет разработан в течение спринта. Владелец продукта выносит на обсуждение два важных вопроса:
■ бизнес-цели, которые должны быть достигнуты в спринте;
■ элементы бэклога продукта, необходимые для достижения цели спринта.
На основании этих данных скрам-команда формирует единое понимание обо всей работе в спринте. Команде разработки принадлежит исключительное право оценивать объем работы, который она сможет выполнить в текущем спринте. И именно команда разработки определяет, сколько из предлагаемых владельцем продукта элементов бэклога продукта она сможет превратить в готовый к поставке инкремент функциональности. Скрам-команда продемонстрирует эту функциональность заинтересованным лицам на обзоре в конце спринта. Команда разработки определяет объем работы на спринт, но решение о том, какие элементы бэклога продукта попадут в спринт, принимает владелец продукта. Во время планирования спринта скрам-команда формирует цель спринта, которая служит ориентиром для реализации элементов бэклога продукта и помогает команде разработки лучше понять, для чего создается текущий инкремент продукта.
Цель спринта
Цель спринта – это установленный для спринта ориентир, который достигается через выполнение части бэклога продукта. Она формируется во время его планирования и объясняет команде разработки, для чего создается инкремент.
Цель спринта оставляет команде разработки некоторую гибкость в объеме функциональности, которую она разрабатывает в рамках спринта. Так, выбранные элементы бэклога продукта могут реализовывать одну связанную функцию, которая является целью спринта. Или целью спринта может быть любая другая логическая связь, для достижения которой команда разработки будет работать совместно, а не разрозненно над разными задачами.
Тема вторая: как будет выполнена работа?
Когда цель спринта определена и выбраны элементы бэклога продукта, команда разработки самостоятельно и без каких-либо внешних рекомендаций решает, как превратить эту функциональность в готовый к поставке инкремент продукта в течение спринта. Все остальные могут только наблюдать или отвечать на уточняющие вопросы, когда команде разработки нужна дополнительная информация по элементам бэклога. Команда разработки во время планирования при работе над бэклогом спринта самоорганизуется, как и во время самого спринта.
Результатом планирования становится бэклог спринта, состоящий из выбранных элементов бэклога продукта и плана их реализации, который, в свою очередь, состоит из задач, их оценки и выбранных на ближайшие два-три дня исполнителей, чтобы участники команды могли приступить в разработке функциональности. Фактическая работа может отличаться от планируемой объемом и сложностью, поэтому список задач может быть неполным, но он должен быть достаточным, чтобы команда могла прогнозировать объем работы, который сможет выполнить за предстоящий спринт. Часто команда разработки более тщательно детализирует работу, которую будет выполнять в первые дни спринта. Для этого она разделяет работу на более мелкие задачи, обычно длительностью не более одного дня.
