Текст книги "Agile. Процессы, проекты, компании"

3.5. Связь Lean, Agile и других практик

Наши технические команды учатся Agile. Наши продуктовые команды учатся Lean, а наши команды дизайнеров учатся дизайн-мышлению. Кто из них прав?

Джефф Готхельф. Lean vs Agile vs Design Thinking

Самой общей надстройкой семейства гибких практик является Lean, или бережливость. Основной смысл Lean – максимизация ценности для заказчика при минимизации любых потерь (время, ошибки, замечания, лишнее производство и т. д.).

Требования стандартов серии ISO 9001 уточняют: «Все, что не добавляет ценности для потребителя, с точки зрения Lean-производства классифицируется как потери и должно быть устранено». Здесь существует много инструментов и подсистем, как, например, производственная система Lean (системный подход к выявлению и устранению потерь путем непрерывного совершенствования, настройка производственных процессов в зависимости от потребности заказчика и стремление к безупречности во всем – определение Национального института стандартов и технологий (NIST)). Lean может быть отраслевым – Lean-логистика, Lean-здравоохранение, Lean-офис, Lean-строительство и т. п.

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

Канбан, с одной стороны, является инструментом Lean как система карточек Канбан для синхронизации передачи продукта с одной производственной стадии на другую, с другой – одной из разновидностей Agile-практик, визуализацией текущего потока работ с контролем ограничений на канбан-досках. Он появился в середине 2000-х гг. в качестве альтернативы преобладающим в то время Agile-практикам и является менее директивным в сравнении с некоторыми практиками Agile и менее «дезорганизующим», поскольку это подход, основанный на принципе «начинай прямо там, где находишься». Более подробно Канбан будет описан в разделе 5.1.

Скрам, о котором пойдет речь дальше, выступает одной из практик Agile (более подходящий термин – фреймворк, но он не очень привычен для читателей из не ИТ-сферы). В целом все вышеперечисленное весьма схоже и сосредоточено на поставке ценности, уважении к людям, сокращении потерь, обеспечении прозрачности, адаптации к изменениям и непрерывном совершенствовании. В некоторых случаях команда проекта может счесть полезным объединить различные методы: все то, что может принести пользу организации или команде, следует сделать, независимо от его природы.

Спринт 4
Скрам

Введение

Никто не может в одиночку сыграть симфонию. Для этого нужен целый оркестр.

Х. Э. Лаккок, профессор теологии

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

Откуда появился Скрам

Скрам – самый известный и структурированный Agile-фреймворк. Что-то похожее на него в 1986 г. впервые описали Хиротака Такуэти (см. раздел 1.1) и профессор Икуджиро Нонака. Название «Скрам» (сокращенное от scrummage – «схватка») появилось от названия схватки в регби (способа возобновления игры, вовлекающего игроков в тесную группу с опущенными головами для овладения мячом). Официально Скрам получил свое название на конференции OOPSLA 95. Идеи доразвили Джефф Сазерленд и Кен Швабер в начале 1990-х гг. Джеффу принадлежит изначальная идея. Кен описал, формализовал и развил эту идею в то, что мы сегодня понимаем под словом «Скрам». Самым первым в мире скрам-мастером был Джефф Маккенна.

Классика и адаптация

Классический (иногда применяют термин «ванильный») Скрам использует для разработки единую команду. В случае нескольких команд применяют масштабирование Скрама (об этом пойдет речь позже, в разделе 5.5). Апологеты, или евангелисты, Скрама строго запрещают нарушать утвержденные правила, роли, ритуалы, артефакты. Они считают, что Скрам существует только в своей целостности и при использовании отдельных его компонентов измененный фреймворк уже не является Скрамом. На практике же многое подвергается необходимой настройке и адаптации, что связано и с отраслью применения, и с типами проектов, и с корпоративной культурой, и с учетом ограничений:

♦ стали активно использоваться «аквариумные окна» (когда идет видеотрансляция работы одной части команды на стену в комнате, где работает другая часть), позволяющие разделять команду на части, что категорически запрещается авторами Скрама;

♦ используются летучки по телефону;

♦ в конце спринта демонстрация комбинируется с ретроспективой;

♦ ретроспектива переносится на начало следующего спринта и комбинируется с его планированием;

♦ команда работает по Скраму в течение фиксированной части дня, а не полного дня, и т. д.

Особенно большая возможность для подобных настроек или изменений лежит за пределами ИТ-отрасли (этому и посвящена данная книга). Удобным термином для такого избирательного применения компонентов Скрама может быть «скрамность».

Ниже (находясь пока, впрочем, в рамках классического Скрама) поговорим о следующем: что такое скрам-команда и как организовать ее работу? каковы ритуалы Скрама, формиру емые артефакты, правила, особенности планирования и работы в рамках спринта (итерации)? и т. п.

4.1. Классический Скрам

Скрам – это другое. На работе все по-другому. Руководство чувствует себя по-другому. В Скраме работа становится простой, актуальной и продуктивной.

К. Швабер, М. Бидл. Agile Software Development With Scrum

При Скраме разработка делится на временные итерации – спринты, по окончании каждого из которых заказчик получает изменение или улучшение в продукте или создаваемом решении (MVP). Спринты строго фиксированы по длительности, выбранной командой вначале, исходя из особенностей проекта, командного решения и собственной производительности.

Классический («ванильный») Скрам включает три роли (команду разработчиков, владельца продукта и скрам-мастера), артефакты (журнал требований продукта, журнал требований спринта, инкремент или версию продукта) и ритуалы-процессы (планирование спринта, причесывание, обзор спринта, ретроспективу, летучку и собственно сам спринт). Также используются скрам-доска для визуализации потока задач в спринте и диаграммы сгорания и сжигания, показывающие сделанные или оставшиеся объемы задач.

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

♦ командой самостоятельно определяются и фиксируются конкретные объемы работ на спринт;

♦ каждый день проводятся 15-минутные утренние летучки для корректировки работы и подведения промежуточных итогов;

♦ в последний день спринта заказчику демонстрируются полученные результаты, узнается его мнение, уточняется весь список требований и их приоритеты для планирования нового спринта;

♦ по завершении спринта проводится ретроспектива, обсуждаются удачные и неудачные условия работы команды и делаются возможные корректировки;

♦ после всего запускается новая итерация и т. д. до финальной готовности.

Циклы

В большинстве случаев в Скраме применяют инкрементные или итеративные жизненные циклы.

Скрам полезен:

♦ для проектов с «быстрыми победами» в сочетании с высокой толерантностью к изменениям;

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

Ценности Скрама

♦ Приверженность: имея большой контроль над судьбой проекта, команда более привержена проекту и мотивирована на успех.

Онлайн-телеканал Netflix

Сайт ресурса обновляется каждые две недели благодаря Скраму, который не просто позволяет работать с высокой скоростью, но и аккумулирует пользовательский опыт и дает возможность выявить самое главное для клиентов.

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

♦ Фокус: фокусирование одновременно только на немногих вещах – на хорошем сотрудничестве и производстве превосходной работы. Ценность продукта доставляется заказчику раньше.

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

♦ Уважение: разделяя неудачи и успехи, работая вместе, люди начинают уважать друг друга и помогать друг другу.

♦ Смелость: поскольку люди неодиноки, они чувствуют поддержку и имеют в своем распоряжении больше ресурсов. Это придает смелости для решения более сложных задач[6]6
  The Scrum Alliance, 2012.


[Закрыть].

Ограничения Скрама

♦ Расстроенные и демотивированные исполнители, чьи результаты и функции были признаны по итогам спринта ненужными или некачественными.

♦ Командам, привыкшим к длительным предиктивным рабочим циклам, будет сложно перестроиться на работу по Скраму.

♦ Существует опасность увлечься встречами и артефактами Скрама в ущерб реальной работе над проектом.

Netflix (см. врезку на с. 72) испытал эти слабые стороны Скрама в полной мере.

4.2. Роли

Абсолютная уверенность игроков друг в друге, полная согласованность действий и целей – вот что представляет собой величие.

Джефф Сазерленд. Скрам. Революционный метод управления проектами

Трудно с тремя, а потом число не имеет значения.

Из кинофильма «Москва слезам не верит»

Скрам-команда

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

Владелец продукта (Product Owner)

В «водопадных» подходах руководитель проекта сочетает предметные профессиональные знания (правда, чем комплекснее проект, тем меньше это требуется) и управленческие «софтовые» навыки, что часто затруднено. В Скраме есть руководитель-предметник (владелец продукта) и руководитель-администратор (скрам-мастер). Речь о последнем пойдет немного ниже.

Владелец продукта – технический и бизнес-лидер разработки, задача которого – работать с заказчиком и командой, совместно с заказчиком наполнять журнал требований продукта (product backlog) и постоянно и жестко выделять в нем приоритеты, представлять заказчику промежуточные результаты, обладающие для последнего ценностью и возможностью использования. Команда вместе с владельцем продукта по журналу требований выбирает самые важные на текущий спринт задачи, делает план спринта, формируя журнал требований спринта.

Владелец продукта:

♦ по сути, управляет созданием продукта;

♦ является единственным владельцем (возможны варианты, когда их, например, два, но кто-то все равно главный);

♦ выступает представителем заказчика в проекте или в отсутствие конкретного заказчика олицетворяет всех потребителей – пользователей продукта;

♦ может нести финансовую ответственность за продукт;

♦ отвечает за максимизацию ценности создаваемого продукта для заказчика и для бизнеса (business value);

♦ должен досконально знать потребности и образ мышления заказчика, потребителей/пользователей, а также разбираться в продукте и технологии его изготовления;

♦ представляет и описывает обобщенное видение конечного продукта;

♦ совместно с заказчиком (если у него есть полномочия) или без него принимает промежуточные результаты спринтов;

♦ отвечает за максимальную ценность продукта и работы, исполняемые командой разработчиков;

♦ единолично управляет журналом требований продукта, включая создание и упорядочение его элементов; приоритизацию и часто создание элементов журнала; выработку прозрачности и понимания элементов журнала у команды;

♦ связывает и осуществляет взаимодействие между командой разработчиков и скрам-мастером, с одной стороны, и пользователями и другими заинтересованными сторонами – с другой;

♦ отвечает за бизнес-риски, коммуникацию с заинтересованными сторонами проекта, стоимость и границы проекта;

♦ работает не в команде разработчиков, но с этой командой;

♦ может работать с несколькими командами при условии определения приоритетов между их проектами.

Скрам-мастер (Scrum master)

Член команды или свободный участник, играющий роль руководителя – администратора команды разработчиков и обеспечивающий ее работу в течение спринтов. За пределами ИТ-отрасли легко приживается вариант «администратор».

Скрам-мастер:

♦ следит, чтобы никто не мешал команде разработчиков самостоятельно и комфортно работать над задачами;

♦ отвечает за процессы, координацию и улучшение работы команды разработчиков и поддержку социальной атмосферы в ней;

♦ сфокусирован на команде, преодолении разногласий, фактически выполняя для нее роль «обслуживающего лидера»;

♦ помогает участникам лучше понять и принять ценности, принципы и нормы практики Скрама, соблюдать практики и правила;

♦ обучает команду способам преодоления препятствий;

♦ помогает команде проводить планирование и запуск спринта в части выполнения правил Скрама;

♦ проводит утренние летучки, на которых анализируется предыдущий день, описывается текущий и снимаются вопросы, так называемые блокеры, следит за качеством этих летучек;

♦ во время спринта следит, чтобы команду ничего не отвлекало, помогает ей пользоваться коллективным разумом, в конце организует демонстрацию результатов спринта и проводит ретроспективу при участии команды;

♦ помогает участникам, не входящим в состав команды, понять, какие из их взаимодействий с командой являются полезными, а какие – нет, содействует изменению таких взаимодействий для увеличения ценности продукта, создаваемого командой;

♦ помогает знаниями о новых практиках, учит команду Скраму, самоуправлению и кросс-функциональности;

♦ устраняет помехи, которые возникают в процессе работы команды;

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

♦ не возглавляет команду и не руководит ею, скорее «склеивает» ее;

♦ выполняет свою работу так, чтобы команда имела возможность делать то, что она делает лучше всего;

♦ как правило, работает одновременно не более чем с 1–2 командами для избежания большого числа переключений между проектами и конфликта приоритетов.

Команда исполнителей (разработчиков)

Для создания решения или продукта проекта формируется и наделяется полномочиями небольшая автономная команда разработчиков – специалистов по всем необходимым направлениям работы. За счет полного вовлечения членов команды достигается высокая производительность ее работы. Оптимальный размер команды – от трех до девяти человек, иногда для обозначения конкретных участников используют табличку 3 х 3.

Это кросс-функциональная самоорганизующаяся, самоуправляемая, не зависящая ни от кого извне (с некоторыми исключениями) команда специалистов, которая:

♦ быстро создает вариант решения или продукта (MVP) для получения обратной связи от заказчика;

♦ отвечает за то, чтобы в конце спринта все запланированные задачи были сделаны, а представления заказчику MVP выполнены;

♦ целиком несет ответственность за качество продукта, коммуникации в проекте и технические риски своей работы;

♦ не имеет никаких других должностей в команде, кроме роли члена команды или исполнителя, невзирая на вид выполняемой работы;

♦ может включать объявленные роли, но в целом является самоорганизующейся системой из кросс-функциональных мотивированных профессионалов;

♦ сама (никто не может указывать команде) превращает элементы журнала требований продукта в инкременты или итерации работающей функциональности в задачи спринта;

♦ все рабочее время полностью посвящает работе, располагается в одном месте или использует «аквариумные окна» (видеоэкраны со звуком);

♦ включает членов с «Т-образной квалификацией», когда в дополнение к экспертному знанию в одной области сформированы владение вспомогательными, хоть и менее развитыми, навыками в смежных областях и хорошие навыки совместной работы. (Противоположностью «T-людям» являются характерные для «водопадных» циклов специалисты с «I-образной квалификацией», которые имеют глубокую специализацию в какой-то одной области и редко вносят вклад в работу в других областях.)

Говоря о мотивации команды, важно отметить, что система мотивации в первую очередь направлена на достижение общих целей. Этому должна способствовать корпоративная культура, поддерживающая командную работу, командные KPI. Как говорят практики, условия должны быть такими, чтобы члены команды «не думали о деньгах». Желательно, чтобы члены команды имели высокий EQ.

Скрам-команды

Члены команды чувствуют себя полностью вовлеченными в проект, когда участвуют в распределении задач во время планирования спринта, а не в ходе выполнения задания. Если сотрудники действительно испытывают чувство ответственности, то в начале спринта нет необходимости распределять задания между ними. В эффективных скрам-командах персонал сам распределяет задачи на основании имеющихся навыков и опыта. Это один из ключей к пониманию того, как работают самоорганизующиеся команды.

(Из книги Эндрю Стеллмана и Дженнифер Грин «Постигая Agile» (см. список литературы)).

Скрам/Agile-наставник или консультант:

♦ помогает подразделению или всей компании в Agile-трансформации или правильном использовании гибких практик;

♦ может работать скрам-мастером при запуске проекта, или переходе предприятия на Agile-разработки, или в первых спринтах в новом проекте в тандеме со скрам-мастером, может посвятить время развитию потенциала каждой отдельно взятой команды;

♦ должен иметь опыт и умение видеть более долгосрочную картину из гибкой трансформации, подчиняться руководству организации и не подвергаться политическому влиянию;

♦ обучает, интегрирует внешние знания и опыт работы с корпоративной культурой.

4.3. Артефакты

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

Джефф Сазерленд. Scrum. Революционный метод управления проектами

Журнал требований продукта

Журнал требований продукта (Product Backlog, бэклог продукта) – это упорядоченный по приоритетам (важности, срочности) список пользовательских историй (требований), которые получены от заказчика и потребителей и должны принести конкретную бизнес-ценность создаваемому продукту. Этот список является единственным источником требований для любых изменений, которые могут потребоваться в продукте. Ответственность за журнал требований продукта несет его владелец, включая содержание продукта, доступность, редактирование и упорядочение. Как правило, этот список оформляется в виде таблицы (в MS Excel или иных форматах) или с использованием ПО, например JIRA и т. п.

Истории пользователей или требования в этом документе обычно описаны на понятном для заказчика или пользователей языке, в соответствии с концепцией или целью всего проекта, пронумерованы и оценены в объемах работы в условных единицах (стори пойнтах или иногда в часах, с применением экспертных оценок, числа Фибоначчи или покерных карт, введенных Джеймсом Греннингом в 2002 г.).

Комментарий к оценке с помощью покерных карт (один из вариантов)

Каждый член команды имеет колоду карт с диапазоном чисел: 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Модератор совещания по планированию спринта читает описание каждого оцениваемого рабочего элемента, а владелец продукта отвечает на вопросы, которые могут возникнуть. После ответов каждый оценщик выбирает карту с числом. Все одновременно показывают свои карты. Если отдельные оценки существенно различаются, тогда участники объясняют оценки с самыми низкими и самыми высокими показателями и может быть проведено дополнительное обсуждение содержания рабочего элемента. После обсуждения все оценщики делают переоценку и процесс повторяется.

Наиболее важные требования обрабатываются в первую очередь. Чем выше приоритет требования и чем сильнее необходимость в его разработке, тем больше согласованности должно быть по поводу этого требования и его значимости. Используется метод набегающей волны, когда требования с высоким уровнем приоритетности, которые будут достигаться в ближайшее время, детализируются подробно, а более поздние и менее приоритетные – укрупненно. Журнал требований продукта никогда не может быть полным. При старте проекта он содержит только первоначально известные и наиболее понятные требования, а затем постоянно обновляется по мере появления идей заказчика, обновления самого продукта и среды, в которой он разрабатывается. Журнал требований продукта существует одновременно с разработкой продукта. Требования журнала, над которыми команда будет работать во время наступающего спринта, детализированы и разбиты на части так, что любое из этих требований может быть выполнено и «готово» в рамках данного спринта. Время, потраченное на работу над требованиями журнала в Скраме, специально не выделяется. Они вносятся командой в план следующего спринта во время процесса его планирования. Команда несет всю ответственность за оценку объемов работы на следующий спринт. Владелец продукта может помочь команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от команды.

Если над одним продуктом работают несколько команд, все равно используется только один общий журнал требований продукта, чтобы определить работу на ближайший период.

Журнал требований спринта

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

Аспекты создания хорошего журнала требований продукта

Журнал требований продукта должен:

✓ быть соответствующе детализирован. Истории пользователей вверху журнала должны быть достаточно хорошо прописаны, чтобы их можно было закончить в ближайшем спринте. Истории, задачи которых не будут выполняться в ближайшие пару спринтов, не нуждаются в большом количестве деталей;

✓ иметь оценку. Журнал – это больше, чем список пожеланий; это еще и инструмент планирования. Учитывая, что чем ниже элемент, тем менее он пока продуман, оценки могут быть менее точными, чем у элементов сверху;

✓ быть изменяющимся. Журнал не статичен, а изменяется с течением времени. По мере того как мы больше узнаем о продукте, истории в журнал добавляются, удаляются или изменяются их приоритеты;

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

(Из книги Майка Кона «Scrum. Гибкая разработка ПО»)

Диаграммы сгорания и сжигания

Для оценки прогресса работ внутри спринта и в проекте в целом используются графики типа «сколько осталось» (burndown) и «сколько сделано» (burnup), которые называются «диаграммой сгорания» и «диаграммой сжигания» соответственно. По горизонтальной оси откладывается число дней спринта, по вертикали – объем работы в условных единицах. В любое время можно увидеть количество работы, которую осталось проделать для достижения цели проекта или которая сделана. Скрам-мастер отслеживает эти графики как минимум на каждой летучке, сравнивая текущее количество работы с плановым, чтобы оценить прогресс в работе и успевает ли команда достичь цели спринта в рамках запланированного времени. Эта информация должна быть доступной и открытой для всех членов команды. Используются и укрупненные по всему циклу спринтов диаграммы, когда по горизонтальной оси откладывается число запланированных спринтов, а по вертикальной отслеживается весь объем работ проекта. Это крайне важная информация для понимания владельцем продукта, успевает ли команда достичь цели проекта в рамках запланированного числа спринтов.

Скрам-доска

Для визуализации процесса исполняемых задач используется скрам-доска (рис. 4.1). Это либо реальная доска с вертикальными столбцами и со стикерами-карточками, на которых компактно помещается вся нужная информация по задачам (кто выполняет задачу, когда завершит, сколько времени затратит), или виртуальная, в случае если команда работает удаленно (например, с применением программных решений Trello или JIRA). В самом простом виде названия столбцов могут быть: «Журнал требований», «Нужно сделать» (To do), «В процессе» (In process), «На рассмотрении/оценке качества» (In review/Quality assurance) и «Сделано» (Done). По вертикали размещаются истории пользователей (user story). При условии работы команды в одной комнате физические доски лучше, они позволяют передвигать, «тащить» задачи, использовать тактильные ощущения, испытывать психологические эмоции от сокращения числа задач и видеть все глазами сразу. Если это реальная доска, команда пишет свои задачи на стикерах и помещает их в соответствующие столбцы в зависимости от стадии выполнения задачи. Так вырисовывается картина работ над проектом в текущем спринте, а также возникает понимание, на каких этапах наблюдаются узкие места, где, например, возникает наибольшее скопление задач-стикеров.

Рис. 4.1. Пример скрам-доски 1

Можно разбить процессы работы на спринте на составные части, тогда скрам-доска может выглядеть так (рис. 4.2).

Рис. 4.2. Пример скрам-доски 2

В процессе утренней летучки команда, рассказывая о проделанной и предстоящей работе, переклеивает стикеры-задачи из одного столбца в другой, тем самым визуализируя те моменты, которые могут затруднять ее работу. На основании такого наглядного анализа могут вырисовываться срочные задачи, которые тормозят проект в целом. Такие задачи выносятся в отдельную графу на доске визуализации (см. рис. 4.2).

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