Роли, процессы и артефакты в Scrum: дьявол в деталях
15 Ноя 2019
Это шестая статья из серии «Введение в Agile». В ней мы расскажем о ролях и артефактах Скрам, а также о практиках, которые дополняют Скрам.
До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile, а также познакомились с основами Scrum:
- Часть 1. Agile и классическое проектное управление: в чем разница?
- Часть 2. Как определить, что вашему проекту нужен Agile?
- Часть 3. Почему Agile не «внедряют», или как «вырастить» Agile?
- Часть 4. Хочу быть Agile! Но как?
- Часть 5. Scrum: сила простоты или сложность совершенства в Agile?
Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании, в которой он тогда работал. Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.
Роли в Скрам
В Скрам выделяют три роли: Владелец продукта, Скрам-мастер и Команда разработки. Все вместе они составляют Скрам-команду.
Владелец продукта – это представитель пользователя, который в то же время заинтересован в рациональном использовании ресурсов команды. Владелец продукта должен четко представлять себе портрет финального заказчика, его потребности, предпочтения по продукту и цели, для которых разрабатывается продукт. Владелец продукта должен иметь достаточно компетенций и полномочий, чтобы принимать решения по продукту от имени заказчика.
Владелец продукта должен обладать стратегическим мышлением, ведь он отвечает не только за создание продукта, но и за поддержку его в будущем, на следующих этапах жизненного цикла продукта. Вместе с тем Владелец продукта должен быть готов тесно работать с командой, формулируя видение продукта, требования к функционалу, принимая или отвергая рабочие результаты.
Поскольку Владелец продукта отвечает за успех своего продукта, он занимает роль лидера в команде, в то же время тесно сотрудничая с другими участниками и не имея формальной власти над ними. Роман Пихлер в книге «Управление продуктом в Scrum. Agile методы для вашего бизнеса» описывает Владельца продукта как «первого среди равных» в команде.
Усилия Владельца продукта направлены не только внутрь команды, но и на окружение проекта. Ему необходимо общаться с разными заинтересованными сторонами, включая заказчиков, пользователей, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство. При этом важно, чтобы Владелец продукта не выступал «передаточным звеном» между заказчиком и командой, а мог самостоятельно защищать продукт и принимать по нему решения. Для этого ему нужно быть достаточно квалифицированным в предметной области проекта (разработка ПО, создание банковских продуктов или верстка веб-страницы).
Скрам-мастер – это эксперт в области Agile-практик, который помогает Команде разработки выстроить правильные процессы. На начальных этапах Скрам-мастер проводит встречи (Планирование спринта, Ежедневные летучки, Обзор спринта, Ретроспективу), поддерживает в актуальном состоянии артефакты процесса, защищает команду от внешних вмешательств: срочных поручений, не относящихся к разрабатываемому продукту, попыток изменить требования в ходе спринта и т.п.
Скрам-мастер оказывает поддержку Владельцу продукта и команде, защищает ее и процесс работы и при необходимости вмешивается, чтобы проверить, справляется ли команда с задачей, сохраняет ли здоровую атмосферу и мотивацию.
Роли Владельца продукта и Scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание ценного продукта. Scrum-мастер следит за правильным применением практик Scrum. Совмещение этих ролей создает чрезмерную нагрузку и смещение фокуса внимания, поэтому нельзя одновременно быть Владельцем продукта и Scrum-мастером.
Команда разработки – это те самые мотивированные профессионалы, которые заведомо мотивированы на создание результата. В Команде разработки должно быть не более 9 человек, все участники взаимозаменяемы, то есть могут помочь друг другу в выполнении задач. Кросс-функциональность позволяет Команде нести коллективную ответственность за результат.
Для того, чтобы создать успешную команду, необходимо минимизировать изменения в ее составе. По принципам командной динамики людям необходимо время, чтобы привыкнуть друг к другу, сработаться и выйти на оптимальный уровень производительности. Любой новый участник запустит этот процесс заново.
Чтобы сплотить команду, рекомендуют разместить всех участников в одном помещении. По мнению Филиппа Мисслера, CTO немецкой компании «mobile.de», это влияет не только на эффективность выполнения задач, но и на боевой дух команды. Для создания атмосферы в рабочем помещении повесьте на видном месте плакаты с ключевой информацией о продукте: формулировку концепции, наиболее приоритетные элементы Бэклога продукта, задачи текущего спринта. Если нескольким участникам команды нужно часто обсуждать результаты в рабочем режиме, лучше предусмотреть для таких встреч отдельное помещение, чтобы не мешать остальным.
Артефакты в Скрам
Бэклог продукта – это список всех элементов продукта, требований к ним и любой связанной с продуктом информации. Бэклог продукта формируется на всем протяжении проекта (может дополняться, детализироваться или сокращаться). Хорошая практика – привлечение всей Команды к корректировке Бэклога продукта, несмотря на то, что в основном за ведение Бэклога продукта отвечает Владелец продукта.
Бэклог продукта есть практически в любом Agile-проекте: это удобное средство для фиксации требований, задач и элементов продукта. Для оценки качества Бэклога применяется инструмент DEEP (от англ. detailed, estimated, emergent, prioritized): хороший Бэклог должен содержать детализированные, оцененные, независимые и приоритизированные элементы. Максимальную степень детализации должны иметь наиболее приоритетные элементы. Оценка элементов Бэклога помогает спланировать, что мы запланируем на следующий спринт, а что сделать не успеем. По мере создания продукта в Бэклог могут добавляться новые требования.
Для оценки элементов Бэклога применяются относительные величины, которые показывают совокупную величину элемента по сложности, трудоемкости или размеру. Распространены техники оценки в стори-поинтах (от англ. «story points», очки, баллы) – 0, 1, 2, 3, 5, 8, 13 или 20 стори-поинтов, или в размерах футболок – S – маленький элемент, M – средний, L – большой.
Если участники команды по-разному оценивают размер задачи или элемента, эту проблему можно решить с помощью покерного планирования. Каждому из команды выдается набор карточек, которые содержат все возможные значения для оценок. Выбирается элемент для оценки, команда кратко обсуждает его содержание, и каждый участник кладет карту со своей оценкой на стол рубашкой вверх. Затем оценки открываются и авторы оценок, которые наиболее далеки друг от друга, аргументируют свою позицию. Все участники забирают каждый свою карточку и голосование повторяется заново до тех пор, пока все оценки не совпадут.
Бэклог спринта – это набор элементов Бэклога продукта, который Команда принимает в разработку на ближайший спринт. В Бэклоге спринта также формулируется Цель спринта (Зачем мы работаем в этом спринте? Чего хотим достичь именно за эту итерацию?) и план по достижению этой цели.
Роман Пихлер в уже упоминавшейся книге «Управление продуктом в Scrum» приводит пример цели спринта, сформулированной как: «У высоких деревьев глубокие корни». Эта фраза отлично описывала цель спринта: закладку основания для всего последующего проекта. Цель нужна для объединения усилий команды в одном направлении, минимизации вариативности задач (ограничиваемся одной темой) и объяснения заинтересованным сторонам, над чем сейчас работает команда.
В Бэклог спринта должны попадать только такие элементы, которые удовлетворяют трем параметрам: они являются четкими, проверяемыми и осуществимыми. Четкость означает одинаковое понимание участниками команды сути задачи. Проверяемость означает наличие эффективного способа проверить, выполнена ли задача. Осуществимость означает возможность полностью выполнить эту задачу за один спринт.
Инкремент продукта – это сумма завершенных во время спринта Элементов Бэклога продукта и всех инкрементов предыдущих спринтов. То есть, это текущее состояние разрабатываемого продукта, включая доработки последнего спринта.
Процессы в Скрам
Планирование спринта проходит перед началом каждого спринта. Цель этого процесса – определить объем работ, который Команда возьмет в ближайший спринт. В ходе Планирования спринта Команда выбирает из Бэклога продукта самые приоритетные элементы (требования к продукту), детализирует их до уровня задач, оценивает трудоемкость и взаимосвязи между задачами.
Владельцу продукта на этой встрече необходимо помнить, что он может лишь помочь команде осознать, что должно быть сделано за спринт, но не указывать и не выбирать за команду задачи, которые нужно включить в Бэклог спринта. Команда, в свою очередь, берет на себя только тот объем работы, который действительно может выполнить. При этом нужно понимать, что решение команды – это не гарантия выполнения всех запланированных задач. Могут возникнуть непредвиденные сложности или новые внешние факторы.
Ежедневная летучка проводится каждый день в ходе Разработки, в одно и то же время. На этой встрече Команда обсуждает, что каждый из участников сделал за прошлый день, что планирует делать в следующий и в чем нужна помощь. Летучка длится не более 15 минут. Важно не отвлекаться на решение проблем в ходе встречи, а только обозначить их, и вернуться к решению после окончания, не отвлекая внимание других участников.
Владелец продукта постоянно посещает эти встречи. Он может поделиться с командой результатами и планами своей работы, однако не должен ставить задачи команде или каким-либо образом вмешиваться в комментарии по задачам.
Разработка – процесс, в ходе которого Команда выполняет задачи и реализует требования из Бэклога спринта. Основное правило разработки – запрет на изменение состава спринта. В ходе спринта нельзя добавлять к работе команды новые требования или отказываться от уже включенных в Бэклог спринта. Остановить выполнение спринта можно лишь в одном случае: если Цель спринта теряет свою актуальность. В этом случае проводится Ретроспектива для анализа причин возникшей ситуации и заново запускается Планирование спринта.
Обзор спринта – это открытая встреча для демонстрации результатов спринта. По итогам Обзора спринта должна быть получена обратная связь от пользователей по представленным результатам. При необходимости можно обновить Бэклог продукта.
Обзор спринта – это больше, чем совещание по статусу проекта с широким кругом лиц. Эта встреча дает возможность команде напрямую пообщаться с пользователями и заинтересованными сторонами, услышать их требования и комментарии по выполненной работе. Стоит помнить, что задача Обзора спринта – не показать инкремент продукта во всей красе, а предоставить возможность пользователям проанализировать работу, которая действительно была проведена, и обеспечить прозрачность хода проекта.
Ретроспектива – это закрытая встреча Команды, на которой оценивается прошедший спринт с точки зрения организации процессов. На Ретроспективе формулируются ответы на вопросы:
- Что было сделано хорошо?
- Как можно улучшить процесс?
- Какие улучшения будем делать в следующем спринте?
Ретроспектива поможет разрядить обстановку после Обзора спринта, на котором заказчик отказался принять инкремент продукта. Выявив причины сложившейся ситуации, команда может сделать вывод, что ей необходимо плотнее общаться с Владельцем продукта и помогать ему в работе с Бэклогом.
Резюме
Скрам в том виде, в котором он описан в официальном руководстве, содержит минимальный набор рекомендаций по организации работы команды: 3 роли, 3 артефакта и 5 событий. Однако применение этого фреймворка на практике и обмен опытом в профессиональном сообществе приводит к появлению множества практик, которые можно использовать в дополнение к основам. Сформулированы более детальные требования к ролям в Скраме, техники оценки сложности элементов Бэклога и примеры успешного проведения Скрам-событий.
На тренинге ICAgile Certified Professional вы можете почувствовать себя в роли участника Скрам-команды: спланируете спринт, оцените влияние непредвиденных ситуаций на рабочий процесс, проведете ретроспективу, оцените объем завершенной за спринт работы по сравнению с планом и научитесь учитывать эти результаты при планировании следующего спринта.
Смотрите также:
- Agile-трансформация и роль топ-менеджмента
- Жизненно необходимые практики для эффективной agile-команды, или что делать с wagile
- 7 примеров фейкового agile. Часть 1