Хабрахабр

[Из песочницы] Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по Scrum, созданные в результате прочтения книги Сазерленда и статей из интернета.

Agile – это методология (наука), а Scrum – это метод достижения цели. Надо различать Agile и Scrum.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

Состояние счастья приводит людей к превосходным результатам. Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе.

А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. Счастливые люди успешнее на 50%. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

  • определение элементов бэклога продукта;
  • правильное расположение элементов для оптимизации достижения цели;
  • обеспечение понятности и прозрачности Product Backlog;
  • обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
  • общая оптимизация для достижения наибольшей ценности работы Development Team;
  • ответственность за понимание бэклога командой разработки.

Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Размер команды составляет от 5 до 9 человек (5 оптимально). Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Это как некий единый организм, состоящий из отдельных элементов.

Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review). Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду.

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика. Epic (эпик) – одна из нескольких глобальных функций продукта.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Оптимальная продолжительность спринта – 1-2 недели. Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Выбираются задания из Бэклога, которые возможно выполнить за спринт. Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team.

Можно использовать мобильные приложения для Scrum Poker. Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. Story Points (стори поинтc) – единица оценки сложности выполнения задачи. На проекте из одного-двух спринтов использовать 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 (бёрнап чарт) – диаграмма сгорания задач. Первому дню спринта соответствует максимальное кол-во Story Points. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points.

Направление графика снизу вверх. Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Последнему дню спринта соответствует максимальное кол-во Story Points. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points.

Остановку инициирует Product Owner. Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Затем Спринт запускается вновь. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

  1. Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
  2. Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач. Тогда можно изменить «важность» всех задач с этой тематикой;
  3. Задачи лучше разбивать по одинаковым типам.

image

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

  1. Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
  2. Формулировка User Story:
    Будучи пользователем <…> я хочу сделать <…>, чтобы получить <…>.
    Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение;
    Формулировка без ЧТОБЫ (так лучше).
    Как <пользователь>, я <что-то хочу получить>, <с такой-то целью>.
    Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ.
  3. Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
  4. Написание истории с точки зрения этих актеров с указанием уникальных названий;
  5. В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
  6. Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
  7. Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
  8. Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
  9. User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.

Уточнение и оценка Product Backlog

Команда должна оценить каждую задачу: выполнима ли она в принципе? Происходит совместно с Development team. достаточно ли информации для выполнения?

Sprint Planning Meeting. Формируется Sprint. Scrum Poker

Для 2-x недельного спринта митинг длится 2 часа. Продолжительность митинга не более 8 часов. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

  1. Первая часть митинга могут участвовать все.
    Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;
    Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения.
  2. Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
    Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;

Scrum Poker (Planning Poker).

Задачи 13 и более поинтов необходимо дробить на более мелкие. Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице: Срок выполнения задачи одним разработчиком не более одного дня или 8 часов.

image

  1. Scrum Master ведет собрание;
  2. Product Owner представляет краткие обзоры каждой задачи;
  3. Происходит обсуждение, задаются вопросы;
  4. Участники Developer Team выбирают по одной карте, потом переворачивают;
  5. Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
  6. Затем голосуют вновь и присваивают задаче Story Points.

Daily Scrum Meeting

Все могут наблюдать. Проводится каждый день. Проводит Scrum Master. Говорит только Scrum Team.

  1. Проводится в одно и то же время;
  2. Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
  3. Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?

Sprint Review Meeting

Знаменуется значительным приростом функционала продукта. Участвуют все. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Ретроспектива. Sprint Retrospective Meeting.

Проводится в последний день спринта.

Задаются вопросы: что можно улучшить? Призвана оценить результат команды. как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. как? Счастливые люди = высокая производительность команды. Кайдзен – непрерывное совершенствование.

Что сделает вас счастливее вообще? Можно задать вопросы: Что может сделать вас счастливее в следующем спринте?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть