Гибкая методология разработки Scrum, или как мотивировать всех участников проекта быть в потоке 24/7

Константин Гусев

руководитель проектов ИТ-компании ОТР

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

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

Теоретическая канва заслуживает отдельной статьи, а пока, предлагаю ознакомиться с нашей рабочей моделью as-is и убедиться, насколько просто быть в потоке проекта, применяя Scrum методологию.

Модель as-is в действии

Версия продукта (Релизность)

Это отправная точка нашего пути. План выпуска релизов формируется в предшествующем текущему году.

Версии мы ведём в формате гг.нн, где гг — год, нн — номер версии. Например, первый релиз 2020 года будет под номером 20.1, затем 20.2, 20.3 и т. д. Такой формат очень удобен, во-первых, для ведения историчности, во-вторых, для планирования задач в разрезе года.

Согласно плану выпуска в backlog Jira SM заводит версии:

Постепенно у бизнес-заказчика формируется понимание о реализации глобальных доработок в привязке к версиям. В течение года составы версий могут меняться. Конкуренция, различные факторы, влияющие на бизнес, новые открытия, технологии и прочее, и прочее находят отражение в глобальных задачах. Вчера бизнес планировал запустить версию в 3-м квартале 2020 года (версия 20.10), сегодня аналитики, проведя сильные исследования, говорят бизнесу поторопиться и запускаться во 2-м квартале (20.4).

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

Как бы то ни было, мы взяли и держим планку вот уже более 2 лет по количеству разрабатываемых релизов одновременно — 3 штуки.

Глобальные задачи

Здесь из самой формулировки ясно, что есть задачи, которыми говорит бизнес. Ему нужен комфортный авто, четыре колеса, полный бак и музыка хорошая. А что там под капотом, разберутся технологи и ОТР.

В нашем случае бизнес говорит: к 4-му кварталу 2020 года будем взаимодействовать с новым вендором для обеспечения и покрытия следующих процессов: a, b, c … n. И ещё приходит с тремя-четырьмя десятками таких глобальных задач, с разными приоритетами и ожиданием запуска в релизы 20.1–20.xx.

Регистрируем в бэклог Jira глобальные задачи — бизнес-запросы (Business-request, BR) с описанием и привязками к версиям. BR заводим запросами с типом Epic, начиная выстраивать пирамиду, где вершина — версия продукта, а основание — задачи спринта. Epic’и, так же как и версии, заводит SM.

Груминг

Обрастаем фактурой. Теперь у нас есть списки версий и Epic’и с BR:

Самое время плотно включаться командам на проработку BR для формирования историй и подзадач. SM организовывают груминги со всеми заинтересованными лицами со стороны заказчика, а также с командами внутри проекта. Именно с командами, т. к. BR могут иметь отношение к нескольким командам в зависимости от функциональности задач.

Так сложилось исторически, что у каждой BR есть направление в большую сторону одной из функциональных команд. Соответственно, ещё на стадии заведения BR в backlog, из первичного описания, у нас складывается представление, к какой функциональной области, а равно к какой команде в большей степени относится BR. SM такой команды автоматически становится драйвером всех оргпроцессов и коммуникаций.

Оценивая задачи с командой, SM собирает свой бэклог, наполняя историями. Свой бэклог SM формирует через создание спринтов в Jira. Как говорил ранее, в главе описания процесса формирования бэклога: «Оставив “жмых” более чем из сотни задач, стали распределять по командам, там же, в бэклоге, путём создания новых спринтов с припиской Backlog. Данные спринты никогда не берутся в работу, а служат только для хранения историй/задач для последующего взятия в спринт». Это действие относится и к новым задачам.

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

Истории

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

Основное условие детализации BR на истории — одна история в один спринт. История представляет собой запрос с множеством конечных подзадач. Если понимаем, что оценка задач в истории больше чем на один спринт, дробим историю на части.

Теперь backlog приобретает такой вид:

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

На скриншоте видны не заполненные цифрами серые овалы, это как раз те истории, которые предстоит оценить в ближайшем груминге.

Внутри каждой истории множество подзадач:

Спринты

SM открывает доску с бэклогом в Jira, расшаривает всей команде и все совместно приступают к формированию предстоящего 2- недельного спринта. В ходе формирования могут вноситься корректировки в составы бэклогов, историй и оценки подзадач.

После взятия в достаточном объёме задач и историй для 2 недель спринт запускается

В приведённом примере отображены дробления историй: (Часть 2), (Часть 3). В бэклоге лежит ещё по парочке «Частей» в будущие спринты.

Согласно ЖЦ доски, исполнитель проводит задачи через все циклы: Нужно сделать → Разработка → Тестирование → Выполнено.

Что касается цикла тестирования: на старте спринта тестировщики берут разработанные задачи в соответствующем статусе «Тестирование». Окей, а как быть с задачами, которые к концу спринта будут только разработаны? Здесь мы идём по двум сценариям:

1. Если функциональность не затрагивает монолит, да даже если и затрагивает, но разработчик на 100% уверен в своём результате и находит поддержку тестировщика, то выходим на показ и тестим на горячую.
2. Если дорабатывалось что-то глобальное, то тестирование переносим на следующий спринт.

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

Процесс ведения спринта описан ранее. Остановлюсь на ещё одном инструменте в Jira, который использую в рабочем процессе и который будет полезен тем, кто держит руку на пульсе — Отчёт по спринту.

А именно — диаграмма погашения. Диаграмма отражает текущую ситуацию команд с задачами. Любые отклонения — сигнал к действию.

Наша адаптация гибкой методологии Scrum оказалась настолько гибка, что в каждый описанный выше шаг мы можем вносить корректировки согласно потребностям существующих и стартующих процессов производства. В то же время нам удаётся придерживаться вектора философии Agile и достигать синергии внутри проекта, команды и каждого из нас 24/7.

Я описал адаптацию Scrum к нашим процессам, но настоятельно рекомендую ознакомиться с первоисточником, возможно, пройти курсы и понять, как лучше интегрировать фреймворк у себя. Быть может, вам зайдёт чистый Scrum, без адаптаций? Пробуйте!

На этом всё. Ну а мы пошли засучивать рукава, брать маркеры, рисовать, генерировать и воплощать в цифру самые крутые вещи ?