Применить Agile/Scrum/Kanban к реальной ситуации команды: диагностировать проблему и предложить обоснованное улучшение.
Как диагностировать проблемы Agile-команды
Сквозной разбор: от симптома к улучшению
За шесть уроков мы разобрали Agile-манифест и 12 принципов, Scrum-фреймворк (роли, события, артефакты, тайм-боксы), оценку и планирование (story points, velocity, INVEST), Definition of Done и качество инкремента, а также Kanban с метриками потока. Теперь важно научиться видеть проблемы в реальных командах и предлагать конкретные решения, опираясь на эти знания.
Диагностика работает в три шага. Сначала — найти симптом: что именно идёт не так? Потом — связать симптом с нарушенным принципом, ролью, событием или артефактом. Например, если Daily превратился в отчёт менеджеру, нарушается и цель события (синхронизация разработчиков, а не отчёт), и ценность Scrum «самоорганизация». Наконец — предложить реалистичное улучшение, желательно конкретное действие на ближайшей ретроспективе.
Типичные антипаттерны: velocity используют как KPI и сравнивают команды (velocity — эмпирический инструмент команды, не измеритель «производительности»); нет Definition of Done и «готовое» постоянно возвращают на доработку (DoD — обязательство инкремента); задачи копятся без WIP-лимитов (нарушается принцип потока); истории не проходят INVEST — слишком крупные, не тестируемые или не независимые.
В следующем задании вам предстоит разобрать кейс реальной команды, назвать проблему своими словами, объяснить, что именно нарушено, и предложить конкретные шаги.
Lesson notes
Сквозной разбор: от симптома к улучшению
За шесть уроков мы разобрали Agile-манифест и 12 принципов, Scrum-фреймворк (роли, события, артефакты, тайм-боксы), оценку и планирование (story points, velocity, INVEST), Definition of Done и качество инкремента, а также Kanban с метриками потока. Теперь важно научиться видеть проблемы в реальных командах и предлагать конкретные решения, опираясь на эти знания.
Диагностика работает в три шага. Сначала — найти симптом: что именно идёт не так? Потом — связать симптом с нарушенным принципом, ролью, событием или артефактом. Например, если Daily превратился в отчёт менеджеру, нарушается и цель события (синхронизация разработчиков, а не отчёт), и ценность Scrum «самоорганизация». Наконец — предложить реалистичное улучшение, желательно конкретное действие на ближайшей ретроспективе.
Типичные антипаттерны: velocity используют как KPI и сравнивают команды (velocity — эмпирический инструмент команды, не измеритель «производительности»); нет Definition of Done и «готовое» постоянно возвращают на доработку (DoD — обязательство инкремента); задачи копятся без WIP-лимитов (нарушается принцип потока); истории не проходят INVEST — слишком крупные, не тестируемые или не независимые.
В следующем задании вам предстоит разобрать кейс реальной команды, назвать проблему своими словами, объяснить, что именно нарушено, и предложить конкретные шаги.