Как и любая методология, систематизированная и «уложенная» в строгий свод подходов, правил, описаний, scrum разработка грешит серьезными сбоями в том случае, если особенности ИТ-проекта или требования владельца продукта отличаются от стандартных.
В таком случае наблюдается критическая рассинхронизация взаимодействий между участниками дев-тимы, из-за чего время и ресурсы тратятся впустую.
С помощью стандартного инструментария для управления ИТ-проектами не всегда удается стабилизировать такие центробежные силы, и скрам из гибкого, эффективного инструмента превращается в хаотическое действо, от которого и пошло название для этого комплекса методов («scrum» — толкотня).
Другие команды подходят к вопросу синхронизации более творчески, модифицируя структуру scrum разработки под логику конкретного проекта и выстраивают новые последовательности.
Здесь мы рассмотрим один из таких подходов к выявлению и устранению точек рассинхронизации, который доказал свою эффективность при разработке проекта олайн-ипотеки для Альфа-Банка.
Рассинхронизация на уровне DoR
Стандартное начало — определение готовности — уже принесла скрам-тиму немало сюрпризов. Вот основные причины рассинхронизации, которые удалось выявить на этапе DoR:
- Разные взгляды на задачу ProductOwner-а и девтима.
- Разная подготовка к тестированию истории пользователя.
- Разное понимание DoD.
Команда начала scrum разработку с опробования стандартного инструментария, чтобы определить «горячие» точки несовпадения во взглядах и рассинхрона при управлении ИТ-проектом. На этом этапе команда не требовала от заказчика уточнения указаний, а старалась очертить для себя задачи в общем.
Для этого в спринт брались исследования из топ-задач общего backlog-а. Это позволило сократить чек-лист проблемных мест за счет отладки общих понятий и последовательностей, в результате чего снизилась неопределенность, а оценка трудоемкости задач начала производиться более корректно.
Итогом стала готовая к работе user story, подпадающая под следующие критерии:
- Задолго до начала спринта сформулирован ответ от ProductOwner-а на вопрос «Что делаем?».
- Также до начала спринта девтимом определена логика выполнения задачи на высшем уровне.
- Подготовлены и утверждены дизайн и текст.
- Начало спринта означает прекращение любого корректирования условий выполнения задачи.
- В начале спринта и до начала разработки аналитик размещает в jira описание минимальных требований.
- Проведен груминг и оценка задачи.
Рассинхронизация на уровне DоD
Управление ит проектами на этом этапе вызывает свои специфические сложности: определить готовность user story к принятию в работу. Один из способов — просмотр саб-тасков и оценка готовности задачи по ним.
Но этот вариант решения довольно трудоемкий, да и не всегда в них есть необходимость. И даже при идеальном их ведении до выкатки на бой еще далеко, а значит, юзер не сможет оценить пользу от работы.
Комплекс критериев, предложенных в данном случае для оптимизации управления ИТ проектами, похож на DоR, но применим к исполненной задаче (см. иллюстрацию):
- Тест.
- Тест на проде.
- Заливка в мастер.
- Выкладка на прод.
- Сверка работы с постановкой задачи.
- Оформление документации.
Здесь также практикуется отход от формализации, а основной задачей обсуждения является поиск точного критерия закрытия задачи, после выполнения которого она переходит в категорию done.
Рассинхронизация на уровне DoT
Опыт показывает, что между двумя наиболее критичными точками DoR и DoT существует огромное пространство, наполненное дополнительными рисками рассинхронизации.
К примеру, разработчик в ходе разработки и управления ИТ проектом вносит изменения без возможности отката, которые повлияют на работу другого участника команды, или владелец продукта в форс-мажорном режиме меняет свои условия.
Налицо конфликт, появление негативного настроя, а в результате — падение продуктивности. Особенно это характерно для scrum разработок, где над одной задачей трудится несколько участников команды с равными полномочиями и подобными функциями.
Чтобы нейтрализовать этот негатив, скрам-тим Альфа-Банка разработала набор критериев для тестирования задач и их сборки воедино на тестовом стенде. Церемония получила название Definition Of Test (DoT).
По ее правилам, к следующим этапам управления ИТ проектом можно приступать, только полностью выполнив критерии DoT. Схема раскрывается на следующих иллюстрациях:
Кстати, третий рисунок иллюстрирует работу команды разрабов с одной задачей. Главной особенностью процедуры является определение того, что должно быть выполнено и того, что нельзя выполнять до выхода из тестовой зоны.
То есть, составление перечня обстоятельств всех видов, их правильной последовательности и критериев завершенности.
Результатом такого подхода является синхронизация действий разработчиков, благодаря которой вхождение в тестовую зону они могут осуществлять в разное время, а выход и переход к новой работе — только вместе.
Список работ и обязанностей каждого в зоне тестирования scrum разработки обсуждается отдельно.
Может показаться, что введение процедуры DoT в управление ИТ требует больших временных затрат на планирование и организацию задач при их формировании. Однако высокая структурированность и прогнозируемость стадий управления ИТ проектом при таком подходе является значительным «плюсом», который с легкостью перекрывает затраты.
Правильно организовать гибкую Scrum разработку ПО, учитывая возможные проблемы, способен только профессиональный ИТ руководитель. Мы оптимизируем работу команды разработчиков и приблизим выход продукта без ущерба его качеству. Пишите [email protected]
About The Author
Виктор