Основы Scrum
Тема дорожной карты · Agile / Scrum / Kanban
Scrum — гибкий фреймворк, определённый в Scrum Guide (Schwaber & Sutherland). Scrum-команда состоит из трёх ролей (Product Owner, Scrum Master, Developers), создаёт ценность через спринты фиксированной длины (обычно 2 недели) и использует пять событий + три артефакта для inspect-and-adapt. Весь Scrum Guide умещается на ~13 страницах — компактность намеренная, всё лишнее — уже не Scrum.
Как это работает
Механика Scrum обманчиво проста. Спринт — пульс: контейнер фиксированной длины (типично 2 недели, максимум месяц). Внутри команда коммитится к Sprint Goal, строит работу из Product Backlog, проводит Daily Scrum для инспекции прогресса, демонстрирует на Sprint Review, рефлексирует на Sprint Retrospective и сразу начинает следующий спринт. Три артефакта (Product Backlog, Sprint Backlog, Increment) имеют по 'обязательству' (Product Goal, Sprint Goal, Definition of Done), которые якорят решения при возникновении неопределённости.
Когда применять
Scrum лучше всего работает на командах 3-10 разработчиков + 1 PO + 1 SM, на сложных продуктах, где требования возникают в процессе, при стабильном составе команды (без project-based текучки) и со стейкхолдерами, готовыми принимать рабочее ПО каждые 2 недели. Плохо работает когда: работа последовательна по своей природе (research без отгружаемых инкрементов), команда слишком большая (делите на несколько Scrum-команд через LeSS/Nexus) или организация не выдерживает видимую work-in-progress.
Типичные ошибки
У Scrum больше антипаттернов, чем канонических реализаций, потому что каждая организация кастомизирует: пропуск ретро, превращение Daily в status-meeting для менеджера, разрешение PO пушить backlog Developers'у в середине спринта, 'гибкая' длина спринта. Каждое нарушение ломает одну из inspect-and-adapt петель, которые делают Scrum работающим — фреймворк намеренно хрупок, потому что каждое событие несёт нагрузку.