keepsimple
dark
en | ru

#6. SCRUM Фреймворк – артефакты, ритуалы и роли

Итак, мы помним что такое Epic, User Story и Task. Это общие артефакты которые используются вне зависимости от используемого фреймворка.

В Скраме же, помимо общих, есть три дополнительных артефакта.

Артефакты Скрам (SCRUM Artifacts)

  • Бэклог Продукта (Product Backlog, также называется общим бэклогом, глобальным бэклогом, или просто бэклогом). По сути он представлят из себя то самое место, куда мы закидываем все Эпики и Пользовательские Истории, которые необходимо выполнить для завершения проекта.
  • Бэклог Спринта (Sprint Backlog), или Спринт Бэклог, это то место, куда мы перетаскиваем задачи, необходимые для выполнения в следующей итерации.
  • Инкремент Продукта (Product Increment), или просто Инкремент – это то, что мы собираемся получить по окончанию итерации. В идеале, это рабочий кусок программы, который можно показать заказчику и получить комментарии от заказчика.
  • Что считается «завершенным» (Definition of Done, или DoD) – еще один артефакт, который часто используется в разных фреймворках. Суть DoD в том, чтобы до начала непосредственной разработки проекта заключить договоренность между всеми участниками проекта на предмет того, что мы считаем завершенным. К примеру, мы можем договориться, что задача (не важно, epic, user story или task) считается завершенной только тогда, когда она функционирует в точности с тем, как указанно в документации. Либо мы можем определить, что задача считается завершенной если тестировщик проверил ее и перенес в колонку завершенных задач (напр.”Done”). Опять же, не смотря на то, что ответ может показаться очевидным, по факту, в каждом отдельном случае следует учитывать специфику и цели проекта, и составлять DoD в соответствии с ними. Так, если у нас эксперементальный проект, который мы и сами не знаем как будет выглядеть в конце, очевидно, что для него DoD будет более «щадящим», и критерии «принятия» задачи будут абстрактнее, с минимальными требованиями.

Еще одним элементом, который следует знать до того как мы продолжим, является Спринт (Sprint). Спринт – это некий временной отрезок, длительность которого определяется командой в самом начале. В течение всей разработки проекта длительность Спринта обычно не меняется, позволяя команде выработать удобный ей рабочий темп. Говоря проще, Спринт, это название для Итерации в Скраме.

В классическом Скраме длительность Спринта ограничивается двумя календарными неделями (десять рабочих дней).

Пример:

В данном случае у нас есть некое множество задач в Product Backlog-е. Для следующей итерации мы выбрали только три и переместили их в Sprint Backlog. Выполнение каждой из задач в Sprint Backlog-е даст нам инкремент, который мы сможем показать заказчику и работу которого он сможет оценить. Любые новые задачи, идеи, пожелания пользователей и все что мы хотим держать в нашем фокусе будет попадать в Product Backlog.

Итак, мы начали внедрение SCRUM. Создали соответствующее рабочее пространство, закинули все задачи нужные для уже известного и понятного нам проекта в Product Backlog, подготовили Sprint Backlog для выбора задач на следующую итерацию (спринт) и поняли что такое инкремент.

Ритуалы Скрам (SCRUM Rituals)

Ритуалами называются те действия, которые используемый фреймворк крайне рекомендует внедрять для высвобождения всего его потенциала. В Скраме используются следующие ритуалы:

  • Планирование Спринта (Sprint Planning meeting)
    Это встреча на которой команда определяет, что попадет на разработку в следующую итерацию.
  • Ежедневный Скрам (Daily Scrum meeting, или Standup meeting)
    Встреча происходящая каждый день (обычно, самая первая встреча рабочего дня), на которой каждый участник команды отвечает на три простых вопроса: что он сделал вчера; что он будет делать сегодня; есть ли какие-то сложности которые тормозят его работу. Обычно команда проводит эти встречи стоя, за что эти встречи также называют «Standup meeting»-ами. Все участники собираются лицом к лицу и отвечают на вопросы обращаясь к команде, а не к кому-то конкретному, так, чтобы у всех было понимание кто чем был занят. На практике, иногда эти встречи превращаются в обсуждение задач, где коллеги стремятся друг другу активно помочь, поэтому ответственному за проведение встречи (проект менеджер, или кто-то другой, назначенный на роль фасилитатора) следует пресекать долгие дискуссии. В идеале эта встреча длится не более 15 минут. В идеале ☺
  • Обзор Спринта / Демо (Sprint Review / Demo)
    На этой встрече команда показывает результаты своей работы заказчику, или ответственному за принятие работы. Обычно, Демо назначается на последний день Спринта (обычно, на последний рабочий день недели). По результатам Демо, команда может решить что-то изменить или добавить, создав соответствующие задачи и закинув их в Бэклог Продукта.
  • Ретроспективный Анализ Спринта (Sprint Retrospective)
    Эта встреча назначается в конце Спринта, обычно после Демо. На ней команда обсуждает что в течение спринта прошло хорошо, а что можно улучшить. Идея в том, чтобы создать прозрачные условия, где все участники будут открыто обсуждать сложности, чтобы путем постоянных дискуссий добиться максимальной оптимиазции деятельности команды и, как результат, постоянно улучшать производительность команды (В соответствии с принципами Agile <3).
  • Оценка размера Пользовательских Историй (User Story Sizing)
    Необязательный, но рекомендуемый ритуал. Существует множество подходов к оценке «размера» историй, которые нужны, по сути, чтобы иметь возможность прогнозировать примерный объем работы, которая может быть выполнена командой за одну итерацию. Мы разберем наиболее популярный оценочный метод в следующей статье, поэтому оставим этот пункт без деталей.

Теперь мы знаем Артефакты и Ритуалы Скрама, что позволяет нам понять в какой рабочей среде мы будем работать, какими понятиями оперировать и какие встречи с участниками команды проводить.

Давайте же пройдем по ролям участников проекта, и наконец-то соберем целую картину участников нашего проекта.

Роли участников проекта (Project Team Roles)

  • Заинтересованная Сторона (Stakeholder. Стейкхолдер, иногда называют Спонсором, иногда Клиентом, однако понятие Stakeholder наиболее четко описывает эту роль). По сути, это уполномоченное заказчиком лицо (или сам заказчик), имеющее полномочия для принятия каких-либо решений либо предоставления какой-то специфической информации, необходимой для реализации проекта. Например, если мы пишем программу для крупной юридической конторы, Стейкхолдерами выступают все лица со стороны заказчика, с которыми мы собираемся контактировать в рамках проекта. Так, кто-то может быть уполномочен снабжать нас юридической информацией, которую нам следует учитывать в разработке, а кто-то может запрашивать у нас отчеты по прогрессу проекта каждые n-недели.
  • Бизнес Аналитик (Business Analyst, BA). Ответственен за понимание идей Стейкхолдеров, создания реального продукта (на бумаге). Помимо этого, одной из его важнейших обязанностей является обеспечение коммуникации между Стейкхолдерами и Командой, разрабатывающей продукт. Идеальный кандидат на эту роль должен хорошо разбираться в бизнесе в целом, и в сфере бизнеса Стейкхолдеров в частности. Помимо этого, BA должен понимать (понимать, а не владеть!) технические особенности разработки ПО, так, чтобы во время сбора требований от заказчика направлять его, объясняя что желательно, а что нет. После фактического сбора информации, BA переводит все требования в виде Эпиков или Пользовательских Историй, которые уже, как мы знаем, попадают в Бэклог Продукта. По мере появления вопросов у разработчиков, BA либо старается ответить на них сам, либо, компонует вопросы таким образом, чтобы Стейкхолдер, будучи не техническим специалистов, мог понять что интересует команду. Упростим: Бизнес Аналитик это мост между Клиентом и Командой, знающий Бизнес и Технологии (Звучит грубо, но суть отражает).
  • Менеджер Продукта (Product Manager). Чаще всего является участником команды Заказчика. Ответственен за стратегию выведения продукта на рынок, релизами продукта, разработки новых идей и функций продукта. Он же ответственен за определение дат запуска, организацию тренингов своей команды (если программа разрабатывалась для внутреннего использования в компании заказчика), а также за расчет затрат (и прибыли, если таковая подразумевается продуктом). Часто Менеджера Продукта путают с Бизнес Аналитиком. Ключевое отличие между ними в том, что главной функцией Менеджера Продукта является поддержка не технических команд (например департамент продаж, маркетинга, юридический отдел, бухгалтерия и так далее). BA в свою очередь напрямую работает с техническими командами (дизайнеры, разработчики, тестировщики).
  • Менеджер Проекта (Project Manager, PM). Работает в штате компании-разработчика. Контролирует бюджет, доставку продукта, ресурсы и объем работ. Помимо этого следит за статусом работ и генерирует соответствующие отчеты. Еще одной постоянной обязанностью PM-а является решение проблем команды. При этом под проблемами мы имеем ввиду действительно все, что может быть. Идеальный кандидат на эту роль должен быть фанатиком зацикленным на том, чтобы команде было действительно хорошо работать. На западе даже придумали замысловатое название для такого стиля работы: ”Servant Leadership”, наверное, ближе всего это можно перевести как «Услужливое Лидерство». Забавно, никогда не думал как это будет выглядеть на русском. Ну так вот, собственно, идея в том, чтобы PM служил команде, помогая ей всеми силами, отложив в сторону свое эго, пафос и понты.

Касательно PM-а, справедливости ради нам следует знать еще и то, что во многих компаниях он также выполняет функции Бизнес Аналитика. То есть, он, помимо своих PM-обязанностей еще и обеспечивает связь между своей командой и Заказчиком. Такое бывает в небольших компаниях, а небольших компаний занимающихся разработкой ПО очень, очень много.

  • Руководитель Команды, он же Teamlead, Тимлид или просто Lead/Лид. Является техническим куратором проекта. Обычно именно он определяет технологический стэк, который будет использоваться в проекте (Tech. Stack). Он же распределяет задачи между другими тех. специалистами проекта (Разработчики, тестировщики, иногда дизайнеры).

Тимлид следит за сроками исполнения задач, вмешивается в работу младших участников когда это необходимо и запрашивает дополнительные ресурсы у PM—а, тесно с ним работая. По сути PM и Тимлид являются теми, кто видит курс проекта как в краткосрочной, так и долгосрочной перспективе. Плодом их кооперации являются отчеты и запросы вышестоящему руководству.

Ввиду того, что Тимлид работает с командой теснее, чем PM, именно в его обязанности в первую очередь входит контроль за взаимодействием и атмосферой между участниками команды. Все встречи с Заказчиком, где необходима техническая поддержка также проводятся при участии Тимлида.

  • Команда разработчиков, они же, программисты, они же, ребята пьющие тонны кофе. По сути являются фактическими разработчиками проекта. Чаще всего имеют три профессиональных уровня (от малого к большему) : Junior / Mid / Senior, каждый из которых определяется индивидуально для каждой компании.
  • Команда тестировщиков. В идеале, разделена на три уровня:
    • Тестировщик (Tester) - ответственные за исполнение Тест-Кейсов (документ, описывающий шаги необходимые для проведения тестирования каждого Инкремента);
    • Контроль Качества (Quality Control, QC) – те, кто пишут Тест-Кейсы и ведет логгирование деятельности тестировщиков;
    • Гаранты Качества (Quality Assurance, QA) – те, кто определяет методы и архитектуру того, как проводится тестирование ПО, а также занимается интеграцией инноваций в подходы к тестированию.
    • В реальности, подобное разветвление встречается только у действительно огромных компаний. Малые компании называют тестировщиков просто QA, с приставками Junior, Mid или Senior, в зависимости от опыта и навыков кандидата.
  • Технический Писатель (Technical Writer) – лицо, ответственное за разработку тех. документации как для внутреннего, так и внешнего использования. Привлекается только в крупные проекты, где документация является действительно очень важным пунктом контракта.

Помимо этих ролей, Скрам имеет три роли, свойственные только ему.

Скрам Роли (SCRUM Roles)

  • Владелец Продукта (Product Owner, PO), в обязанности которого входит приоритизация эпиков и историй. В командах практикующих Скрам, именно PO определяет что из Бэклога Продукта попадет в Бэклог Спринта.
  • Скрам Мастер (Scrum Master, SM), в обязанности которого входит слежение за исполнением всех Скрам ритуалов, наблюдение за атмосферой царящей в команде, слежение за исполнением ключевых принципов Agile (соответствие четырем пунткам Манифеста Agile). SM, это своего рода командный психолог (а это забавнее, чем я думал ☺)). Но, если серъезно, SM привлекают к серъезным проектам, с целью минимизации любых рисков связанных с понижением продуктивности комманды из-за проблем во внутренней коммуникации между участниками. Важность SM-а возрастает в многонациональных командах, где следует учитывать множество культурных особенностей участников.
  • Тренер (Agile Coach / SCRUM Coach). Привлекается с целью разработки методов плавной интеграции Agile философии и SCRUM фреймворка в компании/команде/проекте, с учетом нюансов психологической составляющей участников, их индивидуальных личностных особенностей и так далее. Эдакий психолог-добродетель ☺)))). На самом деле роль была создана на Западе с целью снять обязанности по интеграции фреймворка с рядовых менеджеров.

Ниже я выписал 5 ключевых ценностей Скрама, которые Эндрю Стеллман написал в своей книге «Постигая Agile». Я сохранил их у себя в заметках когда-то давно, потому что на фоне всего информационного шума в вэбе, эти заметки очень простые, легкие для понимания, но при этом крайне полезные.

5 Ключевых ценностей Скрам (из книги Эндрю Стеллмана «Постигая Agile»)

1. Каждый человек ответственен за цели проекта.

  • Каждый участник может высказать свое мнение о планировании и выполнении проекта.
  • Необходимо полностью избежать лишней бюрократии для облегчения качественного взаимодействия между всеми членами команды.
    (Каждый член команды разделяет ответственность за бэклог...включая все функции, а не только те, над которыми работает лично он)

2. Члены команды уважают друг друга.

  • Никто не сомневается, что другой постарается выполнить свою работу максимально хорошо.
  • Следует объяснить роль каждого члена команды, чтобы все поняли его важность и значимость.
    (Любая, даже не гибкая команда может стать высокопроизводительной, если введет правила, запрещающие своим старшим членам передавать "скучные" задачи младшим по должности)

3. Все сосредоточены на работе.

  • Внимание команды не рассеяно.
  • Многозадачность необходимо избегать, так как она отвлекает.

4. Команды ценят открытость. 

  • Предоставить достаточно механизмов, для полной прозрачности в команде и проекте.

5. Члены команды имеют мужество отстаивать проект.

  • Сплочение команды вокруг Идеи.
  • Идеологическая обработка. Объяснение важности Миссии.
    (Если вы копаете канавы, это вас не очень возвышает и вдохновляет. Но если вы копаете канавы, чтобы защитить свой город от врага, то это вдохновляет гораздо сиьлнее, хотя вы делаете то же самое. Поэтому, задача лидера (менеджера) - предоставить работу таким образом, чтобы люди могли понять в чем ее ценность, ибо высокая ценность не оставит никого равнодушным).

Итог

Посмотрим, что мы узнали.

Мы узнали артефакты, ритуалы и роли Скрам, а также роли всех участников проекта и их обязанности в целом. Теперь, когда мы знаем что такое Скрам фреймворк, мы можем оглянуться назад, и заметить, что теперь мы более глубоко понимаем различия между философией, методологией и фреймворком.

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

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