SCRUM закрепился и в стартапах, и в IT-гигантах, но что на счёт скрама в крупной госкомпании? Попытаемся дать ответ на примере одной из команд разработки Россельхозбанка, а в конце статьи поделимся чек-листом в помощь начинающему скрам-мастеру.

Стартуем: вводные по команде и окружению

Меня зовут Аркадий Озеров, я — скрам-мастер и менеджер (совсем без этого пока не получается!) команды с кодовым названием АКПР, работаю в Департаменте информационных технологий Россельхозбанка. Сразу обозначу, что материал носит практический характер — не претендую на раскрытие теоретической части гибких подходов к разработке. Нераскрытые вопросы по матчасти можно нагуглить, благо статей на Хабре на эту тему достаточно.

Итак, Россельхозбанк — крупный госбанк в активной стадии цифровой трансформации. Команда в лучших традициях скрама состоит из мотивированных профессионалов, однако периодически принимает и обучает новичков. Не все участники проекта имели опыт работы по фреймворку на старте (забегая вперёд: 3–4 спринта требуется на обучение и вовлечение всех участников команды); команда разработки состояла из 5 человек + скрам-мастер (СМ) + владелец продукта (ВП). Проект: автоматизация кусочка кредитного процесса в части принятия решений уполномоченными органами Банка — разработка конструктора документов с гибкой настройкой базовых сущностей на web-архитектуре.

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

• Архитектура: SPA;

• Фронтенд: Angular 12;

• Бэкенд: C#;

• На старте без интеграций с другими системами.

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

Настроение: в банке тренд на внедрение гибких методик — многие хотят, но к решительным действиям не готовы. Проводится регулярное обучение сотрудников.

С чего начинали скрам в команде + наши рекомендации

Чтобы сделать конструктор документов, мы собрали новую команду. Состав оказался смешанным: новые разработчики, раньше не работавшие в банке, действующие разработчики и аналитик. Ещё к команде  присоединились только прошедший обучение СМ, опытный ВП и пара бизнес-аналитиков от заказчика. На входе — черновик «концепции» работы будущего приложения. Концепция — документ с бизнес-требованиями, оформленный командой аналитиков от заказчика. Не вдаваясь в детали, посмотрим, с чем уже может работать команда.

 Выдержка из описания функционала Системы на  этапе 1 автоматизации:

• Опросник АКПР состоит из двух основных наборов инструментов — Условий применения формулировок и Анкеты лимита.

• На основании полученного списка сублимитов Система создает соответствующее количество сублимитов.

• Каждый сублимит опционально предзаполняется типовым для данного сублимита составом формулировок на основании Справочника формулировок. Вариантов типового состава формулировок (шаблонов) может быть несколько («оборотное финансирование, без залога» / «оборотное финансирование под залог ТВО» и т.п.), должна быть реализована возможность выбора этих вариантов, а также возможность пользователя выбирать структуру сублимита «с нуля» без использования шаблонов.

• Типовой состав формулировок сублимитов не статичен и регулируется администратором Системы в зависимости от бизнес-практики.

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

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

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

Вывод или рекомендация №1. Работайте по скраму, но не создавайте «Карго-культ»: соблюдайте рекомендации фреймворка и не забывайте об адаптации. Это работает не хуже, чем в каком-нибудь стартапе или корпорации.

Начать решили с построения USM (User Story Map), то есть Карты Пользовательских Историй. Карту предстояло построить для двух релизов.

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

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

Пример детализации фичи

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

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

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

Создание карты историй — кропотливый и длительный процесс. На старте надо изучить все  хотелки заказчика, чтобы в общих чертах понимать, что он ждёт. Эти хотелки были оформлены в виде концепции, которую мы и разложили на карту.

Мы зашли в два подхода: в первом СМ сам составил карту, добавил все фичи и истории, которые смог определить, и разбил на два релиза. Это заняло 6 часов. Проработанный черновик в первом подходе сократил время на доработку карты с участием всей команды во втором подходе до 2-х часов. Отдельно хочется подчеркнуть важность такого способа составления карты: всем проще договориться, а стоимость мероприятия снижается в разы, т. к. команда отвлекается  лишь на пару часов. Для построения карты использовали Excel, хотя есть более удобные инструменты, вроде Miro или Mural. Всё-таки события разворачиваются в госбанке: тут любые внешние инструменты ставятся под сомнение и усложняют коммуникацию с другими подразделениями.

Вывод или рекомендация №2. Начинайте проект с USM, стройте карту итеративно, чередуя самостоятельную работу и общекомандную. Представьте, что вы в ламповом стартапе и радостно наклеивайте стикеры на доску.

Одна из главных сложностей фреймворка — надо договариваться внутри команды. Речь именно о командной позиции, а не о ситуации «я громче кричу, значит так и сделаем». Часто проще молча не согласиться, встретив напористый ответ, а в будущем отметить «я же говорил!». Понимание этой незатейливой идеи пришло не сразу, а к 3–4 спринту.

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

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

Бэклог или как вести разработку без ТЗ

Результатом USM является набор возможных функций, которыми может обладать приложение. Эти функции называют Историями, где каждую можно сформулировать по-разному, но для новичков рекомендуется подход «пользовательские истории». Он включает в себя описание в формате «Роль- действие-результат» и призван сформулировать историю понятным образом для любого человека, который ее увидит. Вот отличное описание подхода.

Вывод или рекомендация №4. Попробуйте подход «Роль-действие-результат» для описания историй.

Так как команда новая, решили следовать именно такому подходу. На этом этапе возникает вопрос: как оформить истории в понятном виде? Карта прекрасно визуализирует, но выглядит громоздкой и не дает возможности приоритизировать истории. Самое время сформировать бэклог продукта.

Бэклог продукта — это зона ответственности ВП, но участие команды в подготовке бэклога на старте — норма. Инструментов тоже предостаточно, но мы начали с того же Excel. Была сформирована таблица, в которой отразили основные атрибуты истории.

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

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

• Сквозной приоритет — важность истории. Команда двигается сверху вниз и всегда понимает важность каждой истории. Определяет заказчик.

• Эпик — самый большой блок, верхний уровень USM.

• Фича — функция системы.

• История — составные элементы фичи, несут радость пользователям.

• История пользователя — описание в понятном для всех виде «Роль-действие-результат».

• Место в USM — интерактивная ссылка, отправляющая курсор в место на карте, где находится история. Это просто удобно.

• Номер в Jira — ссылка на историю в Jira.

• Описание US — детальная расшифровка пользовательской истории, заполняется по желанию, чтобы добавить контекста.

• Описание TS — детальная расшифровка технической стороны истории, часто содержит ссылки на готовые требования.

• Критерии приемки — результат, который команда согласилась поставить по итогу реализации истории.

Вывод или рекомендация №5. Начинайте формировать бэклог вместе с ВП, помогите выявить технические истории и определить для них приоритеты.

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

Вернемся к примеру фичи выбора формулировки. Попытка оценить такой монолитный функционал не увенчалась успехом ввиду ухода команды в рассуждения на тему того, как можно обогатить фичу, что в теории хотел бы увидеть пользователь и чего делать не стоит. Все это нужно обсудить и это неплохо, но оценить фичу целиком не получилось. Поэтому ее раздробили сначала на крупные истории «Выбрать формулировку», «Выбрать вариант» и «Выбрать буллит». После чего попытались их оценить, снова не получилось, раздробили еще сильнее и уже финальный вариант можно увидеть на картинке USM. Их удалось оценить, но если нужно, можно декомпозировать на еще более мелкие истории.

Ещё один очевидный плюс в том, что благодаря такой детализации всегда можно показать новый функционал заказчику на демо. Декомпозицию историй ВП может проводить самостоятельно, но чаще ему в этом помогает СМ или вся команда на общей встрече.

Вывод или рекомендация №6. Декомпозируйте истории до минимально возможной величины: чем меньше история, тем быстрее ее можно превратить в ценность.

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

Какими атрибутами обладает качественная история?

1. Отношение к эпику и фиче — позволяет сохранить общее видение при фокусе на деталях.

2. Описание в формате «история пользователя» — делает историю понятной для каждого, кто ее прочтёт.

3. Подробное и/или техническое описание истории — добавляет контекст для тех, кому это необходимо.

4. Критерии приемки — самая главная часть истории. Этот атрибут определяет, что должно быть реализовано, чтобы историю считать завершённой. Это не просто формальность, а буквально ожидания заказчика, донесённые до команды в понятном виде и принятые ею.

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

Вывод или рекомендация №7. Составляйте критерии приемки емкими и понятными для всей команды.

Для понимания рассмотрим простой пример.

Задача: добавить в  текстовый редактор кнопку для печати документа.

1. Эпик — печать документа. Фича — печать документа из панели инструментов. История — кнопка «распечатать» на панели инструментов.

2. Я как секретарь хочу нажать кнопку «распечатать», чтобы документ отправился на печать.

3. Техническое описание — в состав элементов управления контейнера элементов «панель инструментов» добавить визуальный элемент управления типа button, отправляющий запрос к серверу на печать активного документа. Ссылка на ТЗ.

4. Критерии приемки — на панели инструментов в интерфейсе пользователя размещена кнопка с изображением принтера, нажатие на которую запускает функцию отправки активного документа на печать.

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

Перейдем к примеру из нашего проекта.

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

1. Эпик — не используем, т.к. нет в нашем проекте Jira, а весь бэклог перевезли туда. Фича — комментирование формулировок. История — создание области комментариев в интерфейсе пользователя.

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

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

4. Критерии приемки: разработан интерфейс области комментариев без бэкенда. Здесь посчитали нужным отметить, что история направлена именно на реализацию фронтенда без учета работ по бэку.

При этом говоря о «качественных историях», нельзя не упомянуть о критериях качества истории. На помощь командному взаимодействию приходит понятие definition of ready (DOR). На русский язык это можно перевести как «критерии готовности», поэтому сразу договоримся для DOR использовать аббревиатуру на английском языке, чтобы не путать с критериями приёмки.

DOR — это критерии готовности истории, т.е. условия, при которых историю можно считать подготовленной для того, чтобы команда взяла ее в спринт. Может представлять из себя некий чек-лист, выполнение которого проверяется для каждой истории. Этот инструмент позволяет наладить процесс взаимодействия между командой и ВП. Чек-лист может изменяться по инициативе команды — это вопрос договоренностей. Например, можно сформировать чек-лист из базовых критериев:

• история понятна каждому участнику команды;

• история оценена командой;

• результат реализации истории может быть проверен;

• история в достаточной степени декомпозирована.

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

Вывод или рекомендация №8. Определите критерии готовности истории совместно с ВП и придерживайтесь их. Это поможет сделать процесс разработки более прозрачным.

Наряду с критериями готовности истории используется аналогичный чек-лист для оценки завершенности реализации истории. Definition of done — можно перевести как критерии завершенности истории, поэтому будем также использовать аббревиатуру DOD. Этот чек-лист также упрощает взаимодействие между командой и ВП и помогает сократить объём критериев приемки за счёт фиксации в DOD базовых параметров разработки, таких как:

• код прокомментирован;

• код протестирован;

• функционал установлен в тестовом контуре;

• проведён code review и т.п.

Вывод или рекомендация №9. Сформулируйте чек-лист DOD и сверяйте с ним каждую историю. Это позволит избежать сложностей в будущем и облегчит восприятие критериев приемки.

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

Собираем рекомендации в чек-лист

1. Работайте по скраму, но не создавайте “Карго-культ”: соблюдайте рекомендации фреймворка и не забывайте об адаптации.

2. Начинайте проект с USM, стройте карту итеративно, чередуя самостоятельную работу и общекомандную.

3. Договаривайтесь и выслушивайте мнение каждого участника: кто-то может заметить риски, которые никто больше не видит.

4. Попробуйте подход «Роль-действие-результат» для описания историй.

5. Начинайте формировать бэклог вместе с ВП, помогите выявить технические истории и определить для них приоритеты.

6. Декомпозируйте истории до минимально возможной величины: чем меньше история, тем быстрее ее можно превратить в ценность.

7. Составляйте критерии приемки емкими и понятными для всей команды.

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

9. Сформулируйте чек-лист DOD и сверяйте с ним каждую историю — это позволит избежать сложностей в будущем и облегчит восприятие критериев приемки.