Что не является артефактом scrum
Роли, процессы и артефакты в Scrum: дьявол в деталях
15 Ноя 2019
Это шестая статья из серии «Введение в Agile». В ней мы расскажем о ролях и артефактах Скрам, а также о практиках, которые дополняют Скрам.
До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile, а также познакомились с основами Scrum:
Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании, в которой он тогда работал. Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.
Роли в Скрам
В Скрам выделяют три роли: Владелец продукта, Скрам-мастер и Команда разработки. Все вместе они составляют Скрам-команду.
Владелец продукта – это представитель пользователя, который в то же время заинтересован в рациональном использовании ресурсов команды. Владелец продукта должен четко представлять себе портрет финального заказчика, его потребности, предпочтения по продукту и цели, для которых разрабатывается продукт. Владелец продукта должен иметь достаточно компетенций и полномочий, чтобы принимать решения по продукту от имени заказчика.
Владелец продукта должен обладать стратегическим мышлением, ведь он отвечает не только за создание продукта, но и за поддержку его в будущем, на следующих этапах жизненного цикла продукта. Вместе с тем Владелец продукта должен быть готов тесно работать с командой, формулируя видение продукта, требования к функционалу, принимая или отвергая рабочие результаты.
Поскольку Владелец продукта отвечает за успех своего продукта, он занимает роль лидера в команде, в то же время тесно сотрудничая с другими участниками и не имея формальной власти над ними. Роман Пихлер в книге «Управление продуктом в Scrum. Agile методы для вашего бизнеса» описывает Владельца продукта как «первого среди равных» в команде.
Усилия Владельца продукта направлены не только внутрь команды, но и на окружение проекта. Ему необходимо общаться с разными заинтересованными сторонами, включая заказчиков, пользователей, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство. При этом важно, чтобы Владелец продукта не выступал «передаточным звеном» между заказчиком и командой, а мог самостоятельно защищать продукт и принимать по нему решения. Для этого ему нужно быть достаточно квалифицированным в предметной области проекта (разработка ПО, создание банковских продуктов или верстка веб-страницы).
Скрам-мастер – это эксперт в области Agile-практик, который помогает Команде разработки выстроить правильные процессы. На начальных этапах Скрам-мастер проводит встречи (Планирование спринта, Ежедневные летучки, Обзор спринта, Ретроспективу), поддерживает в актуальном состоянии артефакты процесса, защищает команду от внешних вмешательств: срочных поручений, не относящихся к разрабатываемому продукту, попыток изменить требования в ходе спринта и т.п.
Скрам-мастер оказывает поддержку Владельцу продукта и команде, защищает ее и процесс работы и при необходимости вмешивается, чтобы проверить, справляется ли команда с задачей, сохраняет ли здоровую атмосферу и мотивацию.
Роли Владельца продукта и Scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание ценного продукта. Scrum-мастер следит за правильным применением практик Scrum. Совмещение этих ролей создает чрезмерную нагрузку и смещение фокуса внимания, поэтому нельзя одновременно быть Владельцем продукта и Scrum-мастером.
Команда разработки – это те самые мотивированные профессионалы, которые заведомо мотивированы на создание результата. В Команде разработки должно быть не более 9 человек, все участники взаимозаменяемы, то есть могут помочь друг другу в выполнении задач. Кросс-функциональность позволяет Команде нести коллективную ответственность за результат.
Для того, чтобы создать успешную команду, необходимо минимизировать изменения в ее составе. По принципам командной динамики людям необходимо время, чтобы привыкнуть друг к другу, сработаться и выйти на оптимальный уровень производительности. Любой новый участник запустит этот процесс заново.
Артефакты в Скрам
Бэклог продукта – это список всех элементов продукта, требований к ним и любой связанной с продуктом информации. Бэклог продукта формируется на всем протяжении проекта (может дополняться, детализироваться или сокращаться). Хорошая практика – привлечение всей Команды к корректировке Бэклога продукта, несмотря на то, что в основном за ведение Бэклога продукта отвечает Владелец продукта.
Бэклог продукта есть практически в любом 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 вы можете почувствовать себя в роли участника Скрам-команды: спланируете спринт, оцените влияние непредвиденных ситуаций на рабочий процесс, проведете ретроспективу, оцените объем завершенной за спринт работы по сравнению с планом и научитесь учитывать эти результаты при планировании следующего спринта.
Скрам — Артефакты
Скрам-артефакты предоставляют ключевую информацию, которую необходимо знать команде Scrum и заинтересованным сторонам для понимания разрабатываемого продукта, выполненных работ и планируемых мероприятий в проекте. Следующие артефакты определены в Scrum Process Framework —
Это минимально необходимые артефакты в проекте Scrum, и артефакты проекта этим не ограничиваются.
Резерв продукта
Журнал ожидания продукта — это упорядоченный список функций, которые необходимы как часть конечного продукта, и он является единственным источником требований для любых изменений, вносимых в продукт.
Журнал ожидания продукта содержит список всех функций, функций, требований, улучшений и исправлений, которые представляют собой изменения, которые будут внесены в продукт в будущих выпусках. Элементы журнала незавершенного производства имеют атрибуты описания, заказа, оценки и стоимости. Эти элементы обычно называются пользовательскими историями. Владелец продукта несет ответственность за Журнал незавершенного производства, включая его содержание, доступность и порядок заказа.
Отставание продукта — это развивающийся артефакт. Самая ранняя версия может содержать только изначально известные и наиболее понятные требования. Журнал ожидания продукта разрабатывается как продукт, и среда, в которой он будет использоваться, прогрессирует. Журнал ожидания продукта постоянно изменяется, чтобы включить то, что требуется, чтобы сделать его эффективным. Пока продукт существует, его бэклог продукта также существует.
По мере того, как создаваемый продукт используется и приобретает все большую ценность, бэклог продукта становится все более обширным и исчерпывающим списком. Изменения в бизнес-требованиях, рыночных условиях или технологиях приводят к изменениям в Журнал ожидания продукта, превращая его в живой артефакт.
Уточнение журнала невыполненных работ означает добавление деталей, оценок и порядка приоритетов к элементам журнала невыполненных работ. Это постоянный процесс, выполняемый Владельцем продукта и Командой. Скрам-команда решает, как и когда нужно проводить доработку.
Элементы Журнала Продукта могут быть обновлены в любое время Владельцем Продукта или по усмотрению Владельца Продукта.
Предметы с более высоким уровнем упорядоченности продуктов, как правило, более четкие и подробные, чем элементы с низким порядком. Более точные оценки сделаны на основе большей ясности и повышенной детализации. Чем ниже порядок, тем меньше детали.
Элементы Журнала незавершенного производства, которые, вероятно, могут соответствовать требованиям кандидата для будущего Спринта, уточняются, чтобы эти элементы могли быть разработаны во время Спринта. Элементы Журнала работы продукта, которые могут быть разработаны Группой в рамках одного Спринта, считаются готовыми для выбора на совещании по планированию Спринта.
Журнал Спринта
Журнал ожидания для Sprint — это набор элементов Журнала работы с продуктом, выбранных для Sprint, а также план для увеличения продукта и реализации цели Sprint.
Журнал ожидания от Sprint — это прогноз Группы о том, какие функциональные возможности будут доступны в следующем Инкременте, и о работе, необходимой для предоставления этой функциональности в качестве инкремента рабочего продукта.
Журнал ожидания спринта — это план с достаточным количеством деталей, которые можно понять, но команда должна отслеживать «Ежедневные схватки». Команда изменяет Журнал Спринта во всем Спринте, а Журнал Спринта появляется во время Спринта. Это происходит, когда команда прорабатывает план и узнает больше о работе, необходимой для достижения цели спринта.
Поскольку новая работа требуется, Команда добавляет ее в Журнал ожидания Спринта. По мере того, как работа выполнена или завершена, предполагаемая оставшаяся работа обновляется Когда элементы плана считаются ненужными, они удаляются. Только Команда может изменить свой Журнал Спринта во время Спринта. Журнал ожидания Спринта — это хорошо видимая в реальном времени картина работы, которую Команда планирует выполнить во время Спринта, и она принадлежит исключительно Команде.
инкремент
Прирост — это сумма всех элементов Журнала Продуктов, выполненных во время Спринта, вместе с приращениями всех предыдущих Спринтов. В конце Спринта новый Инкремент должен быть рабочим продуктом, что означает, что он должен быть в пригодном для использования состоянии. Он должен быть в рабочем состоянии независимо от того, решит ли Владелец продукта его фактическую версию.
Команде Скрам необходимо достичь консенсуса в отношении того, что считается Приращением. Это значительно варьируется в зависимости от Скрам Команды, но члены команды должны иметь общее понимание того, что это значит для завершения работы. Это используется для оценки завершения работы над приращением продукта.
То же самое понимание помогает Группе узнать, сколько элементов Бэклога продукта она может выбрать во время Планирования Спринта. Целью каждого Sprint является предоставление Приращений потенциально высвобождаемой функциональности.
Команды обеспечивают увеличение функциональности продукта в каждом спринте. Этот прирост можно использовать, поэтому владелец продукта может немедленно выпустить его. Если понимание приращения является частью соглашений, стандартов или руководящих указаний организации-разработчика, все Скрам-команды должны следовать ему как минимум. Если это не соглашение организации-разработчика, команда Scrum должна определить определение приращения, подходящее для продукта.
Каждый Инкремент аддитивен ко всем предыдущим Инкрементам и тщательно протестирован, обеспечивая совместную работу всех Инкрементов.
По мере взросления Скрам-команд ожидается, что их определения Приращений будут расширены и будут включать более строгие критерии более высокого качества. Любой продукт должен иметь определение приращения, которое является стандартом для любой работы над ним.
Диаграмма выжигания спринта
В любой момент времени в Спринте общая работа, оставшаяся в Журнале Спринта, может суммироваться. Команда отслеживает эту общую работу, оставшуюся для каждой ежедневной схватки, чтобы спрогнозировать вероятность достижения цели спринта. Отслеживая оставшуюся работу по всему Спринту, Команда может управлять ее ходом.
Спринт Burn-Down Chart — это практика для отслеживания работы, затраченной Scrum Team. Было доказано, что это полезный метод для отслеживания прогресса Спринта в достижении Цели Спринта.
Владелец продукта отслеживает эту общую работу, оставаясь, по крайней мере, в каждом обзоре Sprint. Владелец продукта сравнивает эту сумму с работой, оставшейся в предыдущих Обзорах Спринта, чтобы оценить прогресс в выполнении запланированной работы к требуемому времени для достижения цели. Эта информация передается всем заинтересованным сторонам.
Заключение
Роли, события, артефакты и правила Скрама неизбежны. Если реализованы только некоторые части Scrum, результат не Scrum. Скрам должен быть реализован полностью и хорошо функционировать, если он согласован с другими методами, методологиями и практиками.
Scrum Guide © 1991-2013 Кен Швабер и Джефф Сазерленд, Все права защищены.
Что не является артефактом scrum
Итак, мы помним что такое Epic, User Story и Task. Это общие артефакты которые используются вне зависимости от используемого фреймворка.
В Скраме же, помимо общих, есть три дополнительных артефакта.
Артефакты Скрам (SCRUM Artifacts)
Еще одним элементом, который следует знать до того как мы продолжим, является Спринт (Sprint). Спринт – это некий временной отрезок, длительность которого определяется командой в самом начале. В течение всей разработки проекта длительность Спринта обычно не меняется, позволяя команде выработать удобный ей рабочий темп. Говоря проще, Спринт, это название для итерации в Скраме.
В классическом Скраме длительность Спринта ограничивается двумя календарными неделями (десять рабочих дней).
В данном случае у нас есть некое множество задач в Product Backlog-е. Для следующей итерации мы выбрали только три и переместили их в Sprint Backlog. Выполнение каждой из задач в Sprint Backlog-е даст нам инкремент, который мы сможем показать заказчику и работу которого он сможет оценить. Любые новые задачи, идеи, пожелания пользователей и все что мы хотим держать в нашем фокусе будет попадать в Product Backlog.
Итак, мы начали внедрение SCRUM. Мы создали соответствующее рабочее пространство, создали Product Backlog и закинули туда все задачи нужные для понятного нам проекта. Затем мы подготовили Sprint Backlog, выбрали задачи на следующую итерацию (спринт) и поняли что такое инкремент.
Ритуалы Скрам (SCRUM Rituals)
Ритуалами называются те действия, которые используемый фреймворк крайне рекомендует внедрять для высвобождения всего его потенциала. В Скраме используются следующие ритуалы:
Scrum-методология
Во многих бизнес-школах по всему миру сегодня преподаётся Scrum-методология. Рассказываем, в чём она заключается, что собой представляет, как внедряется и, самое главное, чем помогает собственнику бизнеса или руководителю.
Scrum: определение понятия и краткая история
Понятие «scrum» пришло из регби. Термин переводится с английского языка как «схватка» и описывает поведение команд перед вбросом мяча (когда после остановки игры или нарушения соперники обхватывают друг друга руками, создавая три линии игроков, пытающихся вывести мяч из схватки).
Применительно же к бизнесу, Scrum — это гибкий метод управления проектами, в рамках которого создаётся команда специалистов с распределёнными ролями, работающая на общий результат. Такой подход к работе упомянули ещё в 1986 г. японские учёные Х. Такэути и И. Нонака. А в начале 1990-хх гг. Скрам использовал разработчик программного обеспечения из США Кен Швабер. Убедившись в его эффективности, он впоследствии описал его вместе с Джеффом Сазерлендом. Со временем Scrum начал применяться не только в разработке IT-продуктов, но также в бизнесе.
Концепция Scrum-методологии: принципы, ценности
Здесь надо сказать, что технология Scrum является частью концепции Agile, принципы которой сформировали в начале 2001 г. в США. Согласно Agile:
Благодаря этим принципам гибкие методы управления проектами, к которым относится и Скрам, позволяют добиваться лучших результатов, тратя на работу минимум времени.
Основные принципы Scrum:
Структура Scrum
Скрам — это фреймворк, в котором выделяются роли, практики, артефакты. В них надо разобраться, чтобы понять, как строится работа по Scrum.
В команде три роли.
Важно, чтобы люди были самостоятельны, могли автономно работать и нести ответственность за результат, а не согласовывали каждое действие с кем-то извне. Только тогда работа будет продуктивной и эффективной.
Практики
Основой методики Scrum является Sprint — период времени, занимающий от 1 до 4 недель, за который команда работает над продуктом. Важно, что по завершении спринта она должна представить рабочую версию продукта, а не завершённый этап, и это существенно отличает этот метод от других методов управления проектами. Подготовка к первому спринту осуществляется на основании плана проекта и требований к нему. Затем спринт планируется, формируется журнал спринта (определяются задачи, которые позволят удовлетворить требования) и начинается работа.
Артефакты
Артефактами называются документы в Scrum:
Детальнее структура работы описана в книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами».
Этапы планирования в Scrum
Изначально надо составить список факторов, влияющих на результат, расставив их по приоритетности. Таким образом, если времени на реализацию задач не будет хватать, команда сократит список.
Затем следует проанализировать каждый пункт, чтобы оценить важность тех или иных задач. Интересно, что автор предлагает действенные методики анализа. Например, использование шкалы оценок, где задачи сравнивают в «собаках» (такса – 1, дог – 13), или покер планирования. В рамках последней каждый участник вытягивает карту из колоды и показывает свою оценку. Если она не совпадает с оценками других участников, её аргументируют.
Командная работа в Scrum
Суть методологии Scrum заключается в слаженной командной работе. Формируется команда из людей с нужными для выполнения определённых задач знаниями и навыками. При этом у каждого участника есть своя область ответственности, но, если нужно и время позволяет, специалисты могут помогать друг другу.
Scrum применителен и для удалённых команд. Правда, им придётся использовать специально разработанные под эту методологию программные продукты.
Когда применять Scrum
Изначально методология была разработана для IT-сферы, но со временем её стали внедрять и в других областях: в бизнесе, маркетинге. Надо отметить и то, что основное преимущество Scrum в возможности эффективно организовать работу там, где есть сложности, неопределённости, быстро меняющиеся условия, и добиться нужного результата.
Таким образом, Scrum незаменим при разработке инновационных, принципиально новых продуктов.
Преимущества и недостатки методологии Scrum
Как и любой подход, Scrum имеет свои плюсы и минусы.
Почему работа по Scrum может быть неэффективной
В Scrum есть чёткие правила работы, требования, которым нужно следовать, чтобы добиться результата. Соответственно, если их игнорировать, он может оказаться не таким, как ожидалось. Кроме того, одно из ключевых отличий Scrum от других методологий Agile, например, Kanban, в его сложности в организации и реализации. С другой стороны, эти две методологии можно успешно совместить. О том, как это сделать, читайте в книге Х. Книберга и М. Скарина «Kanban и Scrum: выжимаем максимум».
Надо также сказать, что основа методологии Скрам в тесном взаимодействии участников. И, если по каким-то причинам организовать его не удаётся, команды терпят неудачи.
Как внедрить методологию
Д. Сазерленд рекомендует осуществлять внедрение Scrum поэтапно:
Важно при этом ежедневно обсуждать первые спринты, выбирая приоритетные требования, чтобы впоследствии не пришлось выполнять ненужных действий.
Выводы о Scrum
Scrum — это методология, которая позволяет организовывать эффективную работу и завершать её в срок, представляя каждый раз заказчику готовый работоспособный продукт. Технология удобна, поскольку достаточно гибка: в ходе работы можно менять функциональность продукта, адаптируя его под изменяющиеся условия. С другой стороны, в этом заключается сложность при работе со Scrum, так как из-за этого тяжело рассчитать бюджет. Однако это не мешает владельцам компаний в сфере IT, а также тем, кто производит инновационные продукты, успешно использовать методологию в своей работе.