agile

Agile — ловушки

Stories

Техзадача вместо user value

Плохо: "Внедрить Redis для кэширования" — технология, не ценность для пользователя Правильно: "Как пользователь, я хочу получать результаты поиска за <2 сек" — Redis в Technical Notes Почему: story без user value невозможно приоритизировать и нельзя проверить — нет acceptance criteria

Story без Acceptance Criteria

Плохо: "Улучшить поиск" — размыто, нет критериев приёмки Правильно: AC в формате Given фильтр цены 1000-5000 / When применяю / Then вижу только товары в диапазоне Почему: без AC каждый понимает story по-своему, QA не знает что проверять, PO не знает когда принимать

Технология в формулировке story

Плохо: "Как пользователь, я хочу чтобы данные кэшировались в Redis" Правильно: "Как пользователь, я хочу чтобы страницы загружались за <2 сек" Почему: пользователю всё равно про Redis. Технология = implementation detail, фиксируется в Technical Notes

Story > 8 SP не разбита

Плохо: story на 13+ SP тянется через весь спринт, не влезает Правильно: split по workflow steps, бизнес-правилам, или данным (CSV / Excel / JSON отдельно) Почему: большая story = непредсказуемость, невозможно отслеживать прогресс, блокирует остальные задачи

Спринт и планирование

Water-Scrum-Fall

Плохо: все stories написаны заранее на квартал, детализированы до последней запятой Правильно: just-in-time refinement — детализируй только то, что берёшь в ближайшие 1-2 спринта Почему: требования меняются, детализация "на будущее" = waste. 70% заранее написанных stories переписываются

Velocity как KPI

Плохо: "Ускоряемся каждый спринт" — velocity как цель для роста Правильно: velocity = 3-sprint rolling average для прогноза, НЕ метрика производительности Почему: команда начинает инфлировать SP чтобы "расти", velocity теряет смысл как инструмент планирования

Цепочка зависимостей A-B-C-D

Плохо: story A блокирует B, B блокирует C — одна задержка останавливает всё Правильно: минимизируй зависимости, объединяй зависимые stories, или делай параллельными через interface contracts Почему: каждая зависимость = точка отказа. 4 зависимости с 80% вероятностью каждая = 41% общей вероятности успеха

DoR / DoD

Нет DoR перед planning

Плохо: берём story в спринт без AC, без оценки, без понимания scope Правильно: DoR чек-лист: AC есть, зависимости определены, оценка дана, вопросы закрыты Почему: неготовая story в спринте = разбор полётов mid-sprint, re-estimation, срыв commitment

Нет DoD перед приёмкой

Плохо: "Готово" = код написан, но нет тестов, code review, документации Правильно: DoD чек-лист: тесты, review, deploy на staging, AC проверены Почему: без DoD каждый понимает "готово" по-своему, technical debt накапливается, баги на production

Splitting стратегии

Стратегия	Пример
По workflow steps	Регистрация / Подтверждение email / Настройка профиля
По бизнес-правилам	Доставка: domestic / international / бесплатная
По данным	Импорт: CSV / Excel / JSON API
По Simple/Complex	Поиск по имени / + фильтры / + сортировка / + full-text

Чек-лист

• Stories формулируются через user value, не техзадачи
• AC в формате Given-When-Then
• Нет stories >8 SP (split!)
• DoR проверяется перед planning
• DoD проверяется перед приёмкой
• Velocity — rolling average, не цель для роста
• Backlog refinement каждый спринт (just-in-time)