Перевод оригинального Скрам-паттерна
…вы на Sprint Planning и вы готовы начать Sprint.
✥ ✥ ✥
Смысл Sprint в том, чтобы доставить ценность заинтересованным лицам. Однако, простое следование списку Sprint Backlog Item (например, задач), не обязательно приводит к созданию максимально возможной ценности.
Когда команда создает план работ исходя из индивидуальных задач или результатов, легко взять отдельный элемент и работать над ним индивидуально в течение Production Episode. Однако, это снижает возможность инноваций, возникающих в результате коллаборации людей, которые привносят в работу различные точки зрения. Офисные стены могут стать барьерами на пути к непрерывному общению, которое важно для всех разработчиков (участников Development Team) и всей команды в целом. Страдает командная работа.
Команде, возможно, надо частично перепланировать текущий Sprint, чтобы убедиться, что ценность будет создана к концу Sprint.Новая работа может появиться в самый последний момент, и команда должна обновить план. Следование первоначальному плану может привести к тому, что максимально возможная ценность не будет создана. Другое частое явление — в ходе Sprintстановится понятно, что команда не завершит все Элементы Sprint Backlog. Это часто происходит потому, что объем работы, необходимой для завершения Элемента Бэклога Спринта, увеличивается.
Другой сценарий, когда команде для разработки Product Backlog Item (PBI) нужно получить важные технические знания. Разработчикам (или даже Product Owner) может понадобиться технический прототип, чтобы проверить архитектуру или узнать рабочие характеристики технологии. Несмотря на то, что PBI должен идентифицировать такую работу, его неопределенный характер требует, чтобы команда сфокусировалась на получении знаний, а не на завершении всей запланированной работы. Технический прототип становится критическим пунктом для успеха Sprint.
Иногда наибольшая ценность не привязана к конкретному Product Backlog Item. Например, наибольшей ценностью для команды было увеличение дохода за Sprint, и команда посвятила Product Backlog Item этой цели. С другой стороны, иногда большая часть ценности в Sprint связана с одним конкретным PBI.
Следовательно:
Scrum Team привержена достижению короткой формулировки ценности, которую она создает во время Sprint. Она становится фокусом всей работы в течение Sprint.
Вся Scrum Team совместно создает Sprint Goal. Product Owner будет драйвить создание Sprint Goal, потому что он лучше всех понимает следующие шаги к Product Vision и то, как создать Greatest Value. Scrum Team становится привержена достижимой Sprint Goal.
✥ ✥ ✥
Scrum Team может использовать Sprint Goal для выбора PBI’s в Sprint, но в некотором смысле, Sprint Goal важнее, чем сумма отдельных PBI’s. Sprint Goal создает согласованность между PBI’s, помогая создать ценный Product Increment. Один из хороших первоначальных подходов к формированию Product Backlogсостоит в том, чтобы выразить его в виде списка Sprint Goals, который Product Owner и Development Team вместе уточняют в форме PBI’s.
Участники Autonomous Teams должны быть в состоянии самостоятельно контролировать достижение целей, а в Developer-Ordered Work Plan указано, что Development Teams могут упорядочивать работу в Production Episode так, как считают нужным. Sprint Goal — единственный механизм, как Product Ownerможет влиять на потенциальный порядок, в котором Development Team выполняет свою работу (делая вывод о срочности и важности, которую передает Sprint Goal), но, опять же, только с согласия Development Team.
Во время Sprint Planning, Scrum Team определяет, что она стремится достичь к концу Sprint; короче говоря, это то, для чего создается Sprint Goal. Development Team определяет детали того, как достичь эту Sprint Goal, создавая Sprint Backlog. Если Development Team приходит к выводу, что достичь Sprint Goal невозможно, ее следует посоветоваться с Product Owner. Ключевым результатом Sprint Planning является то, что Development Team в состоянии объяснить, как она достигнет Sprint Goal и как поймет, что та достигнута. Для этого нужно глубокое понимание предстоящей работы, что повышает шансы достижения Sprint Goal за Sprint.
Development Team привержена достижению Sprint Goal. Sprint Goalспособствует объединению Development Team (см. Unity of Purpose), и это служит укреплению доверия заинтересованных лиц к команде.
Sprint Goal должна быть прозрачна для команды; например, помещена на Скрам Доску или использована в другом Information Radiator.
Development Team продолжает держит Sprint Backlog в актуальном состоянии во время Sprint, поддерживая достижение Sprint Goal. Прогресс выполнения Sprint Backlog (как показано на Sprint Burndown Chart) подобен прогрессу на футбольном поле: хотя каждый ярд движения по полю приближает мяч к финалу, ценность приходит только, когда гол забит в ворота. Иногда возможно достичь Sprint Goal, не завершив все SBIs. Это помогает командам справляться с непредвиденными ситуациями и дает Developersгибкость в изменении их рабочего плана каждый день во время Daily Scrum. Например, возникающие препятствия могут поставить под угрозу достижение Development Team всего Sprint Backlog. В этом случае команда автоматически прибегает к Sprint Goal как к «Плану Б», не тратя долгие часы на перепланирование.
Согласно исследованию, проведенному Университетом Карнеги-Меллон, команды, которые заранее готовятся к прерываниям, справляются с ними на 14% лучше. Команды, которые готовятся к прерываниям, завершают задачи, на которые прерываются, на 43% быстрее.
Теоретически возможно постоянное достижение Sprint Goal когда каждый Sprint завершается только часть PBIs. Это должно быть редкостью, потому что Sprint Backlog должен соответствовать Sprint Goal; если этого не происходит, то существует серьезная проблема с Value Stream.
Скорость (см. Notes on Velocity) помогает командам понять, работают ли они все правильно. Sprint Goal помогает командам убедиться в том, что они разрабатывают правильные вещи. Речь идет о понимании того, «почему» команда разрабатывает что-то, для фокуса в случае изменений.
Джефф Сазерленд добавляет, что кроме фокуса Sprint Goalпоощряет Swarming: Можем ли мы стимулировать всех работать над чем-то одним вместе? Он рассказывает:
В Кремниевой Долине в 2007 году компания Palm работала над Web OS, которая впоследствии была приобретена компанией Hewlett-Packard. Каждый Sprint команды хорошо работали, пока через пару Sprints не появилось ощущение, что они уперлись в стену. PBIs не заканчивались. Разработчики были демотивированы и рано уходили домой. Меня пригласили и совместно с Product Owners и Scrum Masters мы провели час, опрашивая членов команды о том, почему они демотивированы. Мы обнаружили, что они не понимают, почему они должны усердно работать над низкоуровневыми PBIs.
Мы провели послеобеденное время, разбирая Product Backlog, показывая четкую связь между историями высокого уровня и иерархией декомпозиции. Как только разработчики поняли, что Sprint Goal было улучшение производительности Web OS на 10%, у них появилась мотивация завершить низкоуровневые истории, и скорость вернулась к норме.
Для разработчиков, и особенно для глубоких экспертов, важно понимать, почему разрабатываются PBI(s).
Sprint Goal обычно имеет отношение к Ценности Продукта. Команда может альтернативно связать Sprint Goal с процессами, например: “выполнять всю работу через парное программирование”, или “появляться вовремя на Daily Scrum каждый день”.
Движение к Sprint Goal мотивирует и вовлекает команду и наоборот, Happiness Metric может быть эффективным инструментом для определения Sprint Goals.
В 2001 году Кен Швабер и Майк Бидл были первыми, кто описал Sprint Goal.
Picture credits: Shutterstock.com.
