Agile и Scrum

2001 год. Snowbird, Utah. 17 разработчиков в горнолыжном домике написали 68 слов - и этим разрушили методологию, которая доминировала в индустрии 30 лет. Waterfall не умер сразу. Но он начал умирать именно там.

• **Spotify** построил модель Squad/Tribe/Chapter/Guild на Agile-принципах - автономные команды с full ownership фичи. Результат: сотни независимых деплоев в день без централизованного координатора.
• **Amazon** практикует «two-pizza teams» - команда не больше той, которую можно накормить двумя пиццами. Это Agile-принцип кросс-функциональной небольшой команды в корпоративном масштабе.
• **Google** запустил Gmail как 20%-проект: инженер Пол Бухайт работал над ним в личное время в рамках неформального Agile - итерации, эксперименты, быстрая обратная связь. MVP внутри компании жил годы до публичного запуска.

Agile Manifesto: 68 слов, изменивших индустрию

Февраль 2001. Snowbird, Utah. Горнолыжный курорт, снег за окном, 17 разработчиков в одном домике. Три дня разговоров - и 68 слов, которые разрушили водопадную разработку, доминировавшую 30 лет.

Эти 17 человек - Кент Бек, Мартин Фаулер, Рон Джеффрис, Уорд Каннингем и другие - не просто написали документ. Они зафиксировали то, что уже работало на практике в XP, Scrum, DSDM, FDD. Манифест стал именем для паттерна, который индустрия нащупывала параллельно.

Четыре ценности Agile Manifesto: - **Люди и взаимодействие** важнее процессов и инструментов - **Работающий продукт** важнее исчерпывающей документации - **Сотрудничество с заказчиком** важнее согласования условий контракта - **Готовность к изменениям** важнее следования плану Правая часть важна - но левая важнее.

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

Agile не отменяет планирование - он делает план пересматриваемым. Спринт - это контролируемый эксперимент: сделали предположение о том, что ценно, проверили за 2 недели, скорректировали. Это не хаос - это итерации с коротким петлёй обратной связи.

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

Agile - не методология. Это философия. Scrum, Kanban, XP, SAFe - конкретные реализации с разными компромиссами. Можно быть Agile без Scrum. Нельзя быть Scrum без Agile-ценностей - это называется "cargo cult Scrum": ритуалы без смысла.

Scrum-церемонии: ритм, который держит команду

Scrum - это фреймворк с фиксированным ритмом. Спринт длится 1-4 недели (обычно 2). Каждый спринт начинается Sprint Planning, заканчивается Review и Retrospective. В промежутке - ежедневный Daily Standup. Этот ритм не случаен - он создаёт предсказуемость и регулярные точки адаптации.

Sprint Planning отвечает на вопрос: что команда сделает за этот спринт? Команда выбирает задачи из Product Backlog и создаёт Sprint Backlog. Ключевой артефакт - Sprint Goal: одна чёткая формулировка ценности, которую спринт должен принести. Не список фич, а бизнес-результат.

Daily Standup - 15 минут стоя (отсюда название). Не статус-митинг для менеджера. Синхронизация команды: что идёт по плану, что блокирует движение к Sprint Goal. Если разговор затягивается на конкретную проблему - выносить after-standup с заинтересованными.

Sprint Review vs Sprint Retrospective - их часто путают: - **Review** - смотрим на **продукт**: что сделано, получаем фидбэк от stakeholders, обновляем Backlog - **Retrospective** - смотрим на **процесс**: как команда работала, что улучшить в следующем спринте Review - внешний взгляд. Retrospective - внутренний.

Retrospective - самый недооценённый ритуал Scrum. Именно здесь происходит organizational learning. Команды, которые делают ретро серьёзно, через 6 месяцев выдают в 2-3 раза больше, чем те, кто пропускает или формализует его.

Refinement (Backlog Grooming) - технически не церемония, но регулярная активность. Команда и Product Owner уточняют, оценивают, декомпозируют задачи в Product Backlog. Обычно 1-2 раза в неделю, 1-2 часа. Цель - чтобы верхние задачи всегда были готовы к взятию в спринт.

Роли, velocity и story points

В Scrum три роли. Не «менеджер», не «тимлид» - три конкретные функции с чёткими зонами ответственности. Проблемы возникают, когда границы размываются.

**Product Owner** - отвечает за ценность продукта: - Владеет Product Backlog - Расставляет приоритеты (что важнее) - Принимает/отвергает результаты спринта - Представляет интересы бизнеса и пользователей - Один человек, не комитет **Scrum Master** - отвечает за процесс: - Помогает команде следовать Scrum - Устраняет блокеры (impediments) - Не менеджер - servant leader - Фасилитирует церемонии **Development Team** - отвечает за исполнение: - Кросс-функциональная: разработчики, тестеры, дизайнеры - Самоорганизующаяся: сама решает, как делать - 3-9 человек (Scrum Guide) - Нет иерархии внутри команды

Story points - относительная мера сложности задачи. Не часы. Не дни. Абстрактные единицы, которые команда калибрует для себя. Обычно используют шкалу Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Почему Фибоначчи? Потому что оценка неопределённости нелинейна: разница между 5 и 8 не такая же, как между 1 и 4.

Velocity - не KPI производительности. Не «команда A лучше команды B, потому что 40 SP > 25 SP». SP у каждой команды свои. Velocity - инструмент прогнозирования для самой команды: сколько задач возьмём в следующий спринт, когда выйдет релиз.

Definition of Done (DoD) - критическая концепция, которую часто пропускают. Это список критериев, при которых задача считается завершённой. Код написан? Нет. Код написан + ревью прошло + тесты написаны + QA проверил + документация обновлена + деплой на staging. DoD одинаков для всей команды и всех задач.

Распространённые ловушки Scrum: - **Scrum но без Daily** - «нет времени». Тогда это не Scrum. - **PO недоступен** - задачи берутся без понимания ценности, Backlog устаревает. - **Sprint = дедлайн** - команда работает овертайм последние 3 дня. Velocity нестабилен. - **Retrospective формально** - 15 минут, «всё хорошо», никаких action items. - **Velocity как KPI менеджера** - команда начинает накручивать SP, теряется смысл метрики.

Ключевые идеи

• **Agile - философия, Scrum - реализация**: четыре ценности Манифеста задают приоритеты, Scrum даёт конкретный фреймворк с ролями, церемониями и артефактами.
• **Ритм создаёт предсказуемость**: Planning - Daily - Review - Retrospective повторяются каждый спринт. Это не бюрократия - это короткая петля обратной связи, встроенная в процесс.
• **Velocity - прогноз, не KPI**: story points калибруются командой для прогнозирования, не для сравнения команд. Перегруз спринта снижает quality, не увеличивает throughput.

Связанные темы

Agile живёт не в вакууме - он требует технической базы и организационного контекста:

• CI/CD Pipeline — Непрерывная интеграция - техническая реализация принципа «работающий продукт каждый спринт»
• Unit Testing — Definition of Done в Scrum обычно включает написанные тесты
• Kanban и Lean — Альтернативный Agile-подход для потоковой работы без спринтов
• Эстимация и планирование — Story points и velocity - детальная техника оценки в Agile-контексте

Вопросы для размышления

• Если Agile ценит готовность к изменениям, как защитить команду от бесконечного потока «срочных» изменений в середине спринта?
• В каких ситуациях waterfall-подход будет лучше Scrum? Есть ли проекты, где итеративность вредит?
• Retrospective работает только при психологической безопасности - команда должна говорить правду без страха. Как создать такую среду?

Связанные уроки

• se-07 — Kanban - альтернативный гибкий процесс без спринтов
• se-29 — Story points и velocity - основа эстимации в Agile
• se-17 — CI/CD - техническая база, на которой работает Scrum
• se-10 — Unit-тестирование обязательно в Definition of Done
• se-27 — Техлид координирует команду внутри Scrum-структуры
• devops-09