Один из трёх Принципов Скрама. При обнаружении отклонений от допустимых пределов одного или несколько элементов процесса или продукта, и если эти отклонения могут привести к бесполезности продукта, следует внести соответствующие изменения – либо в процесс, либо в разрабатываемые материалы (продукт).
Скрам предписывает четыре формальных мероприятия для инспекции и адаптации:
- Планирование Спринта
- Ежедневный Скрам
- Обзор Спринта
- Ретроспектива Спринта
Материальное представление работы или ценности. В Скраме существует три артефакта: Бэклог Продукта, Бэклог Спринта, Инкремент.
Они спроектированы таким образом, чтобы обеспечить максимальную прозрачность ключевой информации, и чтобы все участники процесса имели единое понимание каждого из артефактов.
Бэклог Продукта – это упорядоченный и постоянно обновляемый список всего, что планируется сделать для
создания и улучшения продукта. Этот артефакт Скрама является единственным источником работы для Скрам-команды. Владелец Продукта несет ответственность за Бэклог Продукта, включая его содержимое, доступность и упорядочение.
Элементы Бэклога Продукта, которые могут быть доведены Скрам-командой до состояния готовности в течение одного Спринта, считаются готовыми к помещению в Бэклог Спринта (см. также Критерии Готовности к Разработке). Элементы достигают такого уровня прозрачности после активностей по Уточнению Бэклога Продукта, в ходе которого элементы снабжаются актуальной уточняющей информацией, разбиваются (декомпозируются) на более мелкие и конкретные, получают оценки размера, а также упорядочиваются.
Оценку размера элементов производят Разработчики, которые будут выполнять работу. Владелец продукта может влиять на Разработчиков, помогая им понять элементы и обсуждая компромиссы.
В Руководстве по Scrum 2020 появилась Цель Продукта, являющаяся commitment’ом для Бэклога Продукта.
Статья Что такое бэклог?Какие бывают бэклоги, какие в них элементы и что значит «управлять бэклогом».
См. также: Что такое продукт?Практическое определение продукта от ScrumTrek.
Бэклог Спринта – это выбранный на Спринт набор Элементов Бэклога Продукта, а также план разработки Инкремента продукта и достижения Цели Спринта. Служит для наглядного представления работы, которую Команда определила для достижения Цели Спринта.
Бэклог Спринта состоит из:
- Цели Спринта (отвечающей на вопрос «Зачем делать?»),
- набора Элементов Бэклога Продукта, выбранных для выполнения в текущем Спринте (отвечающих на вопрос «Что делать?»),
- осуществимого плана действий по поставке Инкремента в рамка выбранных элементов (план отвечает на вопрос «Как делать?»).
Бэклог Спринта — это результат Планирования Спринта, управляемый силами Разработчиков для самих Разработчиков. В нем должно быть достаточно деталей, чтобы Разработчики могли инспектировать свой прогресс во время Ежедневных Скрамов.
Бэклог Спринта – это наглядный и доступный в режиме реального времени план работы, отнюдь не фиксированный в момент завершения Планирования Спринта. Поэтому Бэклог Спринта обновляется на протяжении всего Спринта по мере появления новых знаний. Для наглядности Бэклог Спринта обычно визуализируется на Доске Спринта.
Бэклог Спринта обычно включает одно или несколько улучшений процесса, которые Скрам-команда решила брать в работу на Ретроспективе прошлых Спринтов.
С точки зрения commitments, появившихся в Руководстве по Scrum 2020 для каждого из трех Артефактов Скрама, для Бэклога Спринта commitment’ом является Цель Спринта.
Это одна из 3 зон ответственности в Скрам-команде. Владелец Продукта отвечает за максимизацию ценности продукта, получаемого в результате работы Скрам-команды. В его обязанности также входит курирование и приоритизация Бэклога Продукта. Около 50% времени Владелец Продукта проводит с клиентами и заинтересованными лицами, остальные 50% работает совместно с командой.
В качестве ответственного за эффективное управление Бэклогом Продукта, Владелец Продукта:
- разрабатывает Цель Продукта и делает ее явной;
- создает и четко объясняет Элементы Бэклога Продукта;
- упорядочивает Элементы Бэклога Продукта;
- обеспечивает прозрачность, доступность и понимание всеми Бэклога Продукта.
Владелец Продукта может выполнять это работу сам или делегировать ее выполнение другим лицам, оставаясь ответственным за ее результат.
Чтобы Владелец Продукта мог в этом преуспеть, вся организация должна уважать его решения. Эти решения отражены в содержании и порядке элементов Бэклога Продукта, а также в Инкрементах, которые инспектируются во время Обзора Спринта.
Владелец Продукта — это один человек, а не комитет. Владелец Продукта может отражать в Бэклоге Продукта потребности многих заинтересованных лиц. Желающие изменить Бэклог Продукта могут сделать это, попытавшись убедить Владельца продукта.
Подробнее о роли владельца продукта читайте в статьях:
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. По мере того, как дни Спринта проходят и задачи на Доске Спринта переходят в «Готово», график сгорания работ идет вниз, показывая Команде ее прогресс относительно Цели Спринта.
Этот инструмент эффективен за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу Спринта (см. идеальную прямую на рисунке ниже). Это ведет к уменьшению числа параллельных задач, стимулирует команду помогать друг другу ради скорейшего перехода задач в «Готово» и в итоге ведет к повышению эффективности Команды.
Если к середине Спринта график еще не пошел вниз, Команде необходимо срочно переходить на стратегию аварийной ситуации (Emergency Procedure). Скрам-мастеру при этом важно помогать Команде действовать проактивно, не дожидаясь, когда Спринт закончится провалом.
Доска Спринта, часто называемая «Скрам-доской» или просто «Доской задач», — это инструмент визуализации Элементов Бэклога Спринта на протяжении Спринта. Доска управляется Разработчиками и отражает все элементы, которые нужно сделать, работа над которыми ведётся в данный момент и которые уже завершены в рамках текущего Спринта. Колонки доски могут называться «Сделать», «В работе», «Готово» или иметь аналогичные названия.
- В ходе Планирования Спринта все Пользовательские Истории, переходящие в Бэклог Спринта, выписываются на стикерах и помещаются в порядке приоритетов в колонке «Сделать».
- В ходе Спринта Разработчики решают, какие элементы они хотят сделать в данный момент. Они берут соответствующий стикер и перемещают его в колонку «В работе».
- Когда работа над задачей завершена, она перемещается в «Готово» (см. также Критерии Готовности).
Разработчики нередко добавляют новые колонки на свои Скрам-доски, чтобы они соответствовали этапам их работы. Именно так рекомендуется делать на Канбан-досках. Например, если команда хочет выделить этап тестирования, она может добавить колонку «Тестирование» или «Проверка» между «В работе» и «Готово».
Однако Скрам-мастер должен иметь ввиду негативные эффекты от такого расширения доски, связанные с возможным уменьшением взаимопомощи и кросс-функциональности команды. В вышеуказанном примере: тестировщики могут остаться без работы в начале спринта, будучи в конце спринта перегружены настолько, что часть элементов бэклога к концу спринта невозможно будет переместить в «Готово». Для команд, лишь недавно работающих по Скраму, рекомендуется именно 3 колонки, чтобы разработчики помогали друг другу перемещать задачи слева направо.
Некоторым Скрам-командам также бывает удобно добавлять на доску Диаграмму Сгорания Работ Спринта, чтобы любой участник команды мог увидеть прогресс работы в Спринте.
Если разработчики располагаются в одном помещении (на одном этаже офиса), лучше иметь физическую Скрам-доску. Доска должна находиться в общей зоне, где люди могут ее видеть и иметь к ней доступ. Во многих организациях доска становится более популярным местом для сборов и дискуссий, чем кулер с водой, и это создает пространство для совместной работы.
Для распределённых команд существует множество готовых программных решений (от специализированных для Scrum до универсальных: например, Trello, Miro или Mural). В специализированные виртуальные доски задач (такие как JIRA) часто встроены очень полезные фичи, которые позволяют Скрам-мастерам и Владельцам Продукта отслеживать множество метрик и помогают улучшать процессы в команде. Некоторые команды используют оба вида досок (виртуальные и физические), чтобы максимально использовать преимущества каждого из них.
Ежедневный Скрам — это встреча, которая длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. Является одним из 5 Мероприятий Скрама. В нем принимают участие все разработчики Скрам-команды.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Ежедневного Скрама:
- Цель — инспекция прогресса в достижении Цели Спринта, адаптация Бэклога Спринта по
мере необходимости и корректировка запланированной предстоящей работы. - Ежедневный Скрам улучшает коммуникации, выявляет препятствия, способствует быстрому
принятию решений и, как правило, устраняет необходимость в других встречах. - Разработчики могут выбирать любой формат для этой встречи, который сочтут нужным, при условии, что она направлена на достижение Цели Спринта и создает план работы на следующий рабочий день. Это обеспечивает фокус и улучшает самоуправление.
- Разработчикам разрешено корректировать свой план не только во время Ежедневного Скрама. Они могут встречаться в течение дня для более подробного обсуждения того, как перепланировать оставшуюся работу по текущему Спринту.
Скрам-мастер (как ответственный за процесс в Скраме) не участвует активно в Ежедневном Скраме, если он сам не является одним из Разработчиков. Однако он обучает Разработчиков достигать целей Ежедневного Скрама и при этом укладываться в 15 минут.
Чтобы соблюсти это ограничение по времени, разработчикам рекомендуется проводить Ежедневный Скрам не в форме свободной дискуссии, а выработать какой-либо удобный для себя конкретный формат и придерживаться его на каждом Ежедневном Скраме. Например, неплохо себя зарекомендовал себя формат с ответами каждого разработчика на 3 вопроса (который был приведен в качестве примера в прежних Руководствах по Scrum, но в 2020 году был удален оттуда, чтобы не ограничивать Разработчиков этим конкретным форматом):
- Что я сделал вчера, что помогло нам приблизиться к Цели Спринта?
- Что я сделаю сегодня, чтобы приблизить достижение Цели Спринта? Нужна ли мне помощь в этом?
- Вижу ли я какие-либо препятствия, которые могут помешать нам достичь Цели Спринта?
Главное — чтобы подобный формат не превратился в формальность, а действительно позволял всем видеть статус Бэклога Спринта, развивал командный дух и взаимопомощь, ускорял решение проблем.
Зачастую Ежедневный Скрам проводится вокруг Доски Спринта, которая как раз дает наглядное представление о препятствиях, которые могут помешать успешному завершению Спринта.
Лицо, дающее обратную связь Владельцу Продукта и Скрам-команде в целом по видению, Бэклогу Продукта и Инкрементам. Нередко участвует в Обзоре спринта. Зачастую является частью организации, которая разрабатывает продукт.
Инкремент более точно можно назвать «Потенциально Готовый к Поставке Инкремент Продукта». Является одним из трех Артефактов Скрама. Инкремент объединяет реализации Элементов Бэклога Продукта, сделанные во время текущего Спринта. Каждый Спринт должен включать минимум один Инкремент, чтобы считаться завершенным успешно.
Руководство по Scrum 2020 следующим образом описывает содержание и характеристики Инкремента:
- Инкремент — это конкретная ступенька к достижению Цели Продукта.
- Чтобы иметь ценность, Инкремент должен быть пригодным для использования.
- Каждый Инкремент является дополнением ко всем предыдущим. Они тщательно проверяются для обеспечения совместной работы всех Инкрементов.
- В рамках одного Спринта можно создать несколько Инкрементов.
- Совокупность Инкрементов представляется в ходе Обзора Спринта, что отражает Эмпиризм Скрама. Однако Инкремент может быть поставлен заинтересованным лицам еще до окончания Спринта. Обзор Спринта не должен считаться единственным моментом для поставки ценности.
- Работа не может считаться частью Инкремента, если она не соответствует Критериям Готовности, которые являются «commitment» (приверженностью) для Инкремента.
Один из трёх Принципов Скрама. Для своевременного выявления нежелательных отклонений участники Скрам процесса должны регулярно инспектировать (проверять) его артефакты и прогресс движения к Цели Спринта и Цели Продукта. Однако проверки не должны быть настолько частыми, чтобы мешать работе. Инспекция делает возможной адаптацию. Мероприятия Скрама спроектированы так, чтобы стимулировать как инспекцию, так и адаптацию.
Критерии Готовности — это требования качества, предъявляемые к продукту и его Инкрементам — описание того, что нужно сделать, чтобы считать завершенной работу над будущими Инкрементами и реализованными в них Элементами Бэклога Продукта.
Критерии Готовности играют роль сommitment’а для Инкремента (в русской версии Scrum Guide термин сommitment переведен абстрактным словом «приверженность»). Commitment есть у каждого из трех артефактов Скрама и способствует понятности артефакта и лучшему соответствию между артефактом и конкретной работой Скрам-команды. В частности, Критерии Готовности помогают Скрам-команде оценивать, проверять и доводить работу над Элементами Бэклога до конца.
Определение Критериев Готовности звучит похоже на Критерии Приемки, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов и Инкрементов в целом.
Руководство по Scrum версии 2020 года следующим образом описывает назначение, содержание и применение Критериев Готовности (в этой версии термин Definition of Done впервые переведен как Определение Готовности, но мы пользуемся русским переводом, сложившимся за 10 предшествующих лет):
- В момент, когда Элемент Бэклога Продукта стал соответствовать Критериям Готовности, рождается Инкремент.
- Критерии Готовности обеспечивают прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Инкремента.
- Если Элемент Бэклога Продукта не соответствует Критериям Готовности, его нельзя выпускать или даже демонстрировать на Обзоре Спринта в качестве результата. Вместо этого такой элемент возвращается в Бэклог Продукта для дальнейшего рассмотрения.
- Если Критерии Готовности для Инкрементов являются частью единых стандартов организации, все Скрам-команды должны использовать их в качестве необходимого минимума, но могут дополнять своими критериями. Если Критерии Готовности НЕ определены стандартами организации, то Скрам-команда должна создать свои Критерии Готовности, подходящие разрабатываемому продукту.
- Разработчики должны неукоснительно следовать Критериям Готовности. Если несколько Скрам-команд работают над общим продуктом, они должны совместно определить и соблюдать одни и те же Критерии Готовности.
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
I.N.V.E.S.T. – это аббревиатура, объединяющая шесть характеристик, которыми должен обладать Элемент Бэклога Продукта, чтобы соответствовать Критериям Готовности к Разработке.
- I – Independent (независимый от других)
- N – Negotiable (пригодный к обсуждению)
- V – Valuable (имеющий ценность для клиента)
- E – Estimable (пригодный к оценке трудоемкости)
- S – Small (пригодный к выполнению за один спринт)
- T – Testable (пригодный к тестированию)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Команда, имеющая все необходимые навыки, чтобы выполнять работу и не зависеть от тех, кто не является частью команды. Благодаря этому Кросс-функциональные Команды являются более гибкими, креативными и продуктивными, чем команды, где люди специализируются на одной компетенции для выполнения своей работы.
Версия продукта, позволяющая команде с минимальными затратами собрать максимум информации о клиентах и обратной связи от них.
Обзор Спринта — это одно из 5 Мероприятий Скрама, которое проводится в конце Спринта, перед Ретроспективой. В нем принимает участие вся Скрам-команда и лица, заинтересованные в продукте.
Заинтересованные лица проводят инспекцию Инкремента продукта и дают обратную связь по нему, а Скрам-команда, при необходимости, делает адаптацию Бэклога Продукта.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Обзора Спринта:
- Цель — инспекция результата Спринта и выявление возможностей для адаптации.
- Скрам-команда демонстрирует результаты своей работы ключевым заинтересованным лицам, и
обсуждает прогресс в достижении Цели Продукта. - Скрам-команда и заинтересованные лица анализируют, что было достигнуто по итогам
Спринта, и что изменилось в окружении, влияющем на продукт. На основе этой информации участники совместно решают, что делать дальше. - Бэклог Продукта может быть скорректирован с учетом новых возможностей и обнаруженных препятствий.
- Обзор Спринта — это рабочая сессия, которая НЕ сводится к презентации.
Обзор является предпоследним мероприятием Спринта и ограничен по времени максимум
четырьмя часами для одномесячного Спринта. Для более коротких Спринтов эта встреча обычно короче.
Эта встреча — своеобразная проверка: правильно ли Скрам-команда поняла, что заказывали заинтересованные лица и правильно ли они сами определили, что ему надо. Второе определяется гораздо лучше, когда команда показывает им Инкремент продукта, в идеале — дает возможность попользоваться им в режиме реального времени.
Рекомендуется, чтобы демонстрацию Инкремента проводили все или многие разработчики (а не один человек, выделенный командой для этого), чтобы повысить уровень командной ответственности, а также избежать искаженного понимания Инкремента заинтересованными лицами.
Обзор Спринта — это не отчетное мероприятие, а конструктивный и откровенный партнерский диалог между Разработчиками, Владельцем Продукта и заинтересованными лицами.
Например, Целью Спринта была форма регистрации.
- В этом случае (после краткого напоминания всем Бэклога Спринта, которое обычно делает Владелец Продукта) несложно попросить самих заинтересованных лиц зарегистрироваться/войти через новую форму и высказать свои впечатления.
- Если что-то не удобно (например, незаметна возможность восстановить забытый пароль) или чего-то не хватает (например, нет регистрации через ту социальную сеть, которая важна для целевой аудитории продукта), то Скрам-команда при активном участии Владельца Продукта предлагает, как можно отразить в Бэклоге Продукта изменения, необходимые для устранения важных замечаний.
- На эти предложения от заинтересованных лиц поступает обратная связь, обычно с указанием приоритетов: что важно (и почему важно), а что не является критичным.
- Владелец Продукта может учесть эту обратную связь добавлением в Бэклог Продукта новых элементов, а также перемещением в верхушку Бэклога важных/срочных элементов (например, интеграцию с нужной соцсетью), чтобы точно рассмотреть их на ближайшем Планировании Спринта.
Одна из пяти Ценностей Скрама. Члены Скрам-Команды берут персональную ответственность за достижение ее целей.
Одна из пяти Ценностей Скрама. Скрам-Команда вместе с заинтересованными лицами приходят к согласию о том, чтобы открыто обсуждать всю работу и возникающие при ее выполнении сложности.
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Это встреча, инициирующая Спринт и планирующая работу на этот Спринт. Является одним из 5 Мероприятий Скрама. В Планировании Спринта принимает участие вся Скрам-команда, а для консультаций могут приглашаться и другие люди.
- Владелец Продукта обеспечивает готовность участников к обсуждению наиболее важных элементов Бэклога Продукта и их связи с Целью Продукта.
- Скрам-мастер отвечает за то, чтобы Планирование Спринта состоялось, помогает всем участникам понять его цель, а зачастую и фасилитирует обсуждения на встрече.
Руководство по Scrum 2020 следующим образом описывает 3 темы и содержание Планирования Спринта.
Тема 1: Почему этот Спринт ценен?
Владелец продукта предлагает, как можно повысить ценность и практичность продукта в текущем Спринте. Затем вся Скрам-команда совместно определяет Цель Спринта, которая объясняет, почему результат Спринта будет ценен для заинтересованных лиц.
Тема 2: Что конкретно может быть сделано в этом Спринте?
Разработчики обсуждают с владельцем продукта, какие элементы Бэклога Продукта выбрать для включения в текущий Спринт. Скрам-команда может попутно уточнять эти элементы, чтобы достичь уверенности в том, что все понимают их одинаково и на уровне, достаточном для оценки этих элементов.
Оценка и основанный на ней выбор элементов, которые получится завершить за Спринт, может оказаться трудной задачей. Однако, чем больше Разработчики знают о своей прошлой Производительности, своих возможностях на следующий Спринт и своих Критериях готовности, тем более уверенно они могут прогнозировать работу, которую выполнят в ходе Спринта.
Тема 3: Как будет выполняться выбранная работа?
Для каждого выбранного элемента Бэклога Продукта, разработчики планируют работу, необходимую для создания Инкремента, соответствующего Критериям готовности. Это часто делается путем декомпозиции элементов Бэклога Спринта на более мелкие задачи продолжительностью не более одного дня. То, как это делается, остается на усмотрение разработчиков. Никто не указывает им, как превращать элементы Бэклога Продукта в Инкремент.
Цель Спринта, выбранные элементы Бэклога Продукта, а также план их реализации вместе называются Бэклогом Спринта.
Для Спринта длиной в месяц Планирование Спринта длится не более 8 часов. Для более коротких Спринтов на планирование обычно выделяется меньше времени.
Чтобы встреча была максимально короткой и все же достигла всех трех своих целей, есть следующие практические рекомендации:
- Оценка элементов Бэклога Продукта проводится в относительных единицах — Стори Поинтах, обычно через карты Покера Планирования. Это не только занимает в разы меньше времени по сравнению с оценкой трудоемкости в часах или днях, но и приводит, как ни странно, к большей точности прогнозирования — уже через несколько Спринтов работы команды.
- К моменту планирования очередного спринта верхушка Бэклога Продукта должна быть достаточно хорошо подготовлена: крупные элементы Бэклога Продукта должны быть поделены на более мелкие (пригодные к взятию в Спринт) и, желательно, оценены. Это в Scrum называется Уточнением Бэклога Продукта, а рекомендация состоит в том, чтобы это было не просто фоновой активностью некоторых участников Скрам-команды, а общей встречей. Такие встречи по Уточнению Бэклога Продукта обычно проводятся в течение нескольких недель до того, как предполагается соответствующие элементы Бэклога Продукта рассматривать на Планировании Спринта. Благодаря им, Планирования проходят намного быстрее и эффективнее.
Один из трёх Принципов Скрама. Значимые аспекты процесса и продукта должны быть доступны тем, кто отвечает за его результат. Соблюдение принципа прозрачности подразумевает, что эти аспекты объединены в общий стандарт, и все участники процесса обладают единым их пониманием.
Производительность Скрам-команды часто называют скоростью, поскольку это буквальный перевод Velocity —англоязычного термина из Scrum. Это величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Производительность является важной метрикой в Скраме и должна визуализироваться таким образом, чтобы все члены Команды могли ее видеть.
Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Стори Поинты по частично завершенным или незавершенным историям не должны участвовать в расчете производительности Команды.
Прогноз производительности должен отслеживаться в течение Спринта на основании Диаграммы Сгорания Работ Спринта. Конечно, в идеале итоговая производительность спринта должна совпасть с числом Стори Поинтов по всем задачам, запланированным на Спринт, но по факту она может отличаться как в меньшую, так и в большую сторону.
Производительность — это ключевой механизм получения обратной связи для Команды. Она позволяет оценить, как внедрённые процессные изменения повлияли на эффективность ее работы. И хотя производительность Команды от Спринта к Спринту может меняться, в среднем у хорошо функционирующих Скрам-Команд она стабильно возрастает примерно на 10% за Спринт.
Этот показатель помогает достаточно точно прогнозировать, сколько историй Команда может делать за один Спринт (в Скраме это называется Вчерашняя погода). Для расчета прогноза необходимо взять среднее значение Производительности за последние три Спринта. Это означает, что для корректного расчета производительности Команде необходимо работать в том же составе, как минимум, три Спринта, что бывает очень сложно объяснить нетерпеливым стейкхолдерам.
Без понимания Производительности невозможно планировать выпуск (релиз) продукта. Зная же Производительность, Владелец Продукта понимает, сколько Спринтов потребуется Команде, чтобы собрать функционал, готовый к поставке. В зависимости от длины Спринта, Владелец Продукта может запланировать дату релиза или понять, укладывается ли Команда в заданный свыше дедлайн.
Набор норм, практик и стратегий, которые описывают правила совместной работы членов команды.
Это одна из 3 зон ответственности в Скрам-команде. Разработчики – это люди, работающие над Элементами Бэклога Спринта. Они имеют все необходимые компетенции, чтобы каждый Спринт создавать работающий Инкремент продукта.
Разработчики:
- создают Бэклог Спринта;
- ежедневно адаптируют свой план достижения Цели Спринта;
- стремятся к качеству посредством соблюдения Критериев Готовности;
- помогают друг друг развивать свои профессиональные навыки, необходимые для разработки продукта.
Термин «Разработчики» в Скраме не связан с распространенным в бизнес-среде узким значением слова «разработчики», означающем программистов и других инженеров, занимающихся разработкой программного обеспечения.
- Даже если создается ИТ-продукт, то к Разработчикам с точки зрения Скрама относятся люди, имеющие в трудовой книжке должности аналитиков, инженеров по качеству (тестировщиков), дизайнеров, технических писателей и др.
- При разработке и поддержке продуктов, слабо связанных или совсем не связанных с разработкой ПО, к Разработчикам могут относиться любые специалисты, если они вносят свой вклад в Инкременты. Например, маркетологи будут входить в качестве Разработчиков в команду, занимающейся разработкой и поддержкой тарифов на услуги компании.
Подробнее о роли Разработчиков читайте в соответствующем разделе статьи «Scrum: что это и зачем нужно».
Ретроспектива Спринта — это одно из 5 Мероприятий Скрама, дающее Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием следующего спринта. В нем принимает участие вся Скрам-команда.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Ретроспективы:
- Цель — запланировать повышение качества и эффективности.
- Скрам-команда инспектирует то, как прошел последний Спринт в отношении людей, взаимодействий, процессов, инструментов и Критериев Готовности. Инспектируемые элементы зависят от характера выполняемой работы и могут быть очень разными.
- Выявляются предположения, которые сбили команду с пути, и исследуются их причины. Скрам-команда обсуждает, что прошло хорошо во время Спринта, с какими проблемами она столкнулась, и как эти проблемы были (или не были) решены.
- Скрам-команда определяет улучшения в процессе своей работы, наиболее полезные для повышения эффективности. Такие улучшения затем реализуются в кратчайшие сроки. Они могут даже быть
добавлены в Бэклог следующего Спринта.
Для Спринта длиной в месяц эта встреча ограничивается 3 часами. Для более коротких Спринтов она обычно короче.
Ретроспектива Спринта — командообразующая встреча, весьма непростая для проведения. Поэтому ее обычно фасилитирует Скрам-мастер. На Ретроспективе ведутся откровенные разговоры, в том числе, о неприятных вещах; проходят сложные мозговые штурмы. Если из раза в раз встреча будет оставлять чувство неудовлетворенности у команды, а ее результаты не будут реализовываться в следующих Спринтах, команда будет демотивироваться.
Типичная Ретроспектива включает ответы участников Скрам-команды на следующие вопросы:
- Что за прошедшую прошедший спринт было хорошо и помогало тебе работать?
- Что тебе мешало работать?
- Что или кто может тебе помочь работать лучше?
Эти ответы так или иначе визуализируются, а далее служат основой для генерации новых практик и правил, влияющих на процесс работы команды.
Однако если каждый раз Ретроспектива будет проходить в одном и том же формате, это быстро наскучит людям. Кроме того, далеко не всегда такие прямолинейные вопросы позволяют получать откровенные ответы и вскрывать реальные проблемы. По этим причинам Скрам-мастера стараются разнообразить формат обсуждений на Ретроспективе, используя десятки различных техник.
Варианты проведения каждого из 5 этапов ретроспективы вы можете посмотреть в этих видео:
Определение Скрама
Скрам — это фреймворк, предназначенный для решения нетривиальных задач, для эффективного и творческого создания продуктов с максимально возможной ценностью.
Руководство по Scrum 2017
”
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Руководство по Scrum 2020”
Эти слова из Scrum Guide требуют пояснений:
- Область применимости Скрама – это НЕ разовые проекты с фиксированным сроком и/или объемом работы; это «продукты», которые постоянно улучшаются во взаимодействии с клиентом. Причем Скрам нужен не для типовых задач, а для сложных продуктов, имеющих высокую степень неопределенности как в способах достижения результата, так и в востребованности результата рынком.
- Одна из целей Скрама – бизнес-ценность создаваемых продуктов. Он особенно эффективен в условиях, когда требуется быстро создавать MVP и затем быстро повышать ценность продукта на основе обратной связи от клиентов / с рынка. Но бизнес-ориентированность не означает, что в Скраме игнорируются потребности людей, которые создают продукт. Даже наоборот: исследования подтверждают, что мотивация разработчиков продуктов значительно возрастает после перехода на Скрам (в т.ч. за счет большей самостоятельности в принятии решений и за счет более творческого подхода к работе).
- Фреймворк – это набор базовых элементов – своего рода каркас, на котором могут строиться различные процессы в разных организациях и даже в разных командах одной организации. Элементы Скрама нельзя изменять, но можно дополнять, причем как именно реализуется каждый элемент – зависит от контекста конкретной команды.
- Элементы Скрама – это 5 событий (мероприятий), 3 зоны ответственности (которые присваиваются участникам Скрам-команды независимо от их должностей) и 3 артефакта (материальные представления работ и их результатов).
Особенности Скрама
Scrum — прост. …
Фреймворк Scrum намеренно неполный, и определяет только части, необходимые для реализации теории Scrum.
Руководство по Scrum 2020”
В отличие от многих методологий разработки программного обеспечения, которые детально описывают процесс разработки на десятках страниц, в Скраме по сути нет ничего кроме вышеуказанных элементов и связывающих их немногочисленных правил. Скрам не вводит сложных схем взаимодействия, не диктует, каким именно должен быть ваш процесс разработки, и что именно нужно делать людям.
Scrum не предоставляет людям подробных инструкций, а вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей.
Руководство по Scrum 2020”
В частности, в Скраме отсутствуют конкретные рекомендации по техникам проведения скрам-мероприятий. Например, до 2020 года в Руководстве по Скраму в качестве примера приводился конкретный формат проведения мероприятия «Ежедневный Скрам» (с ответами каждого участника на 3 вопроса). Если команда не понимала ценностей Agile и Scrum, то этот формат зачастую приводил к бессмысленному механическому ритуалу проведения Ежедневного Скрама, поэтому его убрали даже как пример.
Скрам-команда
Вот, пожалуй, главная особенность Скрама в сравнении с другими подходами, следующими ценностям Agile-манифеста:
Основная единица Scrum — небольшая команда людей, Scrum Team. … Scrum Teams являются кросс-функциональными, то есть, их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть, сами решают, кто, что, когда и как делает.
Руководство по Scrum 2020”
Именно c самоуправлением и кросс-функциональностью связан тот факт, что Скрам, несмотря на всю его простоту, достаточно сложно применять на практике. Откуда возникает потребность в самоуправлении/кросс-функциональности и как она реализуется в Скраме для IT-команд — рекомендуем посмотреть в 10-минутном видео от Асхата Уразбаева:
А в статье «От контроля к самоорганизации в команде» вы можете найти перечень проблем, с которыми сталкиваются команды на пути к самоуправлению, и рецепты для руководителей о том, как эти проблемы решать.
Скрам – эмпирический подход к управлению
Скрам основывается на эмпирическом управлении процессами, а не на детерминированном. Эмпиризм означает, что процесс адаптируется к данным, получаемым в ходе работы. Очевидно, процесс с эмпирическим управлением всегда дороже, чем обычный процесс с детерминированным управлением. Поэтому детерминированный подход применяется всегда, когда механизмы процесса достаточно хорошо понятны. Если же механизмы плохо известны, детерминированный подход не приводит к продукту с необходимым соотношением «цена / качество» с первого раза, и продукт приходится переделывать.
В конечном счете создание успешных продуктов с первого раза, используя эмпирическое управление процессом, окажется намного дешевле переделки неудачных продуктов, созданных по процессу с детерминированным управлением.
Скрам. Гибкое управление продуктом и бизнесом (Кен Швабер, 2004)”
Скрам сегодня – это не только про разработку программного обеспечения
- Остатки IT-терминологии из него были удалены в Scrum Guide 2020 (например, тестирование, требования, проектирование, система).
- При этом по факту еще в 2010-х годах Скрам вышел далеко за рамки ИТ-индустрии. Он успешно применяется командах маркетологов, дизайнеров, разработчиков материальной продукции; в розничной торговле, энергетике, промышленном проектировании/производстве и многих других отраслях.
- Подробнее про применение Скрама в не-ИТ отраслях можно прочитать в исследовании Agile в России 2019.
Связь Скрама с другими подходами
Фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткой для существующих практик, или подсвечивает их ненужность.
Руководство по Scrum 2020”
В частности, в рамках Скрама нередко применяются элементы метода Канбан. Однако важно подчеркнуть, что если происходит скрещивание этих двух подходов, сопровождающееся отказом от каких-либо мероприятий Скрама, то такой процесс должен называться иначе.
Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом.
Руководство по Scrum”
Например, «давно работающие по Аgile» команды могут переходить со Скрама на какой-то собственный скрамоподобный процесс или на Scrumban. При этом они уменьшают время, затрачиваемое на мероприятия Скрама, получают возможность изменять длительность итерации (спринта) по ходу работы или даже отказываются от оценок работы на спринт, используя безоценочное (no estimate) планирование на основе собранной статистики. Для зрелых команд это полезно, но это не Скрам.
Однако для начинающих Agile-команд Скрам является отличным выбором, так что неудивительно, что этот фреймворк является самым популярным среди гибких подходов как в России, так и во всем мире.
Резюме: как описать Скрам простыми словами
Если обойтись почти без англицизмов, то вышесказанное можно сформулировать так:
- Скрам выгодно применять не для типовых проектов, а для новых сложных продуктов, требования к которым заранее не определены и быстро меняются под влиянием обратной связи с рынка. В том числе, Скрам предназначен для продуктов, не относящихся к разработке ПО.
- Скрам задает лишь основу (каркас) для ваших процессов разработки, т.е. его можно дополнять, а его обязательные элементы реализовывать по-разному в разных ситуациях.
- Скрам как эмпирический подход регулярно адаптирует продукт и процесс его разработки на основе быстрой обратной связи. Это приводит к дополнительным издержкам. Однако издержки с лихвой компенсируется тем, что продукты начинают зарабатывать намного быстрее, а их бизнес-ценность получается выше по сравнению с продуктами, созданными по заранее придуманным требованиям, которые не учитывали обратную связь от клиентов.
- Скрам прост для понимания: содержит всего дюжину обязательных элементов (мероприятий, артефактов и зон ответственности).
- Скрам сложен для освоения в совершенстве. Это связано, прежде всего, с нетипичной для большинства организаций структурой: Скрам требует делить людей на небольшие команды, которые могут без посторонней помощи разрабатывать продукт, а также самостоятельно решают, как именно это делать.
- Скрам является самым популярным среди «гибких» подходов, объединяемых словом Agile.
Подробнее о Скраме вы можете почитать в статье Scrum: что это и зачем нужно.
Понимаете ли вы Скрам?
Ответьте на 8 вопросов теста по Agile/Scrum, получите подборку ссылок на статьи/видео/курсы и рекомендации в зависимости от результата теста.
Основа Скрама — небольшая команда людей, Скрам-команда. Она состоит из одного Скрам-мастера, одного Владельца Продукта и Разработчиков. Внутри Скрам-команды нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели — Цели Продукта.
Скрам-команда достаточно маленькая, чтобы оставаться проворной — обычно состоит не более чем из 10 человек. И при этом она достаточно большая, чтобы выполнять значительную работу в течение Спринта. В целом, небольшие команды более эффективно общаются и более продуктивны. Если Скрам-команда становится слишком большой, ей следует рассмотреть возможность реорганизации в несколько сплоченных Скрам-команд, которые сфокусированы на одном и том же продукте. Следовательно, у них должна быть та же Цель Продукта, тот же Бэклог Продукта и тот же Владелец Продукта.
Скрам-команды являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Спринте. Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает. Они уполномочены организацией на то, чтобы управлять своей собственной работой.
Скрам-команды выполняет все активности по продукту: сотрудничество с заинтересованными лицами, верификацию, обслуживание, эксплуатацию, эксперименты, исследования, разработку и все то, что может потребоваться. Вся Скрам-команда несет ответственность за создание ценного, полезного Инкремента в каждом Спринте.
Это одна из 3 зон ответственности в Скрам-команде. Скрам-мастер является лидером-слугой (Servant Leader) для Скрам-команды и для организации в целом. Помогает всем понять теорию и практики Scrum, обучает команду устранять препятствия, является коучем команды и фасилитирует Мероприятия Скрама. Фактически является владельцем процесса, ответственным за эффективную работу Скрам-команды.
Скрам-мастер несет ответственность за то, чтобы применение Скрама соответствовало Руководству по Scrum. Он делает это, помогая Скрам-команде улучшать свои методы работы в рамках Скрама.
Руководство по Scrum 2020 следующим образом описывает функции Скрам-мастера.
Для Скрам-команды:
- коучит участников команды с целью развития самоуправления и кросс-функциональности;
- помогает команде фокусироваться на создании Инкрементов с высокой ценностью, соответствующих Критериям Готовности;
- способствует устранению препятствий, мешающих прогрессу Скрам-команды;
- убеждается в том, что все Мероприятия Скрама происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени.
Для Владельца продукта:
- помогает находить техники эффективного определения Цели Продукта и управления Бэклогом Продукта;
- помогает осознать необходимость четких и лаконичных элементов Бэклога Продукта;
- помогает применять эмпирическое планирование продукта в комплексной среде;
- фасилитирует взаимодействие с заинтересованными лицами по запросу или при необходимости.
Для организации в целом:
- направляет, обучает и коучит организацию во всем, что касается Скрама;
- планирует переход на Скрам, участвует во внедрении и консультирует по вопросам применения Скрам в данной организации;
- помогает сотрудникам и заинтересованным лицам понять и применять эмпирический подход к комплексной работе;
- устраняет барьеры между заинтересованными лицами и Скрам-командами.
Подробнее о роли Скрам-мастера читайте в статьях:
Одна из пяти Ценностей Скрама. Члены Скрам-Команды имеют смелость действовать правильно и решать сложные проблемы.
Спринты — это короткие регулярные циклы работы длиной не более четырех недель. Спринты должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Первые Скрам-команды работали Спринтами длиной в месяц, сейчас же большинство команд работают одно- или двух-недельными циклами. Следующий Спринт начинается сразу же по окончании предыдущего.
Спринт включает в себя остальные 4 Мероприятия Скрама. Спринт начинается с Планирования и завершается Обзором и Ретроспективой. Каждый день Спринта проводится краткая встреча, которая называется «Ежедневный Скрам», или просто стендап (Stand-Up), на которой все участники стоят, чтобы встреча была максимально короткой.
Что важно:
- Спринт работает на выполнение Цели Спринта. В результате появляется потенциально готовый к поставке Инкремент Продукта: например, готовая к использованию версия программного обеспечения или иной артефакт, который непосредственно несет ценность для клиента.
- Спринт даёт Скрам-команде регулярную качественную обратную связь по поставленной ценности. Благодаря этому команда может проводить инспекцию и адаптацию своего продукта и процессов на основании реальной информации от клиентов.
- Спринт позволяет измерять результаты команды, полученные за идентичные периоды времени. Это называется Производительностью (или Скоростью) команды. Команда может использовать эту метрику для оценки успешности проводимых ею процессных изменений.
Спринт начинается и завершается в заранее определенные даты. Его продление не допускается. Не допускаются также никакие изменения в Бэклоге Спринта, которые ставят под угрозу достижение Цели Спринта. Команда не берет в рамках Спринта никакую дополнительную работу, пока Цель Спринта не будет достигнута, или же если эта работа несёт столь большую ценность, что просто обязана быть в этом Спринте.
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Ниже — перевод статьи Джеффа Сазерленда Story Points: Why are they better than hours? с сайта Scrum Inc.
Чем Стори Поинты лучше человеко-часов?
Стори поинты дают более точную оценку, существенно уменьшают время планирования, позволяют лучше прогнозировать дату релиза и повышают производительность команд. Традиционная оценка в человеко-часах является менее точной, приводит к лишним потерям времени на оценку, мешает Владельцу Продукта планировать релиз и не позволяет команде понять, какие из внедренных улучшений процесса действительно сработали.
Точность оценок
Последние исследования от Microsoft показывают, что оценка по agile демонстрирует поразительную точность в сравнении с традиционными методами оценки проектов. Подробнее об этом исследовании вы можете почитать здесь:
Scrum + Engineering Practices: Experiences of Three Microsoft Teams
Многим людям, имевшим опыт управления проектами с оценкой в часах, сложно понять, почему стори поинты работают лучше. Им также сложно принять некоторые фундаментальные факты, которые публикуются в профильной литературе уже в течение 60 лет, равно как и последние исследования, которые только подтверждают их правильность.
Успешность проектов
Давайте посмотрим на последние данные по неуспешным проектам. Глобальная финансовая система рушится, и вместе с этим растет процент провальных проектов в IT. Недавно было проведено одно интересное исследование: консалтинговая фирма Standish Group собрала данные об успешности нескольких десятков тысяч проектов, стартовавших за последние десять лет. Аналитика от Standish Group показывает, что процент успешности agile-проектов в три раза превышает успешность проектов, ведущихся традиционным образом. Джим Джонсон рекомендует использование agile-практик на всех без исключения проектах.
Также последние исследования Forrester Group говорят, что традиционные метрики управления проектами приводят IT-департаменты к неудачам.
Разрыв между оценками сроков и реальностью
Венчурные капиталисты, с которыми я работаю, признаются, что никогда не видели актуальную диаграмму Ганта на встречах правления компаний. Исследуя проблему глубже, они обнаружили, что до внедрения скрама никто из руководства вообще не знал реальной производительности своих команд, и это в 100% случаев озвучивается на встречах правления как главная причина несоблюдения даты релиза.
Дело в том, что для планирования релиза критичным является постоянство пользовательских историй. Три стори поинта сегодня — это те же три стори поинта в следующем году, и для Владельца Продукта эти стори поинты являются измеримой частью релиза продукта. Тогда как количество часов для завершения истории зависит от того, кто ее делает и в какой день. Эти показатели меняются ежедневно. Диаграмма Ганта предполагает фиксированное количество часов на задачу для какого-то гипотетического человека (который зачастую не является фактическим исполнителем задачи) и заведомо известные зависимости (которые на самом деле непрерывно меняются). Исследование восьмидесяти мультимиллионных проектов, проведённое в GSI Commerce (ими сейчас владеет eBay), показало, что лучшие эксперты в компании оказались неспособными правильно оценить время выполнения проекта людьми, которые действительно его реализовывали.
Вам может показаться, что эта статистика могла бы заставить людей поменять своё поведение, но многим компаниям, похоже, проще продолжать терпеть убытки или даже банкротство вместо того, чтобы изменить свои принципы управления проектами.
Вариабельность оценок
Исследование, проведенное Rand Corporation еще в 1940х годах, очевидно продемонстрировало неспособность людей точно проводить оценку в часах, и практический опыт постоянно подтверждает этот факт. Вместо часов для оценки рекомендуется использовать метод «Дельфи», известный в разработке программного обеспечения как техника Wide Band Delphi. Аналогичная техника используется agile-командами и носит название Покер планирования.
Интересные данные по личной продуктивности разработчиков пришли из Йельского Университета. Лучшему разработчику на проекте требуется один час, чтобы сделать задачу, в то время как худшему требуется 10 часов (в рамках его проекта) или даже 25 (если проект незнакомый). Для команд эта разница еще на порядок больше. Данные, опубликованные Ларри Путнемом (Larry Putnam) показывают, что задача, на которую наиболее продуктивной команде требуется час, может превратиться в 2000 часов для наименее продуктивной команды.
Процесс оценки в стори поинтах дает лучшую точность, чем оценка в часах, за счет меньшей вариативности стори пойнтов. Одна компания 5го уровня CMMI определила, что оценка в стори поинтах сокращает время оценки на 80%, что позволяет оценивать больше фич и отслеживать их, в сравнении с каскадной моделью. Другая компания из телеком индустрии заметила, что оценка с помощью стори поинтов и Покера планирования была не только в 48 раз быстрее, чем практики каскадной оценки, но и дала более точные результаты.
Мера прогресса
Для руководства мерой прогресса является законченный функциональный элемент, поэтому важно, чтобы каждая поставка была новым шагом на этом пути. Рабочий функционал является предусловием для получения прибыли, а ведь любая компания создается для увеличения прибыли (даже если при планировании проекта неосознанно делается прямо противоположное). По крайней мере, венчурные капиталисты уверены в том, что компании работают ради денег, и для денег важны скорость производства и качественный продукт. А человеко-часы — это затраты, которые необходимо уменьшать или вообще избавляться от них везде, где это возможно.
Число потраченных часов не дает Владельцу Продукта никакой информации о том, сколько фич можно поставить и когда.
Что действительно является важной метрикой, так это количество стори поинтов, которую команда может поставить за календарный период. Число поинтов за спринт — это производительность команды (velocity). И несмотря на то что все оценки происходят в стори поинтах, Владелец Продукта делает план релизов на основании производительности команды и корректирует его, если эта производительность меняется.
Таким образом, стори поинты быстрее, лучше и дешевле часов, и высокоэффективные команды повсеместно отказываются от оценок в часах как от лишней нагрузки, которая замедляет их и тянет вниз.
Jeff Sutherland, 2013
От редактора: обратите внимание на антипаттерн скрам-команд, связанный со стори поинтами и оценкой задач в целом.
Одна из пяти Ценностей Скрама. Каждый участник Скрам-Команды фокусируется (сосредотачивается) на работе Спринта и целях Команды в целом.
Одна из пяти Ценностей Скрама. Члены Скрам-Команды уважают профессионализм и самостоятельность друг друга.
Уточнение Бэклога Продукта — это активность, которая проводится Владельцем Продукта при участии всех членов Скрам-команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
В русском жаргоне адептов Скрама для этой практики прижилось название Груминг Бэклога (а также такие переводы слова Grooming как Уход за бэклогом и Причесывание бэклога). Это связано с тем, что в Scrum Guide до 2013 года использовался термин Grooming, а не Refinement.
В Скраме рекомендуется от 5 до 10 процентов времени каждого Спринта выделять на Уточнение Бэклога Продукта. Этот процесс включает:
- Анализ уточненных требований
- Декомпозицию: разделение крупных элементов на более мелкие (от Эпиков к Пользовательским Историям)
- Оценку новых элементов
- Переоценку существующих элементов
Уточнение Бэклога Продукта проводится не для того, что уже взято в работу в текущем спринте, а для будущих спринтов. Хорошей практикой считается иметь в Бэклоге Продукта детально проработанные элементы как минимум на два Спринта вперёд. В этом случае Планирование Спринта существенно упрощается, поскольку Владелец Продукта и Скрам-Команда начинают планирование с понятным, прошедшим этап анализа и аккуратно оцененным набором пользовательских историй. Если же груминг Бэклога не был проведён (или был проведён недостаточно хорошо), Планирование Спринта растянется во времени, вызовет большое количество вопросов, потребует уточнений и/или выявит несоответствия.
Для пользовательских историй существует два критически важных этапа: «Готово к разработке» и «Сделано». Для них должны быть, соответственно, критерии готовности к разработке (Definition of Ready) и Критерии готовности (критерии завершения работы над историей, Definition of Done). И Уточнение Бэклога — это процесс или встреча, в ходе которого Владелец Продукта удостоверяется в том, что пользовательские истории «Готовы к разработке», то есть команда может немедленно взять их в работу и перевести их в «Сделано».
Цель Продукта — это долгосрочный ожидаемый результат Скрам-команды. Команда должна достичь этой цели (или отказаться от нее), прежде чем приступить к следующей.
Продукт — это средство доставки ценности. У него есть четкие границы, известные заинтересованные лица, четко определенные пользователи или клиенты. Продукт может быть услугой, физическим продуктом или чем-то более абстрактным.
Руководство по Scrum 2020”
См. также подробное описание: что такое продукт.
Цель Продукта описывает будущее состояние продукта, которое может выступать в качестве конечной цели, используемой Скрам-командой при планировании работы. Это помогает отказываться от ненужной работы, которая никак не связана с Целью Продукта.
Цель Продукта входит в состав Бэклога Продукта и играет в нем роль сommitment’а (в русской версии Scrum Guide термин сommitment переведен абстрактным словом «приверженность»). Commitment есть у каждого из трех артефактов Скрама и способствует понятности артефакта и лучшему соответствию между артефактом и конкретной работой Скрам-команды.
А остальная часть Бэклога Продукта нужна, чтобы понять: «что конкретно» будет способствовать достижению Цели Продукта.
Цель Спринта — единственная цель работы на Спринт, она создается во время Планирования Спринта и описывает то, для чего создаётся Инкремент Продукта.
Цель Спринта также обеспечивает связность и сфокусированность, побуждая Скрам-команду работать совместно, а не поодиночке выполнять отдельные задачи.
Цель Спринта входит в состав Бэклога Спринта и играет в нем роль сommitment’а (в русской версии Scrum Guide термин сommitment переведен абстрактным словом «приверженность»). Commitment есть у каждого из трех артефактов Скрама и способствует понятности артефакта и лучшему соответствию между артефактом и конкретной работой Скрам-команды.
Разработчики должны помнить о Цели спринта в ходе работы над задачами Спринта. Если работа не соответствует Цели Спринта, Разработчики взаимодействуют с Владельцем Продукта, чтобы пересмотреть содержание Бэклога Спринта в ходе текущего Спринта, не поставив под угрозу Цель Спринта.
Несмотря на то, что Разработчики привержены Цели Спринта, она все же дает им гибкость с точки зрения выбора конкретных работ, необходимых для ее достижения.
Элемент Бэклога представляет собой часть работы, которую планируется сделать с учетом знаний, имеющихся на данный момент.
Элемент Бэклога Продукта – изменение, которое планируется выполнить в следующих Инкрементах продукта (например, фичи, функции, требования, усовершенствования или информация по исправлению дефектов). Элементы, расположенные в верхней части Бэклога Продукта, обычно более понятны и содержат больше деталей, чем те, что расположены ниже.
Скрам основывается на теории управления эмпирическими процессами – эмпиризме. Согласно этой теории, знания приобретаются опытным путем, а решения принимаются на основе реальных данных. Скрам использует итеративно-инкрементальный подход для повышения предсказуемости и управления рисками. В основе эмпиризма лежат три главных принципа: прозрачность, инспекция и адаптация.