Тема 17. Scrum

1.

Тема 3. Scrum

2.

Что такое «SCRUM»
Термином “scrum” в регби обозначается один из элементов игры,
когда игроки двух команд после нарушения правил или
приостановки игры собираются вместе, сцепляются друг с другом и с
командой-соперником и ждут вброса мяча «девяткой» — игроком
команды под номером девять (scrum half). Это первоначальное
состояние, после которого та или иная команда овладевает мячом, и
начинается игра
Компании все больше понимают, что старый,
последовательный подход к разработке новых продуктов
просто не помогает достигать цели. Вместо этого компании
в Японии и США используют целостный (холистический)
метод: как и в регби, мяч передается [между игроками]
внутри команды, в то время, когда она движется по
полю, как единое целое
Harvard Business Review,The New New Product
Development Game, 1986

3.

История
Джефф Сазерленд вместе с коллегами впервые применил Scrum
для разработки систем в 1993 году, во время работы в Easel
Corporation. Перед ними стояла почти невыполнимая задача — за 6
месяцев создать работающую замену существующему продукту.
Придуманный Scrum-процесс позволил успешно завершить проект
в срок, в рамках бюджета и с небывало низким количеством багов.
Позже Джефф Сазерленд объединил свои усилия с Кеном
Швабером для формализации и окончательной доработки подхода
Первая версия Scrum была создана под сильным влиянием идей
Элияху Голдратта, Теории ограничений и бережливого подхода. По
словам Джеффа Сазерленда, основной фокус делался на поиске и
устранении потерь, описанных в производственной системе Тойта
(TPS): “мури”, “мура” и “муда”
В октябре 1995 года на конференции OOPSLA (“Object-Oriented
Programming, Systems, Languages & Applications”) в Остине, штат
Техас, Кен Швабер и Джефф Сазерленд впервые представили
Scrum в своем докладе дали первое описание Scrum-процесса
Jeff Sutherland
Ken Schwaber

4.

Назначение SCRUM
Scrum предназначен для быстрой разработки и поставки сложных,
принципиально новых продуктов, которых нет на рынке.
Когда зрелого продукта еще нет, а есть только идея и, может быть, первые
рабочие прототипы, тогда никто не может дать четкий план, куда должна
пойти траектория разработки. Все неопределенно и требует проверки на
реальном клиенте. А Scrum позволяет постепенно «развеять» эту пелену
неопределенности, двигаясь небольшими итерациями и постоянно
проверяя: мы делаем то, что нужно клиентам? приносит ли это пользу?

5.

6.

Три кита
1. Прозрачность
Терминология, имеющая отношение к процессу, должна быть понятна всем
участникам
Понимание Критериев Готовности должно быть общим между
исполнителями работ и теми, кто ее результаты принимает
2. Инспекция
Участники процесса должны регулярно инспектировать артефакты Скрама и
прогресс движения к Цели Спринта, что необходимо для своевременного
обнаружения нежелательных отклонении. Частота проведения проверок не
должна мешать работе
3. Адаптация
При обнаружении отклонений от допустимых пределов одного или
несколько элементов процесса или продукта, следует внести
соответствующие изменения. Это могут быть как изменения самого процесса,
так и материалов, используемых в нем. Чем раньше будут внесены
изменения, тем меньше риск дальнейших отклонений.

7.

Ценности
1.
Преданность (целям команды)
2.
Смелость (принимать сложные решения)
3.
Сфокусированность (на целях команды и работе по их
достижению)
4.
Открытость (между заинтересованными лицами и командой
относительно всей работы и возникающих трудностей)
5.
Уважение (профессионализма и самостоятельности друг друга)

8.

Роли SCRUM
Product Owner
Управляет
backlog продукта
Команда разработки
Scrum Master
Помогает команде
следовать
принципам Scrum

9.

Product owner
Отвечает за формирование Product Vision
Управляет ожиданиями заказчиков и всех
заинтересованных лиц
Координирует и приоритизирует Product Backlog
Предоставляет понятные требования команде
Взаимодействует с командой и заказчиком
Отвечает за приемку в конце каждой итерации
Ставит задачи команде, но не вправе ставить задачи
конкретному члену проектной команды в течение
спринта
Отвечает за бюджет

10.

SCRUM Master
Создает атмосферу доверия
Участвует в митингах в качестве фасилитатора
Устраняет препятствия
Делает проблемы и открытые вопросы видимыми
Отвечает за соблюдение практик и процесса в команде
Ведет Daily Scrum Meeting и отслеживает прогресс работы команды (не
всегда)
Никаких директив
Коуч команды
Лидер - слуга

11.

Dev Team
Отвечают за оценку элементов бэклога
Принимает решение по дизайну и реализации
Разрабатывает софт и предоставляет его заказчику
Отслеживает собственный прогресс
Отвечает за результат перед PO
Типичный размер команды 7 ± 2
Нет заранее определенных и поделенных ролей

12.

Артефакты SCRUM
Product Backlog – приоритезированный список имеющихся на данный
момент бизнес-требований и технических требований
Sprint Backlog – содержит список требований, выбранную для
реализации спринта
Инкремент – выполненная работа, принятая PO, поставленная и
добавляющая ценность

13.

Product Backlog
Бэклог продукта состоит из бизнестребований, которые часто оформляются в
виде пользовательских историй или иных
описаний
Чем ближе спринт, тем задачи в бэклоге
должны быть более дателизированными
Детализация задач выполняется в рамках
событий уточнения бэклога (PBR) и
планирования спринта

14.

События SCRUM
Уточнение Бэклога Продукта [Груминг Бэклога] (Product Backlog
Refinement)
Планирование Спринта (Sprint Planning)
Спринт (Sprint)
Ежедневный Скрам (Daily Scrum)
Обзор Спринта (Sprint Review)
Ретроспектива Спринта (Sprint Retrospective)

15.

Уточнение Бэклога Продукта [Груминг
Бэклога] (Product Backlog Refinement)
Уточнение Бэклога Продукта — это активность, которая проводится
Владельцем Продукта при участии всех членов Скрам-команды. Включает
добавление деталей, оценку и упорядочивание элементов в Бэклоге
Продукта.
В Скраме рекомендуется от 5 до 10 процентов времени каждого Спринта
выделять на Уточнение Бэклога Продукта. Этот процесс включает:
Анализ уточненных требований
Декомпозицию: разделение крупных элементов на более мелкие (от
Эпиков к Задачам)
Оценку новых элементов
Переоценку существующих элементов

16.

Уточнение Бэклога Продукта [Груминг
Бэклога] (Product Backlog Refinement)
Хорошей практикой считается иметь в Бэклоге Продукта детально
проработанные элементы как минимум на два Спринта вперёд.
Количество проработанных задач, выставляемых на планирование
должно быть большим количества задач, которые передаются на
планирование. В процессе планирования не все задачи могут быть
взяты в работу командой (не пройдут критерий Definition of Ready
(DOR)
К моменту планирования очередного спринта верхушка Бэклога Продукта
должна быть достаточно хорошо подготовлена: крупные элементы Бэклога
Продукта должны быть поделены на более мелкие (пригодные к взятию в
Спринт) и, желательно, оценены.

17.

Критерий готовности к разработке
(Definition of Ready (DOR))
Описание критериев готовности Элементов к разработке должно быть таким, чтобы для
выполнения работы команде не требовалось дополнительных обсуждений и
исследований. Такие Элементы можно принять в работу немедленно (они 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 (пригодный к тестированию)

18.

Планирование спринта

19.

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

20.

Планирование спринта
Тема 1: Почему этот Спринт ценен?
Владелец продукта предлагает, как можно повысить ценность и
практичность продукта в текущем Спринте. Затем вся Скрам-команда
совместно определяет Цель Спринта, которая объясняет, почему результат
Спринта будет ценен для заинтересованных лиц.
Тема 2: Что конкретно может быть сделано в этом Спринте?
Разработчики обсуждают с владельцем продукта, какие элементы Бэклога
Продукта выбрать для включения в текущий Спринт. Скрам-команда
может попутно уточнять эти элементы, чтобы достичь уверенности в том,
что все понимают их одинаково и на уровне, достаточном для оценки этих
элементов.

21.

Планирование спринта
Тема 3: Как будет выполняться выбранная работа?
Для каждого выбранного элемента Бэклога Продукта, разработчики
планируют работу, необходимую для создания Инкремента,
соответствующего Критериям готовности. Это часто делается путем
декомпозиции элементов Бэклога Спринта на более мелкие задачи
продолжительностью не более одного дня. То, как это делается, остается
на усмотрение разработчиков. Никто не указывает им, как превращать
элементы Бэклога Продукта в Инкремент

22.

Оценка элементов бэклога
1- очень легко
13 – очень сложно
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрамкоманды обычно используют Стори Поинты. Это условная величина,
позволяющая давать Элементам Бэклога относительные веса. Чаще всего
для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8,
13, …), что позволяет провести оценку достаточно быстро
Многие исследования доказывают, что оценка в Стори Поинтах
эффективнее оценки в человеко-часах

23.

Оценка элементов бэклога
T-Shirt Sizes (Размеры футболки)
В качестве единицы измерения в этой технике
используется размер футболки: XS, S, M, L, XL.
Команда принимает решение о размере той или иной
задачи в ходе совместной открытой дискуссии.
Данная техника является довольно быстрой и ее можно
использовать для оценки большого количества задач за
одну сессию. С ее помощью вполне реально за час
оценить 15-20 историй
Иногда техника применяется для оценки долгосрочного
планирования

24.

Оценка элементов бэклога
Planning Poker (Покера планирования)
Это одна из самых популярных техник оценки.
Участники процесса используют специально
пронумерованные карты (подобные игральным), чтобы
голосовать с их помощью за оценку задачи. Обычно для
«покера» используются карты с числами Фибоначчи (0,
1, 2, 3, 5, 8, 13, 21, 34, 55, 89), но возможны и другие
варианты
Planning Poker одна из самых точных техник оценки, но
подходит для сравнительно небольшого количества
задач. В течение часовой сессии таким способом можно
оценить 4-10 историй

25.

Оценка элементов бэклога
Planning Poker (Покера планирования)
Процесс оценки выглядит следующим образом:
Каждый участник получает колоду карт с числовыми значениями
для оценки, изображением «?» (запрос уточнения задачи) и
«чашки кофе» (требование перерыва).
Product Owner делает краткий анонс очередной задачи и отвечает
на вопросы команды по данной задаче.
Участники «покера» выбирают карту с подходящей по их мнению
оценкой и кладут их рубашкой вверх (чтобы не влиять на выбор
друг друга).
После того, как все члены команды выбрали свои оценки карты
одновременно переворачиваются.
Участникам с самыми низкими и высокими оценками делают
краткие комментарии объясняя свой выбор оценки.
В итоге процесса обсуждения команда приходит к единому
решению и после этого переходит к следующей задаче
Если вы работаете в удаленном формате, то оценки можно писать в
общий чат совещания (Zoom, Voov, WebEx,…)

26.

Производительность команды
[Скорость](Velocity)
Это величина, отражающая количество работы, которое
Скрам-команда может выполнить за один Спринт.
Производительность является важной метрикой в Скраме и
должна визуализироваться таким образом, чтобы все члены
Команды могли ее видеть.
Производительность вычисляется в конце Спринта как
сумма Стори Поинтов по всем полностью завершенным
Элементам Бэклога Спринта. Стори Поинты по частично
завершенным или незавершенным историям не должны
участвовать в расчете производительности Команды
Прогноз производительности должен отслеживаться в
течение Спринта на основании Диаграммы Сгорания Работ
Спринта.

27.

Производительность команды
[Скорость](Velocity)
Производительность — это ключевой механизм получения обратной связи для
Команды. Она позволяет оценить, как внедрённые процессные изменения повлияли на
эффективность ее работы. И хотя производительность Команды от Спринта к Спринту
может меняться, в среднем у хорошо функционирующих Скрам-Команд она стабильно
возрастает примерно на 10% за Спринт
Этот показатель помогает достаточно точно прогнозировать, сколько задач Команда
может делать за один Спринт. Для расчета прогноза необходимо взять среднее
значение Производительности за последние три Спринта.
Оценка производительности команды позволяет команде брать в спринт столько задач,
сколько команда реально сможет сделать
Без понимания Производительности невозможно планировать выпуск (релиз) продукта.
Зная же Производительность, Владелец Продукта понимает, сколько Спринтов
потребуется Команде, чтобы собрать функционал, готовый к поставке. В зависимости от
длины Спринта, Владелец Продукта может запланировать дату релиза или понять,
укладывается ли Команда в заданный свыше дедлайн

28.

Цель спринта
Цель Спринта — единственная цель работы на Спринт, она
создается во время Планирования Спринта и описывает
то, для чего создаётся Инкремент Продукта.
Цель Спринта также обеспечивает связность и
сфокусированность, побуждая Скрам-команду работать
совместно, а не поодиночке выполнять отдельные задачи
Наличие цели Спринта позволяет команде сфокусироваться
на достижении данной цели. Например, если команда не
успевает сделать все задачи спринта, то в первую очередь
команда должна закрывать задачи, приближающие команду
к цели спринта
Разработчики должны помнить о Цели спринта в ходе
работы над задачами Спринта. Если работа не
соответствует Цели Спринта, Разработчики
взаимодействуют с Владельцем Продукта, чтобы
пересмотреть содержание Бэклога Спринта в ходе текущего
Спринта, не поставив под угрозу Цель Спринта

29.

Спринт
Итерация (1-4 недели)
Результат спринта – готовый продукт (build)
Короткие спринты обеспечивают быстрый feedback
Каждый спринт – маленький «водопад»
Список задач на спринт фиксирован. Команда не берет в рамках Спринта никакую
дополнительную работу, пока Цель Спринта не будет достигнута, или же если эта
работа несёт столь большую ценность, что просто обязана быть в этом Спринте
Спринт начинается с Планирования и завершается Обзором и Ретроспективой.
Каждый день Спринта проводится краткая встреча, которая называется «Ежедневный
Скрам», или просто стендап (Stand-Up), на которой все участники стоят, чтобы
встреча была максимально короткой
Спринт начинается и завершается в заранее определенные даты. Его продление не
допускается.

30.

SCRUM доска
Это инструмент визуализации Элементов Бэклога Спринта на
протяжении Спринта. Доска управляется Разработчиками и
отражает все элементы, которые нужно сделать, работа над
которыми ведётся в данный момент и которые уже завершены в
рамках текущего Спринта. Колонки доски могут называться
«Сделать», «В работе», «На проверке», «Готово»
В ходе Планирования Спринта все задачи, переходящие в Бэклог
Спринта, выписываются на стикерах и помещаются в порядке
приоритетов в колонке «Сделать» (To Do).
В ходе Спринта Разработчики решают, какие элементы они хотят
сделать в данный момент. Они берут соответствующий стикер и
перемещают его в колонку «В работе» (In Progress).
Когда работа над задачей завершена, она перемещается в колонку
«На проверке» (Testing) и потом в «Готово» (Done)

31.

Ежедневный Скрам
(Daily Scrum)
Ежедневный Скрам — это встреча, которая длится не более
пятнадцати минут и проводится каждый рабочий день в
одном и том же месте в одно и то же время. В нем
принимают участие все разработчики Скрам-команды.
Цель — инспекция прогресса в достижении Цели Спринта,
адаптация Бэклога Спринта по
мере необходимости и корректировка запланированной
предстоящей работы
Ежедневный Скрам улучшает коммуникации, выявляет
препятствия, способствует быстрому
принятию решений и, как правило, устраняет
необходимость в других встречах
Разработчики могут встречаться в течение дня для более
подробного обсуждения того, как перепланировать
оставшуюся работу по текущему Спринту

32.

Ежедневный Скрам
(Daily Scrum)
Рекомендуется использовать формат с ответами каждого
разработчика на 3 вопроса:
1. Что я сделал вчера, что помогло нам приблизиться к
Цели Спринта?
2. Что я сделаю сегодня, чтобы приблизить достижение
Цели Спринта? Нужна ли мне помощь в этом?
3. Вижу ли я какие-либо препятствия, которые могут
помешать нам достичь Цели Спринта?
Зачастую Ежедневный Скрам проводится вокруг Доски
Спринта, которая как раз дает наглядное представление
о препятствиях, которые могут помешать успешному
завершению Спринта

33.

Диаграмма Сгорания Работ
Спринта (Sprint Burndown Chart)
Диаграмма Сгорания Работ Спринта
визуально показывает прогресс Команды
в Стори Поинтах. Это графическое
представление того, сколько работы уже
сделано и сколько еще остается сделать.
По мере того, как дни Спринта проходят
и задачи на Доске Спринта переходят в
«Готово», график сгорания работ идет
вниз, показывая Команде ее прогресс
относительно Цели Спринта
На графике отображаются линии
планового и фактического сгорания задач
Рекомендуется, чтобы оставшаяся работа
уменьшалась более-менее равномерно
по ходу Спринта

34.

Критерии Готовности [Определение
Готовности] (Definition of Done)
Критерии Готовности — это требования качества, предъявляемые к продукту и
его Инкрементам — описание того, что нужно сделать, чтобы считать
завершенной работу над будущими Инкрементами и реализованными в них
Элементами Бэклога Продукта
В момент, когда Элемент Бэклога Продукта стал соответствовать Критериям
Готовности, рождается Инкремент
Если Элемент Бэклога Продукта не соответствует Критериям Готовности, его
нельзя выпускать или даже демонстрировать на Обзоре Спринта в качестве
результата. Вместо этого такой элемент возвращается в Бэклог Продукта для
дальнейшего рассмотрения
Разработчики должны неукоснительно следовать Критериям Готовности. Если
несколько Скрам-команд работают над общим продуктом, они должны
совместно определить и соблюдать одни и те же Критерии Готовности

35.

Обзор Спринта
(Sprint Review)
Обзор спринта проводится в конце Спринта, перед
Ретроспективой
Заинтересованные лица проводят инспекцию Инкремента продукта и
дают обратную связь по нему, а Скрам-команда, при необходимости,
делает адаптацию Бэклога Продукта
Цель — инспекция результата Спринта и выявление возможностей
для адаптации
Скрам-команда демонстрирует результаты своей работы ключевым
заинтересованным лицам, и обсуждает прогресс в достижении Цели
Продукта
Скрам-команда и заинтересованные лица анализируют, что было
достигнуто по итогам
Спринта, и что изменилось в окружении, влияющем на продукт. На
основе этой информации участники совместно решают, что делать
дальше
Бэклог Продукта может быть скорректирован с учетом новых
возможностей и обнаруженных препятствий

36.

Обзор Спринта
(Sprint Review)
Эта встреча — своеобразная проверка: правильно ли
Скрам-команда поняла, что заказывали заинтересованные
лица и правильно ли они сами определили, что ему надо.
Второе определяется гораздо лучше, когда команда
показывает им Инкремент продукта, в идеале — дает
возможность попользоваться им в режиме реального
времени
Рекомендуется, чтобы демонстрацию Инкремента
проводили все или многие разработчики (а не один
человек, выделенный командой для этого), чтобы повысить
уровень командной ответственности, а также избежать
искаженного понимания Инкремента заинтересованными
лицами

37.

Ретроспектива Спринта
(Sprint Retrospective)
Ретроспектива проходит после Обзора Спринта, перед Планированием
следующего спринта. В нем принимает участие вся Скрам-команда
Цель — запланировать повышение качества и эффективности
Скрам-команда инспектирует то, как прошел последний Спринт в
отношении людей, взаимодействий, процессов, инструментов и Критериев
Готовности
Выявляются предположения, которые сбили команду с пути, и исследуются
их причины. Скрам-команда обсуждает, что прошло хорошо во время
Спринта, с какими проблемами она столкнулась, и как эти проблемы были
(или не были) решены
Скрам-команда определяет улучшения в процессе своей работы, наиболее
полезные для повышения эффективности. Такие улучшения затем
реализуются в кратчайшие сроки. Они могут даже быть добавлены в Бэклог
следующего Спринта

38.

Ретроспектива Спринта
(Sprint Retrospective)
Ретроспектива Спринта — командообразующая встреча,
весьма непростая для проведения. Поэтому ее обычно
проводит Скрам-мастер. На Ретроспективе ведутся
откровенные разговоры, в том числе, о неприятных вещах;
проходят сложные мозговые штурмы
Типичная Ретроспектива включает ответы участников Скрамкоманды на следующие вопросы:
Что за прошедшую прошедший спринт было хорошо
и помогало тебе работать?
Что тебе мешало работать?
Что или кто может тебе помочь работать лучше?
Эти ответы так или иначе визуализируются, а далее служат
основой для генерации новых практик и правил, влияющих
на процесс работы команды

39.

Общая схема SCRUM
Входы
от заинтересованных лиц
Скрам
Мастер
Диаграмма
выгорания
Скрам
митинг
Кажды
е 24
часа
Владелец
продукта
Команда
Ranked list
of what is
required:
features, stories, …
Team selects starting
at top as much as it
can commit to
deliver by the end of
Sprint
Беклог
продукта
Планирование
спринта
1-4 недельные
спринты
Завершенная
работа
Task
Task
Task
breakout
breakout
breakout
Беклог
спринта
Обзор
итогов
спринта
Дата окончания спринта
и результат не изменяются
Ретроспектива
спринта

40.

SCRUM является:
Компактным
Простым для понимания
Трудным для совершенного овладения

41.

Плюсы
Прозрачность процессов (практически сразу)
• Предсказуемость (Скрам - не хаос)
• “Мы стали более лучше общаться” (с)
• Постоянный аудит происходящего и адаптация
• Обратная связь непрерывна, и команда включает ее в следующую
версию
• Возможность быстро вносить изменения в продукт и процесс
• Получение быстрых результатов, частые поставки изменений продукта
• Мандат на регулярные технические улучшения
• Минимум документации
• Ориентация на клиента и потребности бизнеса
• Фокусировка на цели спринта
• Практически не требует менеджерской работы
• Интенсивный режим работы, команда всегда «в тонусе»

42.

Минусы и поводы задуматься
Не все люди срабатываются. До скрама нужно дорасти,
команда должна иметь определенную степень зрелости и
сработанности
• Издержки на «болтовню» 10-30%
• Проблемы с планированием
• Не всегда заказчик готов. Нужна активная вовлеченность
клиента в процесс разработки
• Не для всех проектов подходит
• Недостаточно проработанная документация, не всегда
хватает на это времени
Сложности при заключении договоров. Scrum в принципе
не подразумевает наличие фиксированного бюджета и
фиксированного технического задания, что затрудняет
юридическое оформление такого рода договоренностей
• Интровертам сложно, приходится раскрываться на
ретроспективах
• Непредсказуемый результат

43.

Непредсказуемый результат

44.

Масштабирование SCRUM
Типичный размер команды 7 ± 2
Для реализации больших проектов используют
управленческие фреймворки по масштабированию
SCRUM

45.

Пример масштабирования с
использованием Less
3 кросс функциональные
команды
Владелец
продукта
LeSS Фреймфорк
Потенциально
готовый к поставке
инкремент продукта
Общепроектные:
Планирование, Демо
и Ретроспектива
Скрам-мастер
и фиче команда
Командные:
Планирование, Ретроспектива
Пред.
спринт
Планированиесп
ринта ч.1
Обзор спринта
SM
Планированиесп
ринта ч.2
Ретроспектива
Координация
Бэклог спринта
Ежедневный скрам
Уточнение
бэклога продукта
Общая Ретроспектива
След.
спринт
Межкомандное
взаимодействие

46.

Внедрение. Чек-лист
Договорились о готовности работать «по-другому» с командой
и Заказчиком
2. Проведено обучение для команды и Заказчика
3. Привлечен Agile-коуч / Scram Master в проект
4. Убедиться, что:
• 4.1. Команда и Заказчик согласны с подходом к работе
(форматы встреч, фиксирование договоренностей, объем и требования
к документации, длительность спринтов, критерии приемки результатов)
• 4.2. Команда мотивирована и на самом деле готова выпускать работающий
продукт к концу каждого спринта
(маркеры – содержательные daily, тщательное планирование спринтов
с запасом на непредвиденные проблемы – 80/20, формулирование целей спринта,
использование ретроспектив командой как точки развития и повышения своей
эффективности)
• 4.3. Менеджеры и Заказчик понимают, что команда имеет право
на провал (при этом нужно убедиться, что команда учла ошибки
на ретроспективе, запланировала и реализовала улучшения в следующем спринте)
1.