Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Scrum предназначен для быстрой разработки и поставки сложных, принципиально новых продуктов, которых нет на рынке.
Когда команда начинает применять Scrum, ее работа, как правило, становится более слаженной и предсказуемой, а сроки разработки новых продуктов зачастую сокращаются в разы.
Когда зрелого продукта еще нет, а есть только идея и, может быть, первые рабочие прототипы, тогда никто не может дать четкий план, куда должна пойти траектория разработки. Все неопределенно и требует проверки на реальном клиенте. А Scrum позволяет постепенно «развеять» эту «пелену неопределенности», двигаясь небольшими итерациями и постоянно проверяя: мы делаем то, что нужно клиентам? приносит ли это пользу?
Основную цель Agile и Scrum часто формулируют как сокращение Time2Market — времени выпуска на рынок новых продуктов / времени их поставки потребителю.
Вкратце, Scrum требует, чтобы Scrum Master способствовал возникновению среды, в которой:
- Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog.
- Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность.
- Scrum Team и заинтересованные лица инспектируют результаты и вносят правки для следующего Sprint.
- Повторить
В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берёт на себя обязательства по выполнению объёма работ на спринт перед Владельцем продукта (Product owner). Работа команды оценивается как работа единой группы.
Команда в Scrum кроссфункциональна. В неё входят люди с дополняющими навыками — разработчики, аналитики, тестировщики, дизайнеры. Нет заранее определённых ролей и специализаций в команде, ограничивающих область дейстий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на возможные изменения.
Размер команды ограничивается размером группы людей способных эффективно взаимодействовать «лицом к лицу». Типичный размер команды — 7 ± 2 человека. Чем ближе к нижней границе — тем лучше.
Команда:
- Кросс-функциональная
- Владеет планом итерации
- Принимает обязательство достичь цели спринта
- Самоорганизуемая
- Работает вместе, помогая друг другу
Чеклист:
- Команда сидит в одном месте или находится в постоянном тесном контакте онлайн (colocation)
- Члены команды чувствуют ответственность по отношению друг к другу
- Команда кроссфункционально — нет закреплённых отдельных ролей за членами команды
- Члены команды работают совместно над завершением фич более высокого приоритета в первую очередь.
- Члены команды признают наличие проблем и просят друг друга о помощи
- Члены команды помогают друг другу
Скрам-мастер — член команды. Основная его задача — помочь команде стать самоуправляемой и самоорганизующейся. Он следит за тем, чтобы команда выполняла принятые ей решения, за соблюдением практик и отвечает за решение проблем, обнаруженных командой и находящейся вне её компетенции.
Скрам-мастер не раздаёт задачи членам команды. Скрам-мастер — один из членов команды. Он может быть разработчиком, тестировщиком, аналитиком и т.д.
Скрам-мастер проводит командные митинги: стендап (дейли-митинг), планирование спринта, демонстрацию и ретроспективу.
Скрам-мастер также отвечает за удаление всех внешних препятствий, мешающих команде. Например, если команде нужен новый сервер, то именно скрам-мастер вступит в бой с бюрократическими силами компании. На практике часто бывает, что скрам-мастер просто обозначает соответствующую проблему менеджменту и уже менеджер занимается её решением.
Скрам-мастер следит за климатом внутри команды и старается создать атмосферу доверия. Это ни в ком случае не означает, что скрам-мастер «гасит» все конфликты между членами команды. Напротив, конфликт должен быть вытящен на обсуждение как можно быстрее и конструктивно решён.
По мере того, как команда становится самоорганизующейся, роль скрам-мастера уменьшается.
Скрам-мастер:
- Помогает внедрять скрам
- Отвечает за процесс (как)
- Учитель
- Наставник (коуч)
- Модератор
- Сторожевой пёс
- Защитник
- Устраняет помехи
Чеклист:
- Скрам-мастер есть
- Скрам-мастер следит за выполнением командных практик Scrum
- Скрам-мастер — член команды (а не менеджер и не владелец продукта)
- Скрам-мастер помогает устранить внешний препятствия
- Скрам-мастер следит за выполнением командой принятых ей решений
Владелец продукта (Product Owner, PO) — это человек, отвечающий за разработку продукта. Это может быть менеджер продукта для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Владелец продукта — это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.
Это позволяет избежать проблемы множественности заказчиков. Управляет ожиданиями заказчиков и всех заинтересованных лиц. Владелец продукта должен чётко понимать, какие фичи должны быть сделаны и каковы их приоритеты.
Владелец продукта ставит задачи всей команде, но он не вправе ставить задачи конкретному члену команды.
Владелец продукта:
- Принимает готовое
- Рассчитывает ROI
- Бэклог продукта
- Приоритеты
- Инициатор изменений
- Работает с заинтересованными лицами
- Видение продукта
- Постоянно делится информацией
- Обеспечивает ресурсами
Чеклист:
- У команды только один владелец продукта
- PO устанавливает приоритеты элементов бэклога для своей команды
- PO достаточно хорошо разбирается в продукте и предметной области для того, чтобы правильно расставить приоритеты
- PO отвечает за формирование концепции продукта (Product Vision)
- PO является основной точкой коммуникации для заказчиков и всех заинтересованных лиц
- PO отвечает за предоставление требований (к продуктам, фичам) команде
- PO отвечает за приёмку результатов в конце каждой итерации
В течение одной итерации команда общается с заказчиками, анализирует, пробует, разрабатывает и тестирует код. В конце каждой итерации (спринта) демонстрируется полностью доделанная за итерацию функциональность. Заказчики смотрят на результаты работы. Все предложения по улучшению планируются на последующие итерации. Внутри итерации заказчики стараются воздерживаться от изменения требований.
Такими короткими шагами раз за разом мы приближаемся к желаемому результату, корректируя по ходу направление нашего движения.
Длина итерации — от 1 до 4 недель. Типичная длина итерации — 2 недели.
Чеклист:
- В конце итерации есть готовый инкремент продукта
- Фичи, которые начинаются в эту итерацию, в ней же и доделываются
- Разработка фичи включает тестирование и исправление найденных багов
- Команда соблюдает приоритеты фич, установленные Владельцем продукта
- В большинстве случаев команда делает то, что было запланировано: иногда чуть больше, иногда чуть меньше
- Команда сообщает Владельцу Продукта, когда отстаёт от плана итерации
- В случае отставания от плана команда предпринимает корректирующие действия
- Для каждой фичи команда знает, каким образом и от кого получить необходимую дополнительную информацию в случае необходимости
- Проблемы обнаруживаются быстро и обсуждаются командой сразу же
- Длина итерации не меняется после каждой итерации
- Вся незапланированная работа учитывается
- Не более одного дня задержки между итерациями
- Заинтересованные лица (Stakeholders) знают о том, что работа ведётся итерациями
Бэклог продукта — это приоритезированный список имеющихся на данный момент нереализованных пользовательских историй (user story) / фич.
Бэклог продукта может включать фичи (пользовательские истории, запросы на изменения), технические истории, баги и технический долг, открытые вопросы. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добавить памяти на машины".
Бэклог продукта постоянно пересматривается и дополняется — в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За бэклог продукта отвечает Владелец продукта. Он работает совместно с командой для того, чтобы получить приближённую оценку фич из бэклога продукта.
Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum Team. Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовности в течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning. Они достигают такого уровня прозрачности после активностей по уточнению. Уточнение Product Backlog — это процесс разбиения элементов Product Backlog на более мелкие и конкретные элементы, и их дальнейшего уточнения. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер. Атрибуты элементов зависят от предметной области выполняемой работы и могут быть очень разными. Оценку размера элементов производят Developers, которые будут выполнять работу. Product Owner может влиять на Developers, помогая им понять элементы и обсуждая компромиссы.
Чеклист:
- PO управляет и координирует backlog
- Product Backlog содержит фичи (user story), а не технические задачи
- Product Backlog виден каждому
- Product Backlog обновляется перед планированием спринта
- PO понимает все фичи / пользовательские истории из бэклога
Встреча, на которой команда и PO планируют итерацию. PO ставит цели спринта и представляет фичи (пользовательские истории). Команда декомпозирует фичи на технические задачи и совместно оценивает их. Итоговый план таймбоксится, то есть в него включаются только те фичи, которые команда планирует успеть сделать в итерации.
Для таймбоксинга спринта используется Скорость (Velocity) команды.
Декомпозиция задачи должна быть достаточно детальной. Для двухнедельной итерации рекомендованная длительность технической задачи – порядка дня (не более двух дней).
Чеклист:
- PO и члены команды участвуют все (очень желательно, лично)
- Результат — план итерации
- Все члены команды согласны с планом
- Все члены команды согласны с тем, что план может быть выполнен за итерацию
- Каждая фича имеет приоритет внутри итерации
- Все технические задачи имеют оценки
- Все фичи имеют оценки (складываются из оценок технических задач)
- Планирование начинается и заканчивается вовремя (это касается всех встреч) (по крайней мере нужно к этому стремиться)
- На планировании итерации технические задачи не назначаются на конкретных людей
Команда совместно с PO осуществляет долгосрочное планирование. Команда оценивает фичи из бэклога.
Фичи оцениваются в условных единицах (story points), либо идеальных человеко-днях (ideal man-days). Для оценки часто используется практика Planning poker.
PO формирует долгосрочный план (план релиза) на основании оценок команды и знания скорости команды. В долгосрочном плане указано какие фичи в какой итерации планируется сделать.
Чеклист:
- PO отвечает на вопросы команды во время оценки
- Только команда может оценивать
- Все члены команды участвуют в оценке
- Фичи достаточно декомпозированы и по возможности достаточно небольшие, так что несколько фич может быть сделано за одну итерацию
- Долгосрочный план корректируется каждую итерацию
План итерации — набор фич и задач (на которые фичи декомпозируются), которые команда собирается выполнить в итерацию.
План итерации поддерживается командой в актуальном состоянии в течение итерации. Для ведения плана итерации удобно использовать доску задач (Task Board).
Чеклист:
- Все видят план итерации
- Для каждой фичи из бэклога указаны приёмочные тесты / критерии приёмки / сценарий демонстрации
- Каждая фича на плане декомпозируется в технические задачи
- Оценки и приоритеты задач при необходимости корректируются членами команды в течение итерации
- Члены команды регулярно актуализируют план
Определение готовности — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту. В момент, когда элемент Product Backlog стал соответствовать определению готовности, рождается Increment.
Примеры DoD для User Story:
- Написаны и пройдены unit-тесты
- Проведено Code review
- Функциональные тесты пройдены
- Написана краткая справка для пользователя по фиче
- Фича / страница добавлена в меню сайта / приложения
Физическая или электронная доска, на которой отражены задачи с их статусами. Пространство доски поделено на колонки.
Левая колонка (To Do) предназначена для задач, за которые ещё никто не брался. Прикрепляем карточки в этой колонке так, чтобы карточки с задачами находились рядом с соответствующими карточками фич.
Вторая колонка (In Progress) — для задач, которые находятся в работе. Разработчик берёт задачу из ToDo, перевешивает в In Progress и подписывает в тот момент, когда берёт задачу в разработку.
Как только задача сделана, разработчик перемещает карточку в третью полосу (Done). Теперь он может взяться за следующую задачу. Он берёт карточку, подписывает и перемещает на вторую.
Таким образом, задачи постепенно перемещаются из первой в последнюю колонку. Ко концу итерации туда должны переместиться все задачи. Количество колонок может быть больше, они фактически отражают жизненный цикл задачи.
Чеклист:
- Доска задач физически висит в комнате команды (или по крайней мере в лёгком доступе онлайн)
- Стендапы (дейли митинги) проводятся возле доски задач
- По итогам стендапа доска задач актуализируется
- Каждая задача в In Progress имеет ответственного
Короткая ежедневная встреча, предназначенная для синхронизации работы команды.
Проводит митинг скрам-мастер. Он спрашивает по кругу всех членов команды, задавая 3 вопроса:
- Что сделано вчера
- Что будет сделано сегодня?
- С какими проблемами столкнулся / нужна ли помощь?
Достаточно часто завязываются обсуждения по тем или иным вопросам. Пока два человека спорят друг с другом, все остальные скучают и начинают отвлекаться. Поэтому задача скрам-мастера — останавливать такие обсуждения и выносить их за пределы стендапа. Даже если возникшая дискуссия затрагивает всех участников, лучше её остановить, закончить стендап и затем снова продолжить обсуждение.
Чеклист:
- Проводится в одно и то же время в одном и том же месте
- Длительность не более 15 минут
- Начинается и заканчивается вовремя (дисциплина!)
- Все члены команды участвуют и отвечают на 3 вопроса
- Стендап не прерывается
- Члены команды сами выбирают задачи на стендапе
- Скрам-мастер не раздаёт задачи!
- Члены команды обращаются друг к другу, а не отчитываются перед скрам-мастером или менеджером
Скорость команды рассчитывается как сумма оценок фич, которые были сделаны командой за итерацию.
Как правило, это значение со временем становится более или менее стабильным и от итерации к итерации меняется незначительно. Знание этой величины и оценок фич позволяет таймбоксить спринт и осуществлять долгосрочное планирование.
Чеклист:
- Скорость рассчитывается после каждой итерации
- В расчёте скорости учитываются только те фичи, которые удовлетворяютт критерию готовности (definition of done)
- Скорость используется для долгосрочного планирования
Для отслеживания прогресса в спринте используется диаграмма сгорания (burndown chart). По оси X — дни итерации, по оси Y — сумма оценок несделанных задач.
Вначале итерации эта сумма равна сумме всех оценок всех задач. Каждый день в одно и то же время (например, перед стендапом) скрам-мастер рассчитывает новую точку и ставит её на диаграмме.
На диаграмму также наносят прямую линию, которая демонстрирует "идеальное" сгорание работы. Если график сгорания выше, чем идеальная кривая — значит команда отстаёт, если ниже — опережает график.
Чеклист:
- Диаграмма видна всем
- Диаграмма предназначена для команды, а не для менеджеров
- Диаграмма актуализируется каждый день
- Команда предпринимает действия, когда значения слишком велики или малы
Главная цель демонстрации — рассказать PO и всем заинтересованным лицам (стейкхолдерам) о прогрессе и получить с них обратную связь. Демо проводится в конце каждой итерации. Команда показывает результаты своей работы, например последовательно показывая сделанные фичи / пользовательские истории.
Не имеет смысла показывать или обсуждать на демо вопросы, не касающиеся приглашённых заинтересованных лиц.
Чеклист:
- Проводится после каждой итерации
- Показывается работающая система (не презентации и не написанные классы)
- Показываются только сделанные фичи (не доделанные — не показываются)
- Все заинтересованные лица приглашаются на демо
- Команда получает от заинтересованных лиц обратную связь
- PO корректирует бэклог продукта в соответствии с пожеланиями заинтересованных лиц
Цель Sprint Retrospective — запланировать повышение качества и эффективности.
Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий, процессов, инструментов и определения готовности. Выявляются предположения, которые сбили Scrum Team с пути, и исследуется их происхождение. Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они столкнулись, и как эти проблемы были (или не были) решены.
Scrum Team определяет наиболее полезные для повышения эффективности изменения. Улучшения с самым высоким влиянием реализуются в кратчайшие сроки. Они могут даже быть добавлены в Sprint Backlog следующего Sprint.
Критерии готовности — определение готовности фичи в виде чеклиста. Можно ли считать фичу сделанной? Такой вопрос часто возникает и иногда является источником споров команды, PO и заинтересованных лиц.
Команда и владелец продукта договариваются о критериях готовности фич. Они формулируются сразу для всех фич и могут доопределяться для каждой конкретной фичи.
Пример критериев готовности:
- Фича создана и работает на stage
- Проведено тестирование
- Отсутствуют критические и мажорные дефекты
- Написаны unit-тесты
- Проведено code review
- и т.п.
Иногда критерий готовности также определяется для отдельной технической задачи или требования.
Чеклист:
- Критерии готовности (DoD) сформулированы командой и PO
- Команда соблюдает критерии готовности
- Все члены команды PO знают критерии готовности
- Критерии готовности включают то или иное тестрирование
- Команда не зависит от других людей для того, чтобы обеспечить выполнение критериев готовности
- Критерии готовности регулярно корректируются (в частности, по результатам ретроспектив)
- Story points (Planning poker)
Статьи:
- scrumtrek:: Scrum: что это и зачем нужно
- Unusual Concepts: статьи по Scrum
- BrainRain: Agile Scrum Blog
- Асхат Уразбаев:: Обзор методологии Scrum
- «Scrum. Революционный метод управления проектами». Книга за 15 минут
- AniArt: Как мы делали SCRUM
- Понимание относительных оценок в Agile. Даёшь Story Points!
- User Story — инструкция по применению
- T-Shaped подход: разные компетенции
- Agile-подход в государственном управлении
Книги:
- «Руководство по Scrum 2020», Кен Швабер и Джефф Сазерленд
- «Заметки с передовой», Хенрик Книберг
- «Scrum и Kanban: выжимаем максимум», Хенрик Книберг и Маттиас Скарин
- «Scrum. Гибкая разработка ПО», Макйл Кон
- «Scrum. Революционный метод управления проектами», Сазерленд Джефф
- «Пользовательские истории. Гибкая разработка программного обеспечения», Кон Майк
Видео: