Содержание
Если вы хоть раз сидели на планировании разработки, наверняка слышали: «эта задача на пять сторипойнтов», «добавим в бэклог», «не успеем в текущий спринт», «velocity просела», «нужен planning poker». Для новичка это звучит как отдельный диалект. На деле за терминами стоят простые идеи: короткие циклы работы, прозрачный список задач, относительные оценки сложности и регулярная обратная связь от заказчика.
Ключевые выводы
Agile — это ценности, Scrum — конкретный способ их применить. Манифест Agile (2001) описывает зачем менять подход к разработке; Scrum добавляет роли, события и артефакты — как организовать работу команды.
Story Points — не часы. Это относительная оценка объёма, сложности, неопределённости и риска. Две задачи на восемь часов могут получить разные оценки, если одна понятна, а вторая — нет.
Velocity — метрика команды, не людей. Она показывает, сколько story points команда обычно закрывает за спринт. Сравнивать velocity разных команд бессмысленно: шкала оценок у каждой своя.
Backlog — единый источник правды о работе. Product Backlog — всё, что может быть сделано; Sprint Backlog — то, что команда обязалась сделать в текущем цикле.
Процесс существует ради продукта. Daily, review, retrospective — не бюрократия, а инструменты, чтобы быстрее поставлять ценность и улучшать способ работы.
Откуда появился Agile
Проблемы каскадной модели
До широкого распространения Agile большинство проектов шли по каскадной модели (Waterfall): сбор требований → проектирование → разработка → тестирование → внедрение. Каждый этап «закрывали» документами, и возврат назад был дорогим.
Реальность software-проектов другая: требования меняются, рынок реагирует на конкурентов, пользователи понимают продукт только после первых релизов. Через год разработки заказчик мог получить ровно то, что просил в ТЗ, — и понять, что это уже не то, что нужно сейчас.
Манифест Agile
В 2001 году семнадцать практиков сформулировали Agile Manifesto. Четыре ценности (формулировки сокращены):
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования контрактов.
- Готовность к изменениям важнее следования первоначальному плану.
За манифестом — двенадцать принципов: короткие итерации, частые поставки, самоорганизующиеся команды, регулярная рефлексия. Agile не отменяет планирование — он делает его непрерывным и адаптивным.
Что такое Scrum
Scrum — самая распространённая фреймворк-реализация Agile для продуктовых команд. Он не описывает, как писать код, но задаёт минимальный каркас: три роли, пять событий, три артефакта.
Роли
Product Owner (PO) отвечает за ценность продукта. Формирует и приоритизирует Product Backlog, переводит бизнес-цели в понятные элементы backlog, принимает результат спринта. PO — не «начальник разработчиков», а представитель интересов пользователя и бизнеса.
Scrum Master следит за процессом: помогает убрать препятствия, фасилитирует события, обучает команду практикам Scrum. Это не project manager в классическом смысле и не техлид — скорее «сервисная роль» для команды.
Development Team (команда разработки) — кросс-функциональная группа, которая создаёт инкремент продукта. В Scrum нет подролей «только кодер» и «только тестировщик» на уровне процесса: команда вместе отвечает за результат спринта.
Sprint — сердце Scrum
Что такое спринт
Sprint — фиксированный интервал (timebox), в течение которого команда создаёт готовый «Done»-инкремент. Типичная длительность: одна, две, три или четыре недели; чаще всего — две недели.
Внутри спринта scope не меняют произвольно: если прилетела срочная задача, PO и команда осознанно решают, что выкинуть или перенести — а не «добавить сверху без последствий».
Зачем нужны спринты
Короткие циклы дают предсказуемый ритм: планирование → работа → демо → улучшение процесса. Ошибки в требованиях всплывают через недели, а не через кварталы. Stakeholders видят прогресс регулярно, а не только на «большом релизе».
Типичный цикл спринта
- Sprint Planning — что делаем и как.
- Daily Scrum — короткая синхронизация (обычно 15 минут).
- Работа над задачами.
- Sprint Review — демонстрация результата.
- Sprint Retrospective — что улучшить в процессе.
- Новый спринт.
Backlog и User Story
Product Backlog и Sprint Backlog
Backlog — упорядоченный список всего, что нужно или может понадобиться продукту.
Product Backlog — главный список проекта: новые функции, баги, технический долг, spikes (исследования). PO постоянно его уточняет и пересортировывает.
Sprint Backlog — подмножество Product Backlog плюс план команды на текущий спринт. Только то, на что команда взяла обязательства в этом цикле.
Пример элементов Product Backlog:
- Авторизация через Google.
- Экспорт отчёта в Excel.
- Ускорение страницы каталога на 30 %.
- Исправление ошибки расчёта НДС.
User Story
User Story описывает потребность пользователя, а не техническую реализацию. Классический шаблон:
Как [роль]
я хочу [действие]
чтобы [результат / ценность]
Плохо: «Сделать кнопку экспорта».
Хорошо: «Как бухгалтер, я хочу экспортировать отчёт в Excel, чтобы отправить его налоговому консультанту».
К story добавляют критерии приёмки (acceptance criteria) — проверяемые условия «готово с точки зрения пользователя». Это мост между PO и командой при тестировании.
Story Points и Planning Poker
Что такое Story Point
Story Point (SP, сторипойнт) — относительная оценка сложности задачи. Это не:
- часы или дни;
- деньги;
- «производительность программиста».
При оценке учитывают:
- объём работы — сколько шагов и затронутых частей системы;
- техническую сложность — нестандартные интеграции, устаревший код (legacy);
- неопределённость — неясные требования, слабая документация API;
- риски — внешние зависимости, миграции данных.
Пример. «Поменять текст на кнопке» — 15 минут, минимальная сложность → 1 SP. «Интеграция нового платёжного шлюза» — может занять 8 часов, но с неизвестной документацией и рисками → 13 SP.
Почему SP не равны времени
Две задачи по времени одинаковы, а сложность — нет. Задача А: понятный CRUD, знакомый стек, без рисков. Задача Б: тот же объём кода, но неизвестное поведение стороннего API и вероятность смены требований. Задача Б получит больше SP, хотя «часы в календаре» могут совпасть.
Последовательность Фибоначчи
Часто используют шкалу 1, 2, 3, 5, 8, 13, 21, 34. Чем больше задача, тем выше неопределённость — разница между 1 и 2 мала, между 21 и 34 уже «другой порядок величины». Крупные оценки сигнал: задачу стоит декомпозировать.
Planning Poker
Planning Poker — техника командной оценки:
- Команда читает user story.
- Каждый тайно выбирает карту со значением SP.
- Все одновременно показывают оценки.
- Обсуждают расхождения (особенно min и max).
- Повторяют голосование до консенсуса или узкого диапазона.
Метод снижает эффект «авторитетного мнения» и вытаскивает скрытые риски: junior видит подводный камень, который senior не заметил.
Velocity и иерархия задач
Velocity
Velocity — сколько story points команда завершила (по Definition of Done) за спринт. Пример: спринты на 30, 35 и 40 SP → средняя velocity ≈ 35 SP/спринт.
Velocity помогает прогнозировать: «при текущем backlog и velocity релиз X займёт N спринтов». Это не KPI для «наказания» команды и не способ сравнить две команды — шкалы SP у них разные.
Epic, Feature, Story, Task
На крупных продуктах работу группируют:
| Уровень | Смысл | Пример |
|---|---|---|
| Epic | Большая бизнес-цель | «Система онлайн-платежей» |
| Feature | Крупная функция | «Оплата банковской картой» |
| User Story | Потребность пользователя | «Как клиент, хочу оплатить заказ картой…» |
| Task | Технический шаг | «Создать таблицу payments», «API checkout» |
Epic декомпозируют на stories; stories — на tasks в Sprint Backlog. Границы между Feature и Epic в разных компаниях плавают — важнее иерархия, а не жёсткие названия в Jira.
Definition of Ready и Definition of Done
Definition of Ready (DoR)
DoR отвечает: «Можно ли начинать разработку?» Типичные критерии:
- есть понятное описание и acceptance criteria;
- зависимости известны или сняты;
- нет блокирующих открытых вопросов;
- задача оценена (если команда оценивает до спринта).
DoR снижает «зависание» задач в статусе In Progress из-за неясных требований.
Definition of Done (DoD)
DoD отвечает: «Когда задача действительно готова?» Пример для production-ready команды:
- код написан и прошёл code review;
- unit/integration-тесты добавлены и зелёные;
- QA проверил по acceptance criteria;
- документация/API обновлены;
- задеплоено на staging (или prod — по политике команды).
DoD — договор команды, а не личное «я считаю, что готово». Без общего DoD velocity и «завершённые SP» теряют смысл.
События спринта: Review и Retrospective
Sprint Review
В конце спринта команда показывает работающий инкремент stakeholders: не слайды «мы почти сделали», а demo. Собирают обратную связь, обновляют приоритеты backlog. Review — про продукт, не про процесс.
Sprint Retrospective
Сразу после review — ретроспектива: что прошло хорошо, что мешало, что попробовать в следующем спринте. Одна конкретная улучшение лучше десяти абстрактных «надо лучше коммуницировать».
Daily Scrum
Daily — не отчёт начальству, а план на ближайшие 24 часа: что сделал, что буду делать, что блокирует. Три вопроса — шаблон, не dogma; главное — синхронизация и раннее обнаружение блокеров.
Заблуждения об Agile
| Миф | Реальность |
|---|---|
| Story Points = часы | SP — сложность и риск, не календарь |
| Velocity = KPI программиста | Velocity — свойство команды и её шкалы |
| Agile = без документации | Нужна достаточная документация, не тонны ТЗ |
| Scrum подходит всем | Для исследований, саппорта, жёстких процессов соответствия требованиям часто лучше Kanban или гибрид |
| Agile = хаос без планов | Планирование есть на каждом спринте и на уровне roadmap |
Как связаны все термины
Типичный поток:
- PO формирует Product Backlog из epics и user stories.
- На Sprint Planning команда выбирает элементы в Sprint Backlog.
- Stories оценивают в Story Points через Planning Poker.
- В Sprint команда работает к Definition of Done.
- По итогам спринта считают Velocity.
- Sprint Review показывает ценность; Retrospective улучшает процесс.
- Цикл повторяется.
FAQ
Можно ли перевести Story Points в часы?
Формально — иногда команда калибрует «1 SP ≈ полдня», но это локальная эвристика, не свойство SP. Как только SP превращают в скрытые часы для контроля людей, теряется смысл относительной оценки.
Чем Kanban отличается от Scrum?
Scrum — фиксированные спринты и роли; Kanban — непрерывный поток, WIP-лимиты, меньше prescribed-событий. Многие команды использую Scrumban: спринты + доска Kanban.
Сколько длится Sprint Planning?
Зависит от длины спринта. Правило большого пальца из Scrum Guide: до 8 часов на месячный спринт; для двухнедельного — часто 2–4 часа на две части (what + how).
Нужен ли отдельный Scrum Master в маленькой команде?
В стартапах роли часто совмещают, но функции остаются: кто-то должен защищать фокус команды и процесс. Совмещение PO и SM в одном лице — риск конфликта интересов.
Что такое spike?
Spike — timeboxed-исследование («узнать, как работает API X»), результатом которого часто становится решение и декомпозиция, а не production-код.
Дополнительные материалы
На stuzhuk.page по смежным темам:
- Bulletproof React — структура фронтенд-проекта, когда backlog растёт
- UX и ROI: данные вместо мнений — связь user story и бизнес-ценности
- Оптимизация баз данных — технический долг в backlog
- SEO, AEO, GEO и AISO — приоритизация «видимости продукта» рядом с фичами
Внешние ресурсы: Scrum Guide (2020), Agile Manifesto (RU).
Заключение
Agile — не модный словарь и не культ stand-up'ов. Это попытка сделать разработку предсказуемой, гибкой и прозрачной: короткие спринты, общий backlog, относительные оценки, регулярная обратная связь.
Запомните связку: Scrum организует работу, Sprint задаёт ритм, Backlog хранит планы, User Story описывает ценность, Story Points и Planning Poker помогают оценивать, Velocity — прогнозировать, DoR/DoD — договариваться о готовности. Все инструменты существуют ради одного: полезного продукта для пользователей и бизнеса.