Скрам: Правила игры. Карманное руководство

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

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

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

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

3.5. ПОКЕР ПЛАНИРОВАНИЯ

Покер планирования – это техника оценки, изобретенная Джеймсом Греннингом на проекте в стиле экстремального программирования, где он понял, что слишком много времени уходит на оценку трудозатрат.

На покере планирования команда устраивает обсуждение требования, после которого каждый член команды делает оценку требования, выбирая карту с определенным значением из колоды. Карты для покера обычно используют экспоненциальную шкалу наподобие последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34, …). Члены команды не раскрывают выбранного значения до тех пор, пока все не сделают выбор. Далее все раскрывают свои оценки одновременно, после чего обсуждают возможные различия. Этот цикл повторяется до тех пор, пока не будет достигнуто согласие и общее понимание оценки требования. Оценки относительны и выражаются в абстрактных единицах, например в стори пойнтах или даже мишках Гамми, как в ранних проектах экстремального программирования.

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

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

3.6. ДЛИНА СПРИНТА

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

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

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

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

Появилась явная тенденция к укорачиванию спринтов. Хотя это и не является формальным требованием, недельные спринты представляются приемлемым минимумом.

Давайте посмотрим на команду с однодневными спринтами.