Как и любая методология, систематизированная и «уложенная» в строгий свод подходов, правил, описаний, scrum разработка грешит серьезными сбоями в том случае, если особенности ИТ-проекта или требования владельца продукта отличаются от стандартных.

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

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

Другие команды подходят к вопросу синхронизации более творчески, модифицируя структуру scrum разработки под логику конкретного проекта и выстраивают новые последовательности.

Здесь мы рассмотрим один из таких подходов к выявлению и устранению точек рассинхронизации, который доказал свою эффективность при разработке проекта олайн-ипотеки для Альфа-Банка.

Рассинхронизация на уровне DoR

Стандартное начало — определение готовности — уже принесла скрам-тиму немало сюрпризов. Вот основные причины рассинхронизации, которые удалось выявить на этапе DoR:

1. Разные взгляды на задачу ProductOwner-а и девтима.
2. Разная подготовка к тестированию истории пользователя.
3. Разное понимание DoD.

Команда начала scrum разработку с опробования стандартного инструментария, чтобы определить «горячие» точки несовпадения во взглядах и рассинхрона при управлении ИТ-проектом. На этом этапе команда не требовала от заказчика уточнения указаний, а старалась очертить для себя задачи в общем.

Для этого в спринт брались исследования из топ-задач общего backlog-а. Это позволило сократить чек-лист проблемных мест за счет отладки общих понятий и последовательностей, в результате чего снизилась неопределенность, а оценка трудоемкости задач начала производиться более корректно.

Итогом стала готовая к работе user story, подпадающая под следующие критерии:

1. Задолго до начала спринта сформулирован ответ от ProductOwner-а на вопрос «Что делаем?».
2. Также до начала спринта девтимом определена логика выполнения задачи на высшем уровне.
3. Подготовлены и утверждены дизайн и текст.
4. Начало спринта означает прекращение любого корректирования условий выполнения задачи.
5. В начале спринта и до начала разработки аналитик размещает в jira описание минимальных требований.
6. Проведен груминг и оценка задачи.

Рассинхронизация на уровне DоD

Управление ит проектами на этом этапе вызывает свои специфические сложности: определить готовность user story к принятию в работу. Один из способов — просмотр саб-тасков и оценка готовности задачи по ним.

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

Комплекс критериев, предложенных в данном случае для оптимизации управления ИТ проектами, похож на DоR, но применим к исполненной задаче (см. иллюстрацию):

1. Тест.
2. Тест на проде.
3. Заливка в мастер.
4. Выкладка на прод.
5. Сверка работы с постановкой задачи.
6. Оформление документации.

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

Рассинхронизация на уровне DoT

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

К примеру, разработчик в ходе разработки и управления ИТ проектом вносит изменения без возможности отката, которые повлияют на работу другого участника команды, или владелец продукта в форс-мажорном режиме меняет свои условия.

Налицо конфликт, появление негативного настроя, а в результате — падение продуктивности. Особенно это характерно для scrum разработок, где над одной задачей трудится несколько участников команды с равными полномочиями и подобными функциями.

Чтобы нейтрализовать этот негатив, скрам-тим Альфа-Банка разработала набор критериев для тестирования задач и их сборки воедино на тестовом стенде. Церемония получила название Definition Of Test (DoT).

По ее правилам, к следующим этапам управления ИТ проектом можно приступать, только полностью выполнив критерии DoT. Схема раскрывается на следующих иллюстрациях:

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

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

Список работ и обязанностей каждого в зоне тестирования scrum разработки обсуждается отдельно.

Может показаться, что введение процедуры DoT в управление ИТ требует больших временных затрат на планирование и организацию задач при их формировании. Однако высокая структурированность и прогнозируемость стадий управления ИТ проектом при таком подходе является значительным «плюсом», который с легкостью перекрывает затраты.

Правильно организовать гибкую Scrum разработку ПО, учитывая возможные проблемы, способен только профессиональный ИТ руководитель. Мы оптимизируем работу команды разработчиков и приблизим выход продукта без ущерба его качеству. Пишите [email protected]