SCRUM (англ. scrum - "схватка") — это методология управления проектами, которая чаще всего встречается при разработке программного обеспечения (англ. software development), но может применяться и в других сферах, в том числе в сферах маркетинга (англ. marketing), продаж (англ. sales) и исследования (англ. research) чего-либо.
Если вы разработчик, то, возможно, вам нет смысла читать книгу о SCRUM - существует множество других книг, которые могут принести вам намного больше пользы.
Очень детально изучить SCRUM стоит менеджерам (например, проектным менеджерам), бизнес-аналитикам. Идеал недостижим, но к нему стоит стремиться. А ещё их об этом очень активно спрашивают на собеседованиях, поскольку эффективное управление - их основная задача. Основная же задача программиста - создание чего-либо.
Очень часто программисты, которые доходят до позиции Team Lead или хотя бы Tech Lead и думают о своём дальнейшем развитии, уходят в менеджмент впоследствии. Потому что чем больше людей в твоём подчинении, тем выше твоя позиция и больше доход. Более того, многие задачи можно делегировать, выстраивая иерархию ответственности. И код самому больше писать уже не нужно - сплошные митинги. Не всем такое подходит, но очень многим.
В реальной жизни в 90% случаев SCRUM используется не больше, чем на 50% от того, что в нём предусматривается.
Чаще всего на небольших проектах с маленькими командами имеется двухнедельный спринт, спринт планинг, доска в Trello с несколькими колонками (Backlog, To do, Doing, Done) и несколько звонков разработчиков с заказчиками в неделю. Вот и весь SCRUM.
Спринт (англ. Sprint) - итерация в скраме, в ходе которой создаётся инкремент бизнес-продукта; повторяющийся фиксированный временной интервал (repeatable fixed time-box) от одной недели до месяца, в течение которого создаётся "готовый" (Done) продукт с максимально возможным значением (value). Спринты имеют одинаковую продолжительность на протяжении всего процесса разработки. Новый Спринт начинается сразу после завершения предыдущего Спринта. Чем короче спринт, тем гибче скрам и тем чаще выходят релизы.
Бэклог продукта (англ. Product Backlog) - упорядоченный список всего, что может быть нужно продукту; единственный источник требований любых будущих изменений продукта. За бэклог продукта отвечает владелец продукта (содержание, доступность, упорядочивание).
Бэклог спринта (англ. Sprint Backlog) - набор элементов из бэклога продукта, выбранных для спринта, а также план доставки инкремента продукта и реализации целей спринта.
Инкремент (англ. Increment) - совокупность всех элементов бэклога продукта, выполненных за время спринта, и значение инкрементов всех предыдущих спринтов.
Скрам-командой (англ. Scrum team) называют команду, которая работает над проектом, разрабатывающимся по методологии SCRUM.
В скрам-команду входят:
- Владелец продукта (
Product Owner) - Скрам-мастер (
Scrum Master) - Команда разработчиков (
Developer Team)
включает в себя владельца продукта, скрам-мастера и команду разработчиков.
Владельцем продукта (англ. Product Owner) называют члена скрам-команды, который знает и понимает желания клиента (англ. customer) и может донести команде их бизнес-значение (business value).
Владелец продукта может консультировать команду, чтобы она корректно выполняла свои задачи.
Владелец продукта должен принимать все важные решения для завершения проекта.
Владелец продукта отвечает за бэклог продукта. Пункты в бэклоге должны быть чёткими и понятными всем, отсортированными по значимости (value).
Скрам-мастер (англ. Scrum Master) управляет скрам-процессом, помогая команде быть отчётной (accountable) за свои обязательства перед бизнесом и устраняя любые препятствия работе и продуктивности команды.
Скрам-мастер организует митинги.
Скрам-мастеру следует тренировать и мотивировать команду, а не навязывать ей правила.
На реальных проектах скрам-мастером чаще всего назначают одного из членов других частей скрам-команды. Я участвовал на проектах, на которых скрам-мастером могли быть:
- Владелец продукта.
- PM/BA.
- Опытный разработчик из команды разработчиков с хорошими коммуникационными способностями.
Команда разработчиков (англ. Developer Team, Dev Team, Engineering Team) структурирована и уполномочена на организацию своей работы. Хорошая синергия команды оптимизирует общую эффективность и результативность.
Команда разработчиков самоорганизуется: никто (даже скрам-мастер) не говорит команде, как превратить бэклог продукта в инкременты.
Скрам не признаёт званий членов команды вне зависимости от их деятельности.
Скрам не признаёт подгруппы в команде разработчиков вне зависимости от их областей (тестирование, архитектура, бизнес-анализ). Отдельные члены команды могут обладать специализированными навыками, но отчётность (accountability) принадлежит всей команде в целом.
Скрам-событиями называют митинги, которые команды проводят каждый спринт.
- Планирование спринта (англ.
Sprint Planning) происходит в его начале. Обсуждаются задачи на следующий спринт, выбирающиеся из бэклога проекта. - Ежедневный скрам (англ.
Daily Scrum) - 15-минутное событие для команды разработчиков, предназначенное для синхронизации действий и создания плана на ближайшие сутки. - Ревью спринта (англ.
Sprint Review) происходит в конце спринта. Проверяется Инкремент спринта и, при необходимости, пополняется бэклог продукта. - Ретроспектива спринта (англ.
Sprint Retrospective,Retro) предоставляет возможность скрам-команде изучить себя и составить план улучшений, которые будут приняты во время следующего спринта.
На практике чаще всего
Планирование спринта проводится в начале нового спринта на митинге.
Продолжительность митинга зависит от продолжительности спринта.
На первой части митинга участвует вся скрам-команда (владелец продукта, скрам-мастер и команда разработчиков): обсуждаются задачи на текущий спринт. Задачи берутся из бэклога проекта с учётом того, что команда успеет выполнить за спринт. На второй части митинга участвует только скрам-команда: обсуждаются технические детали реализации, заполняется бэклог спринта.
- Выбираются задачи из бэклога проекта, на основании которых создаётся бэклог спринта.
- Задачи оцениваются в человеко-часах (не более 12 часов или одного дня на задачу) либо в стори-поинтах. Слишком долгие задачи разбиваются на подзадачи.