Вы знали, что ежедневный скрам – необязательно ежедневное короткое собрание команды?

Ежедневное короткое собрание команды – это практика, описанная в экстремальном программировании[28], которая служит той же цели, что и ежедневный скрам. Но экстремальное программирование советует последователям проводить это мероприятие стоя.

В скраме не обязательно стоять. Однако это хорошая тактика, особенно если вы хотите уложиться в 15 минут.

3.3. УТОЧНЕНИЕ БЭКЛОГА ПРОДУКТА

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

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

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

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

3.4. ПОЛЬЗОВАТЕЛЬСКИЕ ИСТОРИИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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