Блог CEO, CIO Виктора Карабедянц Блог CEO, CIO Виктора Карабедянц
  • Обо мне
  • Навыки
  • Образование
  • Опыт
  • Проекты
  • Блог
  • CIO аутсорсинг
  • Контакты

Как оптимизировать SCRUM разработку с помощью дополнительных процедур DoT

17 ноября 201821 ноября 2018 / By Виктор
  • Home
  • Как оптимизировать SCRUM разработку с помощью дополнительных процедур DoT

Как и любая методология, систематизированная и «уложенная» в строгий свод подходов, правил, описаний, 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. Схема раскрывается на следующих иллюстрациях:

Этапы DOR и DOD в scrum разработке

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

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

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

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

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

About The Author

Виктор

Leave a Comment

Cancel Reply

*Please complete all fields correctly

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

Категории
  • DevOps
  • Без рубрики
  • ИТ поддержка
  • Руководитель ИТ
Популярные статьи
  • 10 причин, по которым компании привлекают своих ИТ-директоров на аутсорсингВторник - 29 июня, 2021
  • Какие нужны знания, чтобы работать DevOps-инженером: основные навыкиЧетверг - 17 июня, 2021
  • Тренд на SASE: что это и зачем нужноСреда - 12 мая, 2021
  • Ключевые вызовы для ИТ-директоров при разработке корпоративного ПО в 2021…Среда - 21 апреля, 2021
  • 5 важных тезисов для CIO по работе с ИИСреда - 14 апреля, 2021
Tags
CIO DevOps service desk Безопасность ИТ директор ИТ менеджер Удаленный ИТ директор контейнеры
Комментарии
  • Поиск доступности в облаке Воскресенье - февраля 05, 2023 08:17 пп
  • Поиск доступности в облаке Воскресенье - февраля 05, 2023 06:50 пп
  • Поиск доступности в облаке Воскресенье - февраля 05, 2023 05:44 пп
  • Поиск доступности в облаке Воскресенье - февраля 05, 2023 04:58 пп
  • Поиск доступности в облаке Воскресенье - февраля 05, 2023 01:18 пп
© 2017 - 2019 Виктор Карабедянц
Posting....