Как начать Scrum?

Как организовать Скрам Команду? Каким образом ввести События Скрама? Что такое Скрам Артефакты и где с ними работать?

Организовать Scrum в проектном офисе - это определенно отличная идея, но никто из нас этого не делал!.. Тогда пустим в ход основы Scrum и будем познавать его через собственный опыт.

Как я уже писал ранее - Scrum описан в одном кратком документе, который называется Scrum Guide. Там максимально понятно и лаконично описаны его основы, к которым зачастую придется обращаться. Разберем основы Scrum в сравнении с Waterfall методологией.

Scrum Team (Скрам Команда)

Обычно простые проектные команды (методология waterfall) включают следующие должности и их функциональные обязанности:

• Project Manager (Руководитель Проекта) - управление и ответственность за исполнение проекта, составление плана проекта, оценка рисков, контроль функционала и стоимости проекта.
• Analyst (Аналитик) - описание процессов "как есть" и "как должно быть", проектирование и документация решения проблем, передача, консультация и приемка задачи в разработке.
• Developer (Разработчик) - проектирование и создание программного продукта, алгоритма или исследование поставленной задачи.
• Tester (Тестировщик) - тестирование программного продукта на работоспособность и соответствие поставленной задачи.

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

Гибкая методология Scrum разделяется всего на 3 роли:

• Scrum Master (Скрам Мастер) - следит за соблюдением командой и её окружения всех ценностей Скрама, а также помогает при работе внутри команды и с её окружающей средой.
• Product Owner (Владелец Продукта) - отвечает за максимизацию стоимости продукта, над которым трудится команда.
• Development Team (Команда Разработчиков) - выполнение всей работы по разработке продукта.

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

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

Scrum Events (События Скрама)

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

• Обследование - интервьюирование Заказчика по рассматриваемым процессам.
• Планирование - демонстрация и обсуждение сроков реализации и трудозатрат, стоимости работ и договорных условий.
• Разработка - процесс разработки обычно сопровождается краткими вопросами (обычно в устной форме) и краткими демонстрациями функционала.
• Тестирование - сдача работ Заказчику по факту выполнения и совместное тестирование.
• Мониторинг - поддержка Заказчика и проверка полученных результатов по проекту.

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

События Scrum:

• Sprint (Спринт) - промежуток времени от месяца и менее (обычно кратно неделям от 1 до 4), в течение которого выполняются все Скрам События и действия команды.
• Sprint Planning (Планирование Спринта) - первая встреча, на которой Скрам Команда (Скрам Мастер, Владелец Продукта и Команда Разработки) проводит планирование работ на грядущий Спринт.
• Daily Scrum (Ежедневный Скрам) - ежедневное совещание внутри команды разработчиков для планирования работы на текущий день.
• Sprint Review (Обзор Спринта) - встреча Скрам Команды и Заказчика для окончания и проверки проделанной работы во время Спринта.
• Sprint Retrospective (Ретроспектива Спринта) - заключительная встреча Скрам Команды для обсуждения завершенного Спринта и планирования улучшений командной работы в следующем Спринте.

Про события Scrum также важно понимать, что они строго ограничены во времени (имеется верхняя граница, которую нельзя превышать) и составе участников.

Разберёмся в чём же принципиальная разница двух подходов:

• События или совещания в Каскадной модели обычно планируются, исходя из этапов проекта (инструмент - диаграмма Ганта) - В Scrum нет понятия этапов, здесь используются конкретные и реализуемые цели за каждый общепринятый командой промежуток времени (1, 2, 3 или 4 недели). Также в Scrum есть обязательные виды совещаний команды, которая позволяет ей всегда оставаться в контексте поставленной цели.
• Характер событий в Каскадной модели (обследование, планирование, разработка, тестирование или мониторинг) обычно разделяется по функционалу и каждый член проектной группы имеет свой план задач - Scrum лишен этого разделения, потому что команда - единое целое и она самоорганизуется в зависимости от сложившейся ситуации. Возможно, разработчику придется где-то выполнить весь функционал, а потом за ним просто проверит второй по схеме парного программирования и они оба сдадут эту задачу заказчику.
• В Waterfall всю работу постоянно контролирует Руководитель проекта - Scrum лишен надзирательной функции руководителя проекта, потому что есть Владелец продукта, который формирует ряд максимально востребованных задач и при необходимости помогает команде в них разобраться. Scrum Master всегда готов облегчить работу скрам-команды и, узнав на ретроспективе или еще где-либо о какой-нибудь внутренней или внешней проблеме, должен в ней разобраться и разрешить как можно скорее

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

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

• Отчет об обследовании - описывает процесс "как есть" и "как должно быть".
• Устав/паспорт проекта - основной документа по проекту, в которому описывается план-график работ, предпосылки и цели работы, ограничения, проектная команда, планируемые результаты, стоимость и риски.
• Техническое задание - постановка задачи на разработку.
• Протокол приёмо-сдаточных испытаний - план-факт работы по тестированию проектных задач.

Scrum имеет Артефакты вместо этих документов. Одно другое может и не заменять, но все понимают, что смысла нет в больших талмутах документации, а смысл есть в выпускаемом как можно скорее продукте:

• Product Backlog (Бэклог Продукта) - упорядоченный список известных требований к продукту.
• Sprint Backlog (Бэклог Спринта) - набор элементов Бэклога Продукта, взятых в Спринт, а также план по достижению Цели Спринта и поставке Инкремента продукта.
• Инкремент - сумма завершенных в Спринте элементов Бэклога Продукта и всех Инкрементов предыдущих Спринтов Продукта.

По традиции рассмотрим различия методологий:

• Разрабатывая Waterfall-документацию, проектная команда лишает себя как Исполнителя и Заказчика возможной гибкости, что ставит во главу угла не цели и результаты, к которым приведет выпуск продукта, а сам процесс выполнения проектных задач - Scrum наоборот подразумевает у выбранного Продукта нескончаемый процесс развития и важно не непрерывно выполнить какие-либо действия, а важно получать реальные результаты при проверке гипотез, которые могут повлиять на судьбу продукта как положительно, так и отрицательно.
• Техническое задание на наш проект - это может быть Бэклог Продукта или Спринта. но описанный максимально понятным способом с расставленными приоритетами.
• Инкремент уникален в своей составляющей, потому что только Scrum, говоря о непрерывном потоке задач по Продукту, может позволить себе гордиться любым накопленным за всё время существования Продукта результатом.

Личный опыт Scrum-трансформации

Расскажу про порядок перехода на Scrum в своей команде. На тот момент наши роли разделялись следующим образом: 2 аналитика, 2 разработчика и я частично выполнял обе роли помимо административной.

1. Работа над списком задач

1.1. Ревизия задач

В нашей Jira за 2 года работы накопилось много замороженных и старых задач, которые нужно было совсем удалить или актуализировать. С этого мы и начали: выписали полный список всех незакрытых задач и вынесли их на обсуждение с топ-менеджерами компании.

Пример таблицы со списком ИТ задач для ревизии

Совершенно неосязаемый список задач из Jira вначале превратился в 67 строк, а позже и вовсе сократился до 56 строк и 28 проектов в Excel.

1.2. Приоритезация задач

В списке задач есть колонка "Приоритет", которая заполнялась также совместно с топ-менеджерами. Необходимо основываться не только на личном отношении, но и вовлечь бизнес для реализации стратегии компании.

Из интересного по приоритезации: процесс этот довольно трудоемкий и требует постоянной перестановки чисел между строками. Совет: первичный приоритет можно расставить самим и умножить его на 10, чтобы задачи постоянно можно было потом тасовать совместно с бизнес-заказчиками.

1.3. Делегирование задач

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

2. Внедрение Scrum

2.1. Выбор продукта

Основным нашим продуктом "как ни крути" является учетная система 1С, поэтому Управленческая база 1С - это наш продукт, над которым мы планировали трудиться.

2.2. Организация команды

С ИТ-директором мы приняли решение составить 2 Scrum-команды по одному продукту: техническая поддержка и оперативные проекты. Это понятно противоречит Scrum-логике, но задумка была следующая: есть задачи на поддержке, которые требуют выпуска релизов как можно чаще и растягивать небольшие задачи нет необходимости - для него короткая длина спринта - 1 неделя. Параллельно идут крупные проекты: почему параллельно? Потому что там спринт на 2 недели и предоставить инкремент (прирост продукта) мы можем только на выходе через 2 недели, не раньше. Инкрементом в проектах должен быть не обязательно запуск всего проекта, а возможно тестовой эксплуатации по проекту или самостоятельной и конечной части проекта.

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

2.3. Первая неделя работы

С 3-й недели мы в проектном офисе начали работу по спринтам: запустили техническую поддержку и начали работы по первому крупному проекту, который рассчитан на первые 2 недели.

Когда пишу про недели спринтов - они означают недели года, потому что так проще планировать спринты и строить по ним отчеты (в самом начале есть цифра, по которой можно сортировать).

Планирование спринтов проходило с участием всех топ-менеджеров компании. Для ведения работ по Scrum мы продолжили использовать - Jira. Важно понимать количество работающих пользователей и делать его не более 10, иначе 10$ превратятся в 3500$ в год за 25 лицензий.

Итак, мы уже имели Product Backlog, в котором были задачи технической поддержки, оставшиеся после ревизии и требующие доработки. Product Backlog для оперативных проектов состоял из большого списка проектов (столбец "Проект" в списке задач Excel), которые значились как Epic и более мелкие задачи по ним. Первым мы взяли один из Epic’ов и ряд задач, позволяющих получить на выходе спринта готовый тестовый продукт. Звучит странно (готовый и тестовый) - суть в том, что задача настолько крупная, что в рамках Definition of Done (определение для задачи - сделано) по входящим в спринт задачам проводится специальное тестирование. Но организованный в результате продукт (тестовый стенд) должен быть предоставлен реальным пользователям и уже от них должен быть получен feedback (обратная связь). Тогда уже мы, выявив оставшиеся проблемы, сможем выкатить его в рабочий релиз для постепенного внедрения.

С командой разработчиков мы провели оценку задач числами Фибоначи (взяв ряд из чисел 1,2,3,5,8,13). С первого раза оценки разнятся, потому что разработчики оценивают по-своему, а аналитики по-своему. Есть задачи чисто для аналитиков и там у них оценка оказывается более низкой, а есть задачи на разработку, где разработчики оценивают в меньших числах. После 2 итераций мы пришли к общей оценке в команде и начали работу.

2.4. Первые проблемы в команде

По ходу работы на 3-й неделе возникли проблемы: все сотрудники были в курсе работы по Scrum, но каждый из них до конца не осознавал всей сути. Основная цель Scrum - командная, слаженная, кросс-функциональная и самоорганизованная работа на реальный результат. На наших Daily Scrum (Ежедневный Скрам) я стал понимать, что самоорганизация у сотрудников не получается.

1. Все видят объем задач, свои фамилии рядом с ними и их оценку, но всё сводится либо к тому, что каждый начинает работать сам по себе, либо задает вопросы мне - как руководителю. Со своей стороны я понимаю, что вхожу в Development Team и должен выполнять, помогать с задачами, если нужен. Помимо этого со своей стороны я стараюсь помочь ребятам коммуницировать друг с другом, объединяя их в группы для работы над их задачами. Мы понимаем, что у нас один сотрудник не сможет заменить другого, потому что их квалификация разная: например, аналитик и разработчик, но также понимаем, что один не сможет справиться без другого.
2. Еще одна проблема в том, что одна и та же команда разработчиков должна выполнить задачи в 2 спринтах и распределение происходит по принципу: вначале делаем задачи по короткому, если находим время в коротком, то берёмся за длинный. Когда задачи выполнены по короткому спринту, то беремся за длинный до окончания короткого. Вес каждого спринта должен быть распределен так четко и логично, чтобы не перекрыть друг друга и оба были выполнены в полной мере.

Подведем итоги

1. Чтобы внедрять Scrum в своей команде, особых навыков не нужно, но желательно иметь человека с опытом такой работы. Отголоски классического подхода всегда будут тянуть обратно, что надо сразу же пресекать. Основной документ для изучения всем - Scrum Guide с его Командой, Событиями и Артефактами.
2. Вводить События Скрама нужно не только в команде, но и в компании в целом, т.к. Обзор Спринтов проводится с заказчиками, которые должны быть в курсе. К сожалению, в Scrum нельзя постепенно вводить события и плавно переходить: нужно приучать всех к работе по-новому и если у участников есть вопросы - сразу же их закрывать.
3. Скрам Артефакты - постулаты методологии, предназначение которых также вся организация должна понимать. Они имеют принципиальное различие с каскадной моделью работы и намного более ёмкие, но в то же время очень гибкие и простые. Обработка Артефактов сократит невидимый разрыв между разработкой и бизнесом: эффективность и отношение улучшиться.