Процесс накопления знаний в доминантных активностях
Однажды в разговоре с участниками Скрам-команды мы обсуждали подход к работе как процесс накопления знаний. Один из разработчиков, немного задумавшись, отметил:
— Но это ведь похоже на Водопад! Мы же практикуем Agile, а делаем всё то же самое в спринтах.
Во время одной из моих последних бесед с участниками Скрам-команды о представлении работы как процесса «накопления знаний» один из разработчиков, как многие до него, заметил: «Но это же очень напоминает Водопад! Мы же практикуем Agile, при этом мы делаем всё то же самое в спринтах».
После чего он накидал прототип их доски:
«Во время планирования спринта, — пояснил он, — мы выбираем истории, которые в него войдут, и формируем к каждой список подзадач. На доске каждая история получает отдельную строку, и то, что необходимо для выполнения одной истории, отображается в графе “Выбрано”.
Непосредственно во время работы мы переставляем задачи сначала в графу “В работе”, а после, когда выполним их, — в графу “Выполнено”. Когда все задачи оказываются в “Выполнено”, историю можно считать завершённой. Как видите, мы можем параллельно выполнять разные типы задач: разработку, тестирование и бизнес-анализ».
С чего всё началось…
— Интересно, — констатировал я, — а откуда берутся истории?
— Конечно, из Бэклога, — ответил разработчик.
Я взял маркер и добавил в таблицу новую колонку:
— Получается, мы можем и Бэклог поместить в отдельный столбик?
— Да, кажется, можно и так.
— Хорошо. Но как всё же там появились истории?
— Мы создаём их во время груминга, — начал он объяснять. — Когда у владельца продукта появляется новая идея или формируется требование, мы создаём Эпик в Бэклоге.
Два раза в неделю мы проводим груминг-встречи, где обсуждаем новый Эпик и делим его на истории. У нас есть «Критерии готовности к разработке», которые определяют максимальный размер истории, подходящий для спринта. Также есть «Критерии приемки», которые нужно определить, прежде чем история попадет в релиз.
Я снова взял маркер:
— Может, тогда представим это так?
— Ещё, — добавил он, — после груминга, но до планирования спринта, мы дорабатываем макеты для UI с UX-командой. Это тоже часть критериев готовности.
— Хорошо, понял. Добавим:
Что происходит с выполненными историями
— Истории в графе «Выполнено» уже доступны пользователям?
— Нет, не сразу. Мы выпускаем готовый продукт раз в месяц. До этого истории остаются в графе “Выполнено”, пока не начнётся регрессионное тестирование. Когда проблемы устранены, мы выпускаем продукт.
Я добавил в таблицу:
Feature toggle: включение фич для пользователей
— Часто вы выпускаете фичи для ограниченного круга пользователей?
— Да! Обычно это пилотные версии, видимые только членам команды. Если всё работает, мы включаем фичу для всех.
— То есть как? Нужно нажать кнопку?
— Процесс не автоматизирован, но несложный. Меняем настройки конфигурации и тестируем продукт.
Я добавил ещё один пункт:
Рабочий процесс от начала и до конца: действительно ли это напоминает Waterfall?
В конце разговора таблица выглядела так:
То, что начиналось как упрощенное описание, стало отражать весь процесс. Жизненный цикл продукта стал прозрачным.
Замечание разработчика, что процессы происходят «в голове», частично верно, но не описывает всей картины. Гибкие команды переключаются между дисциплинами, что нужно для успешного создания ПО.
Работа начинается до спринта и продолжается после, что делает процесс совместным. Определенные виды активности — ключевые, остальные — второстепенные.
Определение гибкости компании
Гибкость команды нельзя определить, просто взглянув на доску. Она зависит от:
- Частоты перехода эпиков между этапами;
- Скорости реализации и предсказуемости;
- Частоты релизов фич.
Но главное — насколько процессы удовлетворяют потребности потребителей, пользователей и акционеров.
Хорошо спроектированная доска может показать слабые места и помочь компании стать гибче, если регулярно вводить изменения и анализировать результаты.
