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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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