PMI PMP: Agile, Scrum и гибридная поставка — Руководство по подготовке

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Часть PMP — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов PMI, или пройдите тесты на время на ExamRoll.io.

Роли, церемонии и артефакты Scrum

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

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

Основные церемонии образуют замкнутый цикл обратной связи:

• Планирование спринта
  • Цель: Согласовать цель и прогноз спринта
  • Частота: В начале спринта
  • Основной результат: Бэклог спринта
• Ежедневный стендап
  • Цель: Синхронизация, выявление препятствий
  • Частота: Ежедневно, ограничено 15 минутами
  • Основной результат: Скорректированный план на день
• Обзор спринта
  • Цель: Проверить инкремент вместе с заинтересованными сторонами
  • Частота: В конце спринта
  • Основной результат: Обратная связь, обновлённый бэклог продукта
• Ретроспектива спринта
  • Цель: Проанализировать процесс
  • Частота: В конце спринта
  • Основной результат: Конкретные действия по улучшению

К каждому из артефактов — Бэклогу продукта, Бэклогу спринта и Инкременту — привязано обязательство: Цель продукта, Цель спринта и Критерии готовности (Definition of Done) соответственно. Именно эти обязательства не дают Scrum выродиться в «итеративный водопад».

Управление бэклогом и пользовательские истории

Бэклог продукта — это живой, упорядоченный список, а не спецификация, замороженная в начале проекта. Владелец продукта ведёт его в сотрудничестве с командой, уточняя элементы так, чтобы верхняя часть бэклога состояла из небольших, хорошо понятных и готовых к работе задач. Распространённой практикой является выделение 5–10% ресурсов команды на уточнение бэклога (backlog refinement) в каждом спринте.

Пользовательские истории следуют знакомому шаблону: Как [персона], я хочу [возможность], чтобы [польза]. Часть с описанием пользы так же важна, как и сама возможность — именно она позволяет команде предлагать альтернативные решения и даёт Владельцу продукта возможность решить, стоит ли по-прежнему делать эту историю при смене приоритетов.

Критерии приёмки — это наблюдаемые, проверяемые условия, при которых Владелец продукта примет историю. Они отличаются от Критериев готовности (Definition of Done): критерии приёмки специфичны для конкретной истории (блокируется ли экран входа после пяти неудачных попыток?), в то время как DoD универсальны для каждой истории (прошёл ли код ревью, протестирован ли, задокументирован ли, развёрнут ли на промежуточном окружении?).

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

DoR, DoD и планирование итераций

Критерии готовности к работе (Definition of Ready) — это фильтр на входе в спринт. История готова, когда она достаточно мала для завершения в рамках одного спринта, имеет чёткие критерии приёмки, известные зависимости определены, и она понятна команде. Соблюдение DoR не позволяет команде брать в работу «сырые» задачи, которые застопорятся в середине спринта из-за нерешённых вопросов.

Критерии готовности (Definition of Done) — это фильтр на выходе. Это общий, не подлежащий обсуждению чек-лист, который превращает фразу «мы закончили кодировать» в «это потенциально готовый к поставке инкремент». Надёжный DoD обычно включает в себя прохождение автоматизированных тестов, ревью кода, отсутствие уязвимостей по результатам сканирования безопасности, обновление документации и — что критически важно — учёт нефункциональных требований, таких как производительность и наблюдаемость (observability). Вовлечение отделов эксплуатации и контроля качества в определение DoD предотвращает ситуацию, когда инкремент «работает» на обзоре спринта, но падает под реальной нагрузкой в производственной среде. Если после спринта отдел эксплуатации поднимает вопрос о производительности, и данные для анализа уже есть в логах, зрелой реакцией будет вынести этот вопрос на уточнение бэклога, добавить пороговые значения производительности в DoD и создать элементы бэклога для устранения проблемы, а не отмахиваться от неё как от «не входящей в скоуп».

MVP, планирование релизов и инкрементальная поставка

Минимально жизнеспособный продукт (MVP) — это наименьшая целостная часть функциональности, которая позволяет команде проверить ключевую гипотезу на реальных пользователях. Его цель — обучение, а не просто поставка. Планирование релизов надстраивается сверху: имея дорожную карту, состоящую из MVP и последующих инкрементальных релизов, команда прогнозирует, какие возможности попадут в какой релиз, используя скорость команды (velocity) в качестве грубого ориентира.

Инкрементальная поставка даёт организации опциональность — возможность менять направление на основе фактов, а не мнений. Ожидание «полноценного» релиза перед тем, как показать что-либо пользователям, — это антипаттерн, для предотвращения которого и был разработан agile.

Оценка, Story Points и скорость команды

Story points измеряют относительные усилия, сложность и неопределенность, а не длительность. Задача на пять story points требует примерно в пять раз больше усилий, чем задача на один story point, именно для этой конкретной команды. Скорость (количество story points, выполненных за спринт) определяется эмпирически в течение нескольких спринтов и используется для прогнозирования диапазонов, а не для принятия календарных обязательств.

Рассматривать story points как фиксированные дни — серьезная ловушка по нескольким причинам. Во-первых, это разрушает абстракцию: если 1 story point = 1 день, команда будет просто оценивать в днях и завышать оценки, чтобы уложиться в сроки. Во-вторых, это устраняет сигнал о неопределенности — задача на 13 story points не просто «длинная», она рискованная, и этот риск должен стать поводом для декомпозиции. В-третьих, это позволяет руководству манипулировать цифрами («вы говорили 40 story points, почему вы сделали только 32?»), что приводит к перестраховке и занижению оценок. Правильное использование: тренд скорости + размер бэклога → вероятностный прогноз релиза, представленный в виде диапазона.

Управление препятствиями, прерываниями и потоком

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

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

Для гибридных команд, где тестирование или другая дисциплина становится узким местом, визуализация потока с помощью Kanban-досок и диаграмм сгорания/накопления выявляет это ограничение. Если команда определяет инструмент, который мог бы разблокировать тестирование, менеджер проекта не должен единолично одобрять или отклонять предложение — он должен оценить его совместно с командой, проверить соответствие организационным политикам (закупки, безопасность), обсудить с PO влияние на бэклог и затем принять решение. Рефлекторное одобрение означает отказ от комплексной проверки; рефлекторный отказ игнорирует опыт команды.

Ретроспективы и непрерывное улучшение

Ретроспективы замыкают цикл обратной связи. Хорошая ретроспектива приводит к одному-двум конкретным действиям по улучшению с назначенными ответственными, а не превращается в сеанс выплескивания эмоций. Привлечение специалистов по эксплуатации и QA к ретроспективам на ранних этапах предотвращает классические сбои при передаче, когда команды оптимизируют работу под демо в конце спринта, а не под реальную эксплуатацию в production. Непрерывное улучшение — это механизм, который поддерживает честность скорости, осмысленность Критериев готовности (DoD) и высокую вовлеченность команды на протяжении всего жизненного цикла продукта.

Практическая задача: разбор сценария

Сценарий: Прия Наир — Scrum-мастер команды мобильного кошелька «LumenPay» в финтех-компании. Команда работает двухнедельными спринтами и состоит из шести разработчиков, QA-инженера и UX-дизайнера. За последние три спринта Владелец продукта (PO), Маркус Ривз, посетил только одно планирование спринта и ни одного обзора спринта, ссылаясь на конфликт обязанностей в качестве главы отдела по работе с розничными партнерами. Заинтересованные стороны из отделов комплаенса и противодействия мошенничеству (Fraud Ops) начали напрямую отправлять разработчикам электронные письма с противоречивыми приоритетными запросами, и за последние два спринта команда перенесла 34 из 82 story points. Спонсор, вице-президент по продукту Анита Чен, начинает сомневаться в скорости команды.

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

Рекомендуемый подход:

1. Задокументировать конкретные последствия отсутствия PO за последние три спринта — перенесенные story points, неоднозначные критерии приемки, нерешенные элементы бэклога и количество прямых запросов от заинтересованных сторон в обход PO — чтобы подготовить аргументацию, основанную на фактах.
2. Сначала провести встречу один на один с Маркусом, поделиться данными и прямо спросить, может ли он посвящать этой роли 10–15 часов в неделю, или же эту роль необходимо переназначить или разделить.
3. Формально эскалировать проблему Аните Чен с задокументированными доказательствами, представив два варианта: переназначить роль PO кому-то, у кого есть ресурсы, или договориться о сокращении обязанностей Маркуса в отделе по работе с розничными партнерами.
4. Проинструктировать команду разработки перенаправлять все входящие запросы от заинтересованных сторон в бэклог продукта, а не принимать их в работу по мере поступления, и напомнить, что только PO может изменять приоритеты.
5. После того как будет подтвержден вовлеченный PO, провести воркшоп по уточнению бэклога, чтобы пересмотреть приоритеты, очистить критерии приемки и заново определить цель для следующей итерации.
6. Заключить рабочее соглашение, в котором будет прописано обязательное присутствие PO на планировании, обзоре и как минимум на двух сессиях по уточнению бэклога за спринт.

Почему это сработает: Эскалация проблемы спонсору сохраняет целостность ролей — Scrum-мастер не должен становиться заместителем Владельца продукта, потому что это навсегда маскирует организационную проблему и ставит под угрозу приоритизацию на основе ценности. Обоснование эскалации конкретными метриками позволяет сосредоточить разговор на результатах поставки, а не на личностях, а перенаправление потока запросов от заинтересованных сторон через бэклог восстанавливает дисциплину единого источника правды, от которой зависит Scrum.

← Руководство командой и управление ресурсами · Все домены · Содержание →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →