Хабрахабр

Синхронизация команды со SCRUM

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

Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.
Статья была подготовлена членами нашей команды: Марина, Дима, Настя, Вероника, Толя.

Команда под проект собиралась с нуля. Не так давно (чуть более полугода назад) в Альфа-Банке стартовал новый проект — «Онлайн-Ипотека». Все было прямо по гайду: DevTeam (JS, Java, QA, Аналитик), скрам-мастер и Product Owner. Люди на проект пришли разные и с разных мест работы. Никто из девтим до этого никогда не работал по скрам-фреймворку.

Первая точка синхронизации: DOR

Итак, мы все собрались, познакомились и почти сразу приступили к делу. Впереди нас ждало множество неочевидных (на первый взгляд) идей. Большинство из них впоследствии стали обыденными и логичными. Но вот что мы долгое время не могли побороть — это мнимая понятность задач. Часто бывает так, что берешь задачу в спринт, а она оказывается не так проста (а иногда и сложна), как казалось на первый взгляд.

Рассинхрон для нас заключался в следующем:

  • разные миры, в которых живет бизнес и девтим,
  • разная степень готовности user story к тестированию,
  • разное понимание завершенности задачи.

Решение пришло как-то само собой. Мы взяли стандартный инструмент и решили опробовать его в деле. DOR (Definition Of Ready) позволяет снизить степень неопределенности в задаче и согласовать действия PO (Product Owner) и девтим до начала работы над задачей. С помощью такого подхода мы всегда можем более или менее четко определить степень неизвестности, с которой столкнемся в ходе разработки, и учесть ее в оценке трудоемкости.

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

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

Дело в том, что он не должен представлять собой набор четких указаний от работодателя. Тут стоит отметить, что DOR у каждой команды должен быть свой. Это скорее требования команды к минимальному описанию задачи и проработке подводных камней, которые должны быть выполнены для удобства и ускорения работы.

Наш DOR

Критерии готовности user story к взятию в работу

  • Четкая постановка «Что?» — от PO (минимум за неделю до начала спринта)
  • Верхнеуровневое описание логики задачи «Как?» — от DevTeam (до начала спринта)
  • Готовый дизайн (если он необходим): т.е. утвержденный текст и дизайн.
  • После начала спринта условия задачи не меняются.
  • Описание минимальных требований в jira аналитиком происходит до начала работы разработчиков (в самом начале спринта)
  • Задача прогрумлена и имеет оценку

Вторая точка синхронизации: DOD

Очень хорошо, когда вся команда понимает, какие задачи мы можем помещать в спринт, а какие лучше не стоит. После выполнения условий DOR мы столкнулись со следующим: мы берем задачу (user story) в работу, но как мы можем понять, что она точно готова?

Но что, если мы не завели саб-таску по документации, тестированию или настройке доступов? Конечно, мы можем посмотреть на все саб-таски (sub task) и оценить готовность задач по ним. Есть ли необходимость каждый раз заводить подобные саб-таски?

Допустим, мы идеально заводим саб-таски и идеально вовремя их закрываем. Ну хорошо. Но ведь задача еще не на бою! Тогда логично было бы закрыть задачу сразу после мерджа в мастер. Пользователь не увидит пользы от нашей работы, и все было зря.

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

DOD очень похож на DOR. DOD (Definition Of Done) позволяет решить проблему приемки и общего понимания готовой задачи. Взглянув на него, мы всегда можем сказать: готова задача или нет. Это такой же набор критериев, но на этот раз для готовой задачи.

Наши наброски по DOD

В результате мы выработали общее понимание того, что надо сделать, чтобы считать задачу закрытой. Только после выполнения всех пунктов задача переходит в DONE.

Подводим итоги первых двух шагов синхронизации

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

Один из разработчиков может сделать изменения (без возможности откатиться), которые коснутся другого разработчика. Аналитик не всегда может изначально проверить все задачи в спринте. В конце концов, PO тоже люди, и задачи могут меняться в ходе спринта, даже если это сильно не приветствуется в скраме.

В любой команде почти всегда можно видеть одну и ту же проблему. На самом деле есть целая масса случаев, которые могут привести к конфликтам и непродуктивной работе между этапами взятия в работу и завершения задачи (для краткости — DOR и DOD). Это провоцирует конфликты и негатив. Кто-то что-то куда-то залил, и второй разработчик теперь страдает. И, конечно, эта проблема почти всегда возникает, когда одной задачей занимаются несколько разработчиков.

К сожалению, ничего подобного и подходящего к нам мы не нашли (может быть, плохо искали). Вначале мы пытались найти что-то из уже существующего вроде DOR и DOD. Каждая задача состоит из разнородных частей. Пробовали 1 work in progress, но опыт не удался. Не так давно мы собрались и подумали над еще одним промежуточный этапом: Наш опыт показал, что при таком подходе кто-то из разработчиков всегда скучает, а кто-то вынужден задерживаться на работе и доделывать свою “половинку”.

Третья точка синхронизации — наша собственная задумка: DOT

DOT (Definition Of Test) представляет собой набор критериев тестирования задачи и сборки ее в единое целое на тестовом стенде. Также мы устанавливаем правила о том, что девтим не может приступать к дальнейшим действиям (pull requests и тд), пока DOT не будет выполнен полностью.

Для начала представим, что у нас имеется только один разработчик на одну задачу: Взглянем на рисунок и попробуем разобрать идею более подробно.

У нас есть то, что должно быть сделано, и то, что делать нельзя до выхода из зоны тестирования. Сразу отметим здесь ключевую особенность. Сюда можно отнести прохождение pull request, мердж в мастер, выкатку и прочее.

Когда мы говорим про DOR, мы говорим о том, что нужно для решения задачи. Сразу стоит отметить отличие от DOR и DOD. В DOT на нас влияют сразу несколько видов обстоятельств. При разговоре о DOD, мы говорим какую задачу можно считать сделанной. С другой, многие действия для доведения задачи в полностью готовый вид делать не стоит. С одной стороны, разработка задачи должна быть завершена.

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

Понятно, что у нас один специалист может помогать (или мешать) другому. Схема очень примерная. А выкаткой на бой может заниматься другой человек. Необходимость доработать задачу может всплыть раньше. У нас есть некая область с четко оговоренными ДО и ПОСЛЕ. Главное тут другое. И только после этого можно получить ОК от тестирования. Более того, ПОСЛЕ не может наступить, пока не будут выполнены все условия DOT.

Как видно из картинки, разработка может начинаться в разное время. Что еще тут важно? Чем они будут заняты в это время — можно договориться. Самое главное тут то, что в область тестирования входят несколько разработчиков в разное время, но выйти из нее они могут только вместе.

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

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

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

Пример процесса разработки нашего шаблона

Заключение

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть