Scrum: Действующие лица
May 23, 2018 · 6 min read
Базовое руководство по Scrum — Scrum Guide — весьма лаконичный документ. Не всегда можно сразу понять, что имели ввиду авторы и, тем более, почему.
Попробую рассказать о базовых принципах другими словами. Начну с команды.
Как ранее писал про Agile — основная область применимости Scrum — создание новых сложных продуктов, инноваций, работа в режиме неопределенности, когда не до конца понятно что создавать или как делать.
Как можно создать успешно новое и сложное? Научным путем, путем проб и ошибок. Сделать — собрать отзывы, обратную связь — уточнить видение — сделать следующий вариант. Пока не получится успешный вариант.
Чтобы делать много вариантов, тестировать, проверять, искать решение, нужна организация работы, которая позволяет быстро создавать и проверять гипотезы.
Скрам-команда (Scrum Team)
Суть Scrum — небольшая команда людей. (Scrum Guide)
Какой должен быть состав команды, которая может быстро проверять гипотезы? Скрам-команда (Scrum Team) включает в себя всего три роли:
Владелец продукта (Product Owner)
Владелец продукта отвечает за достижение максимальной ценности продукта.
Часто в работе над проектом руководство осуществляют несколько людей — менеджер по маркетингу, менеджер проекта, технический менеджер и так далее. Главные недостатки:
Задержки с принятием решения замедляют работу команды. Сначала тебе нужно понять, к кому обратиться за решением. Он не может принять сам, должен согласовать. Эффективность команды падает. Переключение на другие задачи — плохое решение. Рост количества “зависших задач”, переключения между задачами — потери. Чтобы избежать потерь, должен быть один единственный человек, который
Владелец продукта — единственный человек, отвечающий за список требований к продукту и ответственный за результат работы команды. Роль объединяет в себе функции разных ролей спонсора, менеджера продукта, руководителя проекта, менеджера по маркетингу, представителя клиента, участника команды. Всегда доступен команде, чтобы разъяснить требования или принять необходимые решения. Но не имеет формальной власти над командой разработки, является частью общей scrum-команды и должен быть не только лидером, но и хорошим командным игроком.
Роль владельца продукта — это краеугольный камень успешного применения гибкого управления продуктом в Scrum. Времена одиноких менеджеров продукта, запирающихся в кабинете и напрягающих мозги, чтобы разработать идеальные требования, прошли. Владелец продукта — это член scrum-команды, он готов к тесному и постоянному сотрудничеству.
Роман Пихлер. “Управление продуктом в Scrum”.
Из-за принципиальных отличий в полномочиях и зоне ответственности в Scrum используется термин владелец продукта, а не привычный менеджер продукта. Если не дать другое название, не будет однозначно понятен объем полномочий и ответственности человека. Начнется путаница. Прозрачность — один из главных принципов Скрам, и четкая отдельная терминология служит именно прозрачности.
Команда создания продукта (Development Team)
Один в поле не воин, нужна команда. Команда создания продукта — самоорганизующаяся, кросс-функциональная команда, которая на выходе каждой итерации создает потенциально продаваемый вариант продукта. Размер команды — от 3 до 9 человек. Для команды меньше трех человек нет смысла вводить какие-то практики. В командах больше 9 человек будут сложности с координацией и взаимодействием.
Внутри команды есть только одна роль — developer. Других должностей, ролей, под-команд — не должно быть.
Почему так и кто такой Developer?
Сталкивался со статьями, в которых пишут — разработчики ускорились с помощью Scrum, что привело к сбоям в работе тестировщиков (QA). Такая ситуация — следствие неправильной трактовки. Никакого отношения к Скрам не имеет. В Скрам команда должна выдать потенциально готовый к продаже продукт, а не кусок кода, требующий тестирования. Тестирование, развертывание — входят в понятие готового к продаже продукта. Эти работы должны выполняться внутри команды. Так мы приходим к следующем термину.
Кросс-функциональная команда — в команде должны быть все знания и навыки, позволяющие создать готовый к продаже продукт. Если говорить о программном продукте, то это дизайнеры, аналитики, программисты, тестировщики, devops-инженеры и так далее. Все, кто необходим. Если каких-то людей нет в команде, возникает необходимость обращения к внешним ресурсам, работающим по другим правилам. В этот момент работа замедляется или останавливается. Если команда полностью автономна, как с точки зрения знаний, так и полномочий, она может работать в своем темпе и результат зависит только от команды. Если команда зависит от внешних людей, у которых другие цели, приоритеты и правила, эффективного результата добиться будет очень сложно. Автономность принятия решения обеспечивает владелец продукта, автономность по навыкам — кросс-функциональность команды.
Теперь появляется противоречие:
Кроме того, люди могут болеть, уходить в отпуск. Требуется перекрытие по навыкам. Что делать?
Чтобы разрешить противоречие, необходимо, чтобы люди не только выполняли одну задачу, а могли помогать другим членам команды. Вместо узко-направленных специалистов (specialist или I-Shaped people) в команде требуются люди с широкой квалификацией, Т-образные личности (T-Shaped people или generalist). Скрам не требует, чтобы все люди были T-Shaped и обладали всеми навыками. Важно, чтобы все необходимые навыки были внутри команды, а какой комбинацией людей и навыков это будет решено — дело самой команды.
Кросс-функциональность, малый размер команды, широкие навыки, заменяемость и нацеленность на продукт, как на общий результат, приводят к отсутствию должностей или ролей внутри команды. Такое деление будет мешать команде, а не помогать ей.
Без должностей, с перекрытием и помощью друг другу, команда сама начинает решать как ей лучше работать. Появляется самоорганизующаяся команда — группа, которая сама умеет решать, как ей управляться с повседневными задачами. Коллективный разум, который мощнее индивидуального.
Скрам-мастер (Scrum Master)
Описанные выше правила работы не привычны. Для всех. Это достаточно серьезное изменение в работе как самой команды, так и её взаимодействии вовне. Любое изменение — всегда стресс, люди психологически всегда противятся изменениям. Как произвести изменения грамотно, организовать работу по новым непривычным правилам, и добиться успеха?
Для этого появляется новая, многим непонятная роль скрам-мастера. Основная ответственность скрам-мастера — организовать эффективный процесс. Скрам-мастер и владелец продукта дополняют друг друга. Владелец продукта нацеливается на создание лучшего продукта, скрам-мастер — на создание правильного процесса. Правильный процесс приводит к правильному результату. Сделать из индивидов самоорганизующуюся команду, способную эффективно решать инновационные задачи с высокой степенью неопределенности.
Скрам-мастер, как и владелец продукта, должен совмещать в себе одновременно много ролей.
В чем цель scrum-мастера? Она — в стремлении построить самоорганизующуюся команду и обеспечить самоорганизацию как ключевой принцип компании на всех уровнях. Самоорганизация порождает чувство вовлеченности и обязательности, делает людей более активными и ответственными. А это, в свою очередь, дает команде возможность находить собственные решения и делает ее более эффективной. Самоорганизация является ключевым аспектом высокой производительности команды, но не в краткосрочной, а в долгосрочной перспективе. Она позволяет по мере необходимости улучшать и адаптировать процессы, коммуникацию и сотрудничество. Создает сотрудников с высокой мотивацией, а будучи примененной к группе людей, помогает им выстроить настоящую команду — с едиными целью и идентичностью.
… Помните Scrum-мастер является проводником на пути agile-трансформации. Scrum-мастер должен держаться не более чем на один шаг впереди команды и организации, вытаскивая их из устоявшихся привычек и обычаев.
Зузана Шохова. “Путь скрам-мастера”
Если внимательно изучать Скрам, то принципы, лежащие в его основе, весьма логичны. Кратко резюмируя по ролям команды, чтобы создать нечто новое, Скрам предлагает:
Роли scrum и правда о должностях в scrum
Узнайте, почему три роли scrum (scrum-мастер, владелец продукта и команда разработчиков) описывают ключевые обязанности, а не конкретные должности.
Просмотр тем
Какие три роли существуют в scrum?
Scrum подразумевает три роли: владелец продукта, Scrum-мастер и участники команды разработчиков. Хотя все кажется довольно понятным, с обязанностями таких должностей можно запутаться. Многие команды спрашивают, нужно ли им менять названия должностей при внедрении Scrum. Если коротко: нет, не нужно.
В этой статье мы разберемся с ролями Scrum и поговорим о том, как вы можете использовать их в своей организации, не печатая новые визитные карточки.
Роли Scrum и должности
Три роли Scrum описывают основные обязанности участников Scrum-команды. Это не должности. А значит, взять на себя одну из этих ролей может сотрудник с любой должностью, в том числе и вы. Поскольку суть Scrum заключается в эмпирическом подходе, самоорганизации и постоянном совершенствовании, эти три роли дают минимальное определение обязанностей и подотчетности для эффективного выполнения работы в команде. Они позволяют командам нести ответственность за свою организацию и постоянно совершенствоваться.
Создание scrum-команды
Scrum — это методика, позволяющая выстраивать рабочие процессы в команде. Она представляет собой базовую структуру для организации регулярных собраний, создания артефактов и определения обязанностей каждого участника.
Однако вы не получите универсальной модели для работы в команде. Например, если команда создает веб-приложение для страхования, им понадобятся люди, знающие технологию, внутренние системы и предметную область бизнеса. При этом команде, работающей над следующим поколением игры Donkey Kong, нужны совершенно другие навыки. Им понадобятся графический дизайнер, инженер звукозаписи и графический разработчик. Поскольку решаемые проблемы отличаются, структура и навыки команды тоже должны быть разными.
Все становится еще труднее по мере увеличения сложности проблемы, которую пытается решить команда. Как говорится, «вы не знаете, чего вы не знаете, пока не узнаете, что вы об этом не знали». Команды могут не знать заранее, какие навыки им понадобятся или какой объем работы потребуется сделать, и потому им нужен запас гибкости, чтобы менять курс по мере накопления знаний.
Чтобы немного систематизировать этот сложный, постоянно меняющийся и зачастую раздражающий мир, Scrum предоставляет простую структуру с тремя ролями: участник команды разработчиков, владелец продукта и Scrum-мастер.
Команда разработчиков: переопределение понятия «разработчик»
Команда разработчиков — это люди, выполняющие работу. Сперва можно подумать, что под командой разработчиков подразумеваются только технические специалисты. Но это не всегда так. Согласно руководству по Scrum, команда разработчиков может состоять из людей самых разных профессий, в том числе дизайнеров, писателей, программистов и т. д.
Представьте, что у вас есть дом и вы нанимаете «разработчика». Он разрабатывает проект и выполняет работу. Да, он может класть кирпичи, заниматься водопроводом и даже копать огромные ямы, но этот человек все равно просто «разработчик». Это значит, что роль «разработчика» в Scrum означает участника команды, который обладает определенными навыками, необходимыми для выполнения работы в команде.
Команда разработчиков должна уметь самостоятельно организовывать себя, чтобы принимать решения относительно выполнения работы. Команду разработчиков можно сравнить с командой производственного обеспечения, которую вызывают ночью, потому что произошла авария. Команда разработки, как и команда производственного обеспечения, может принимать решения и устранять/оценивать поступающие проблемы. Под самоорганизацией понимается не пренебрежение к организации, а предоставление права решать рабочую проблему тем людям, которые непосредственно занимаются этой работой.
В обязанности команды разработчиков входит следующее.
Владелец продукта: установка четкого направления
Agile-команды по определению являются гибкими и быстро реагируют на изменения, а владелец продукта несет ответственность за обеспечение максимальной ценности. Владелец продукта представляет бизнес и говорит разработчикам, чего требуется достичь. Доверие между этими двумя ролями имеет принципиальное значение.
Владелец продукта должен не только понимать клиента, но и иметь концепцию ценности, которую Scrum-команда поставляет клиенту. Кроме того, владелец продукта определяет баланс между потребностями других заинтересованных сторон в организации.
Таким образом, владелец продукта должен учесть все эти входные данные и расставить приоритеты в работе. Пожалуй, это его самая значимая обязанность, поскольку противоречивые приоритеты и расплывчатые установки не только снижают эффективность команды, но и могут нарушить важные доверительные отношения между бизнесом и командой разработчиков.
Команды, следующие принципам agile, по своей сути предусматривают анализ и адаптацию. Это означает, что изменение приоритета может привести к серьезным изменениям в структуре команды, рабочих продуктах и конечном результате. Именно поэтому для успешной работы Scrum-команд крайне важно, чтобы определением приоритетов занимался только один человек. Это владелец продукта.
В руководстве по Scrum выделяют следующие обязанности владельца продукта.
Scrum-мастер: объединение всех элементов вместе
Scrum-мастер — это роль, которая объединяет все элементы и обеспечивает эффективную реализацию методики Scrum. На практике это означает, что такой сотрудник помогает владельцу продукта определять ценность, команде разработчиков — поставлять ценность, а Scrum-команде — становиться лучше. Scrum-мастер — это лидер-слуга, который не только формирует лояльный стиль руководства, но и ежедневно его практикует.
Он помогает владельцу продукта лучше понимать и выражать ценность, управлять бэклогом, планировать работу с командой и разбивать эту работу для наиболее эффективного обучения. Команде разработчиков Scrum-мастер помогает с самоорганизацией, настраивает участников на достижение конечного результата и выполнение инкрементов, а также вместе с ними управляет блокерами. Кроме того, Scrum-мастер служит организации в целом, помогая ей понять суть методики Scrum и создать для нее благоприятную среду.
Scrum-мастер фокусируется на следующем.
Scrum-мастер помогает владельцу продукта при планировании спринта и обзоре его итогов, чтобы в коллективе сохранялось четкое понимание ценности и направления. Он помогает команде разработчиков в повседневной работе по методике Scrum, следя за выполнением работы и устранением блокеров. Он также отвечает за работу с блокерами, которые команда не может устранить самостоятельно. Scrum-мастер следит за тем, чтобы Scrum-команда видела все возможности для развития, а ретроспектива давала набор четко сформулированных достижимых результатов.
Начало работы с гибкими scrum-ролями
На первый взгляд три основные области ответственности ролей Scrum довольно просто интерпретировать в любой Scrum-команде, но нередко бывает сложно сопоставить их со своей должностью. Вот с чего можно начать.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?