Обсудить задачу
Термин · S

Scrum

Фреймворк гибкой разработки: команда работает спринтами по 1–4 недели, в конце каждого показывая работающий результат.

Scrum — самый распространенный фреймворк гибкой разработки (Agile). Работа идет короткими циклами — спринтами длиной от одной до четырех недель, чаще двухнедельными. В начале спринта команда выбирает, что успеет сделать, а в конце показывает работающий результат и обсуждает, как работать лучше. Подход сформулировали Кен Швабер и Джефф Сазерленд в 1995 году; правила описаны в кратком «Руководстве по Scrum», последняя редакция — 2020 года.

Роли

  • Владелец продукта (Product Owner) отвечает за ценность продукта: ведет список задач, расставляет приоритеты, принимает результат.
  • Scrum-мастер помогает команде работать по Scrum, убирает препятствия и защищает команду от отвлечений во время спринта.
  • Разработчики — все, кто создает результат: программисты, аналитики, тестировщики, дизайнеры. Обычно команда — до десяти человек.

События

  1. Планирование спринта — что и зачем будет сделано в этом спринте и как.
  2. Ежедневный Scrum — встреча на 15 минут: что мешает достичь цели спринта, нужно ли перестроиться.
  3. Обзор спринта — демонстрация результата заказчику и заинтересованным людям и обсуждение дальнейших шагов.
  4. Ретроспектива — что в работе команды получилось, что нет, и одно-два конкретных улучшения на следующий спринт.

Артефакты

  • Бэклог продукта — упорядоченный по приоритету список всего, что может понадобиться в продукте.
  • Бэклог спринта — задачи, выбранные на текущий спринт, и план их выполнения.
  • Инкремент — работающий результат спринта, который можно выпустить.

Отдельно команда договаривается о «критериях готовности» (Definition of Done): задача считается сделанной, только если код проверен на код-ревью, покрыт тестами, задокументирован и выкачен на тестовый стенд. Без этого «почти готовые» задачи копятся из спринта в спринт.

Чем Scrum помогает

  • Заказчик видит прогресс каждые две недели, а не в конце проекта.
  • Приоритеты можно менять между спринтами без хаоса внутри спринта.
  • Ретроспективы постоянно улучшают процесс.
  • Скорость команды становится измеримой, а сроки — предсказуемее.

Когда Scrum не подходит

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