Диагностика анти-паттернов Scrum и корректировка процесса

Здравствуйте! В прошлом уроке мы рассмотрели метрики потока и прогноза: burndown, burnup, velocity и cycle time. Их смысл — не контролировать отдельных людей, а делать видимыми риски для Sprint Goal, изменение объёма и узкие места процесса.

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

---

Что считать анти-паттерном

Анти-паттерн — это повторяющийся способ реагировать на проблему, который кажется удобным или логичным, но обычно усугубляет ситуацию. Это не единичная ошибка и не любое отклонение от «идеального Scrum».

Например, команда один раз отменила Daily Scrum из-за production-инцидента. Это не анти-паттерн: у команды была исключительная ситуация. Но если дейли регулярно превращается в доклад каждому менеджеру о занятости, а участники не обсуждают, как совместно достичь Sprint Goal, — это устойчивый анти-паттерн.

Для TPM важно диагностировать не по названию церемонии, а по наблюдаемому эффекту:

Вопрос	Пример наблюдения
Что происходит регулярно?	На дейли люди по очереди отчитываются Scrum Master или PM.
Какой вред это создаёт?	Блокеры обнаруживаются поздно, команда не меняет совместный план.
Какое свойство Scrum нарушено?	Самоуправление Developers, прозрачность и адаптация к Sprint Goal.
Почему это сохраняется?	Руководству нужен статус, а привычный способ его получить — персональный опрос.
Какой малый эксперимент провести?	Перестроить дейли вокруг доски, возраста задач и рисков для Sprint Goal в течение двух Sprint.
Как проверить эффект?	Измерить число задач, зависших в ревью или тестировании, и обсудить, стали ли блокеры подниматься раньше.

Такой подход полезнее, чем формулировка: «У вас неправильный Scrum». Задача TPM — помочь команде и организации увидеть причинную связь между процессом и результатом.

---

Диагностическая рамка: от симптома к изменению

Практически любой Scrum-анти-паттерн можно разобрать в пять шагов.

1. Зафиксировать факт без обвинения.
   Не «QA тормозит Sprint», а «четыре элемента находятся в тестировании более трёх дней; два из них блокируют Sprint Goal».

2. Понять повторяемость.
   Один сложный Sprint не доказывает проблему. Повторение в нескольких Sprint, особенно при похожем симптоме, требует инспекции.

3. Связать симптом с последствиями.
   Например, позднее тестирование увеличивает cycle time, создаёт очередь и переносит риск качества на финальные дни Sprint.

4. Сформулировать гипотезу о причине.
   Причина может быть в слишком крупных историях, отсутствии тестовых данных, чрезмерном WIP, внешней зависимости или распределении работы по индивидуальным «ячейкам».

5. Выбрать одно изменение и критерий проверки.
   Не «стать более Agile», а: «На два Sprint ограничить одновременно начатые продуктовые истории до трёх и ежедневно обсуждать, что поможет довести старейшую задачу до Done».

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

---

Анти-паттерн 1: Daily Scrum как отчёт руководителю

Самый узнаваемый симптом: Scrum Master, PM или руководитель по очереди спрашивает каждого участника: «Что сделал вчера? Что будешь делать сегодня?». Остальные ждут своей очереди и мало участвуют в разговоре.

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

Правильный ориентир Daily Scrum:

Насколько мы приблизились к Sprint Goal, что мешает довести начатую работу до Done и как мы изменим план?

Например, в Sprint Goal кредитной платформы входит сквозной сценарий показа статуса заявки. На дейли полезно услышать не только «я работаю над API», а следующее:

• пользовательский сценарий не будет завершён, пока не согласован контракт со скоринговым сервисом;
• две задачи ждут code review;
• QA не может проверить интеграцию из-за отсутствия тестовых данных;
• один разработчик может помочь с ревью или подготовкой mock-ответов партнёра.

В этом разговоре планом владеет команда. Scrum Master помогает сделать обсуждение сфокусированным, но не собирает персональную отчётность.

---

Анти-паттерн 2: «водопад внутри Sprint»

В этом случае работа движется большими функциональными пачками:

1. аналитика уточняет требования;
2. дизайнер завершает макеты;
3. backend реализует API;
4. frontend подключает экран;
5. QA получает всё на тестирование ближе к концу Sprint;
6. интеграционные и пользовательские проблемы обнаруживаются слишком поздно.

Иногда это выглядит аккуратно: у каждой функции есть свой этап, специалист постоянно занят, а план кажется предсказуемым. Но ценность не поставляется до самого конца цепочки. Если на девятый день из десяти выясняется, что партнёрское API возвращает иной статус или не поддерживает нужный сценарий, риск реализуется тогда, когда времени на адаптацию почти нет.

Типовые сигналы:

• Sprint стараются удлинить, чтобы «все этапы успели пройти»;
• burndown долго остаётся почти горизонтальным и резко падает в последние дни;
• тестирование систематически сжимается;
• в Sprint Review показывают дизайн, документацию, отдельный API или «почти готовый» код вместо пригодного Increment;
• задачи регулярно переносятся как большая неделимая пачка.

Корректирующее изменение — не требование «всем работать быстрее». Нужно уменьшить размер поставляемого среза и раньше проверить технические риски.

Например, вместо Sprint-плана:

• описать все статусы заявки;
• реализовать все методы backend;
• сделать все экраны;
• протестировать в конце;

можно взять один вертикальный сценарий:

Клиент видит статус «Требуются документы», получает понятное объяснение и может перейти к загрузке документа.

Такой срез включает минимальные изменения frontend, backend, интеграции, проверки и логирования. Он раньше показывает, достижима ли Sprint Goal, и даёт реальную обратную связь.

При этом вертикальный срез не означает отказ от проектирования. Для сложной интеграции может понадобиться техническое исследование, согласование контракта или архитектурное решение. Важно, чтобы результат такой работы снижал конкретную неопределённость и был связан с продуктовой целью, а не становился отдельным «спринтом аналитики» без проверяемого Increment.

---

Анти-паттерн 3: перегруженный Sprint и параллельное начало всего

Команда может принять в Sprint слишком много работы по двум причинам:

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

В итоге на доске много карточек «In Progress», очереди в code review и тестировании растут, а завершённых элементов мало. Это напрямую связано с метриками из прошлого урока: растут cycle time и возраст незавершённых задач, а burndown часто сигнализирует о проблеме только ближе к концу Sprint.

Внешне решение кажется простым: «Нужно поднять velocity». Но это неверный диагноз. Обычно полезнее снизить число одновременно начатых элементов и сосредоточиться на завершении.

Как исправлять

• Планировать Sprint с учётом реальной доступности: отпусков, on-call, обязательных встреч, инцидентов, обучения, поддержки и технического долга.
• Делать прогноз вокруг Sprint Goal, а не вокруг максимального количества points.
• Ввести явное ограничение WIP для ключевых этапов, например разработки, ревью или тестирования.
• На Daily Scrum в первую очередь обсуждать старейшие незавершённые элементы.
• Разрешить и поощрять совместную работу: парное программирование, помощь с тестовыми данными, совместное ревью, декомпозицию истории.

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

---

Анти-паттерн 4: роли переименовали, а модель управления не изменилась

После прошлого урока у вас уже есть базовое различение ролей Scrum Team:

• Product Owner отвечает за максимизацию ценности продукта и управление Product Backlog;
• Scrum Master отвечает за эффективность Scrum Team и помогает устранять препятствия для Scrum;
• Developers создают Increment и сами планируют, как достичь Sprint Goal.

Анти-паттерн возникает, когда старая командно-контрольная модель остаётся прежней, но получает новые названия. Например:

• PM становится Scrum Master и продолжает раздавать задачи каждому человеку;
• Scrum Master согласует все решения, превращаясь в коммуникационное горлышко;
• техлид или Scrum Master единолично принимает все технические решения;
• Product Owner формально ведёт backlog, но не может менять приоритеты, отказывать в запросах или влиять на сроки и бюджет;
• Developers не делают прогноз, а получают «план сверху».

Для TPM это тонкая тема. Роль Project Manager сама по себе не противоречит Scrum, особенно в программах с несколькими командами, внешними подрядчиками, релизными зависимостями и регуляторными обязательствами. Проблема начинается, когда PM лишает Scrum Team её ответственности за продуктовый выбор или технический план.

Здоровая граница может выглядеть так:

Область	Что делает TPM	Что остаётся за Scrum Team
Внешние зависимости	Ведёт реестр, договаривается с владельцами систем, эскалирует риски	Уточняет технические последствия и адаптирует план Sprint
Сроки инициативы	Даёт прогноз диапазоном, делает неопределённость прозрачной	Делает прогноз Sprint и определяет способ достижения Sprint Goal
Риски и отчётность	Синхронизирует стейкхолдеров, не скрывает отклонения	Поддерживает прозрачность фактической работы
Распределение задач	Не назначает индивидуальные тикеты	Developers совместно организуют работу
Продуктовые приоритеты	Помогает увидеть зависимости и ограничения	Product Owner упорядочивает Product Backlog

---

Анти-паттерн 5: Jira и метрики становятся целью

Инструментальная версия Scrum обычно начинается с благих намерений: нужна прозрачность, единый источник данных, отчётность. Затем команда начинает обслуживать инструмент вместо управления работой.

Признаки:

• без Jira невозможно обсудить работу даже на уровне цели и рисков;
• карточки обновляет только Scrum Master или координатор;
• работа не попадает на доску, потому что «не учитывается в velocity»;
• создан особый тип задач, который не влияет на burndown;
• команда меняет факты, чтобы график выглядел красиво;
• story points используют как KPI людей или для сравнения команд.

В прошлом уроке мы уже видели последствия: если velocity становится плановой нормой, возникает инфляция оценок; если burndown оценивают как показатель «успешности», появляется стимул скрывать добавленный scope.

Правильное изменение — вернуть доске и метрикам их диагностическую роль:

• все значимые для Sprint Goal работы и блокеры видимы;
• статусы актуализируют сами участники, выполняющие работу;
• изменение объёма не скрывают, а объясняют;
• метрики анализируют на уровне команды и системы;
• качество Increment и достижение Sprint Goal важнее красивого отчёта.

---

Анти-паттерн 6: Sprint Review как презентация и Retrospective без улучшений

Sprint Review и Retrospective решают разные задачи, поэтому их нельзя подменять друг другом.

Sprint Review посвящён продукту: что изменилось в Increment, что узнали о пользователях, рынке, интеграциях и дальнейших приоритетах. Если вместо демонстрации работающего результата команда показывает слайды или отчёт о «проценте готовности», стейкхолдеры не могут качественно инспектировать реальный результат.

Показывать незавершённые элементы иногда можно, но нужно честно назвать их незавершёнными. Нельзя выдавать их за Done только ради хорошего впечатления или отчёта.

Sprint Retrospective посвящена способу работы команды. Типовые сбои:

• ретро отменяют, чтобы «успеть сделать задачи»;
• команда обсуждает проблемы, но не выбирает действия;
• одни и те же жалобы повторяются каждый Sprint;
• Product Owner исключён из разговора о взаимодействии Scrum Team;
• улучшения формулируются слишком расплывчато: «лучше коммуницировать», «быть внимательнее».

Хорошее ретро завершается не длинным списком пожеланий, а одним или двумя действиями с владельцем и проверкой результата. Например:

Наблюдение	Эксперимент	Проверка через два Sprint
Задачи на интеграцию регулярно блокируются поздно	До Sprint Planning фиксировать владельца, срок ответа и fallback для внешнего API	Снизилось ли число задач, заблокированных более двух дней?
В тестировании образуется очередь	Ограничить WIP в разработке и помогать завершать старейшие элементы	Уменьшились ли средний cycle time и число задач в очереди тестирования?
На Review мало полезной обратной связи	Приглашать конкретных представителей бизнеса и давать им выполнить пользовательский сценарий	Какие решения по backlog появились после Review?

---

Кейс: «спринты есть, Increment нет»

Представьте команду, развивающую сервис обработки автокредитных заявок.

• Sprint длится две недели.
• PM в начале Sprint распределяет задачи между frontend, backend, QA и аналитиком.
• На Daily Scrum каждый отчитывается PM.
• QA получает большинство задач за два последних дня.
• На Sprint Review показывают презентацию: «Разработка API завершена на 90%».
• Retrospective отменяют третий Sprint подряд, потому что команда «не успевает».
• Velocity обсуждают как персональную эффективность разработчиков.

Это не шесть независимых проблем. Здесь действует единая модель: управление оптимизирует индивидуальную занятость и отчётность, а не совместное достижение Sprint Goal и поставку готового Increment.

Разумная последовательность изменений была бы такой:

1. Сформулировать Sprint Goal вокруг одного пользовательского результата, а не набора задач по компонентам.
2. На планировании не распределять весь Sprint Backlog по людям; позволить Developers выбрать совместный план.
3. Перестроить Daily Scrum вокруг доски, возраста задач, блокеров и риска для Sprint Goal.
4. Ввести явный WIP-лимит и правило: сначала помогать завершить начатую работу.
5. Провести Retrospective, выбрав один эксперимент по улучшению потока.
6. На следующем Review продемонстрировать работающий сквозной сценарий либо честно показать, что именно помешало ему стать Done.
7. Убрать персональное использование velocity и анализировать её только как исторический ориентир команды.

Не все изменения нужно запускать одновременно. В реальной организации лучше начать с самого болезненного ограничения — например, очереди тестирования или неясной Sprint Goal — и проверить эффект.

---

Итоги

Scrum-анти-паттерн — не разовое нарушение ритуала, а повторяющийся способ работы, который ухудшает прозрачность, инспекцию, адаптацию или способность команды создавать Increment.

Наиболее частые паттерны, которые стоит замечать TPM:

• Daily Scrum превращается в персональный отчёт вместо совместной адаптации плана;
• внутри Sprint возникает последовательный «мини-водопад», а готовый результат появляется слишком поздно;
• команда начинает слишком много задач одновременно и создаёт очереди;
• роли формально переименованы, но управление остаётся командно-контрольным;
• Jira, burndown и velocity становятся целями, а не средствами диагностики;
• Review подменяется презентацией, а Retrospective отменяется либо не приводит к действиям.

Профессиональная реакция TPM — не навязать идеальную схему, а сделать проблему наблюдаемой, проверить гипотезу о причине и вместе с командой провести малый измеримый эксперимент.

Далее начинается модуль о P3.express. Мы перейдём от Scrum-команды к минималистичной системе управления проектом и разберём семь групп активностей P3.express, связывающих запуск, планирование, еженедельный контроль, закрытие и оценку выгод проекта.