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

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

[sendpulse-form id=”278″]

Не так давно (чуть более полугода назад) у нас стартовал новый проект. Команда под проект собиралась почти с нуля. Люди на проект пришли разные и из разных мест работы. Все было прямо по гайду: DevTeam (Front-End, PHP, QA, Аналитик), скрам-мастер и Product Owner от заказчика. В девтим до этого фронты и qa не работали по скрам-фреймворку. А значит была угроза в рассинхронизации действий. Подобный опыт у нас уже был и мы решили его повторить. Было принято решение установить три точки синхронизации на каждый спринт. Давайте рассмотрим эти точки.

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

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

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

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

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

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

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

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

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

Пример DOR

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

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

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

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

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

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

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

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

Пример DOD

1. Протестировано в тестовой среде
2. Протестировано в боевой среде
3. Залито в мастер
4. Опубликовано на продакшн-сервер
5. Работает так как было описано в постановке
6. Написана документация

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

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

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

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

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

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

Третья точка синхронизации — DOQ

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

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

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

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

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

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

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

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

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

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

Заключение

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