Задача готова! Или нет? Definition of Done и зачем он нужен
Типичный диалог менеджера и разработчика. Где-то в далекой галактике.
Разработчик: Да.
Менеджер: Давайте катить на пользователей?
Разработчик: Давайте.
Менеджер: Что‑то не вижу функциональности на продакшене?
Разработчик: Ну, нам нужно еще пару дней — пройти код‑ревью, подождать, чтобы QA протестировали, собрать и выкатить релиз в прод, сделать несколько миграций данных, и потом мы откроем фичу для пользователей.
Менеджер: Но ты же сказал, что задача готова?
Разработчик: Да.
Думаю, многие из нас были свидетелями или участниками подобного диалога. Каждая сторона считает, что задача готова, но понимание состояния готовности разительно отличается. В итоге у каждой из сторон ожидания сильно расходятся с реальностью, что негативно влияет на коммуникацию между ними и, в целом, на развитие продукта. Так, как же этого избежать?
Всем привет, меня зовут Михаил Мазеин, последние 4 года я работаю в роли Engineering Manager. Помимо управления командой и настройки процессов разработки, в моей зоне ответственности также налаживание взаимодействия между инженерами и бизнесом. В своей статье я расскажу о том, как можно решать проблемы, описанные в примере.
Definition of Done (DoD или критерии готовности)
Данный термин пришел из Scrum, и возможно, многие из тех, кто работает или работал по этой методологии, с ним знакомы. Тем не менее, попробуем поговорить о нем подробнее.
Для того, чтобы процесс разработки был эффективным, очень важно, чтобы все участники этого процесса коммуницировали на одном языке и оперировали одними и теми же понятиями. Definition of Done — это соглашение, которое четко описывает критерии готовности задачи, и что такое в нашем понимании «готовая задача».
Давайте разбираться! Рассмотрим полный жизненный цикл разработки фичи*:
*Здесь я ввожу новый термин — «фича». В данном контексте — задачи, которые приходят в разработку, являются частью реализации фичи. Фича — некоторая функциональность, (потенциально) приносящая ценность конечному пользователю.
Feature lifecycle
На данной схеме у нас отображены состояния, через которые проходит фича, а так же процессы, которые позволяют менять эти состояния. В реальности ваш жизненный цикл может быть декомпозирован сильнее и состоять из большего числа шагов, но логически он, скорее всего, будет сильно похож на представленный.
Давайте подробнее рассмотрим каждый этап:
Idea (Идея) — Работа над любой фичей начинается с сырой идеи. Нашу сырую идею нам нужно подготовить, чтобы инженеры могли начать этап разработки, приведя нашу фичу в состояние Ready (Готовность к работе) через процесс Refinement. Этот процесс вы можете знать под названием PBR, grooming, подготовка бэклога. В этой статье я не буду останавливаться подробнее на этой теме.
Ready (Фича готова к тому, чтобы быть взята в работу) — На данном этапе, мы уже понимаем, в каком виде мы хотим видеть реализованную фичу и имеем набор задач для ее имплементации. Что такое готовая к работе задача — это тоже очень хороший вопрос, который стоит синхронизировать между всеми участниками процесса разработки. Для этого существует такое соглашение, как Definition of Ready. Разговор о нем выходит за рамки данной статьи, но на хабре уже есть статья, которая раскрывает эту тему (https://habr.com/ru/articles/417101/). Готовую к работе задачу, команда разработки может уже брать в реализацию, чтобы перевести ее в состояние Done через процесс Development.
Done — задача готова (завершена, не путать с готовностью Ready). И вот здесь мы возвращаемся к вопросу -, а что же такое «готовая задача»? Проблема в коммуникации, которая показана в начальном примере, заключается в том, что разработчики и менеджеры в своем разговоре ссылаются на разные состояния фичи. Разработчики на состояние «Done», а менеджеры на состояние «Potentially shippable». В идеальном мире, эти состояния должны совпадать, на деле этого часто не происходит. Зачастую это связано с тем, что разработка не может закрыть все связанные с Potentially Shippable критерии. Например, для раскатки фичи на пользователей нам нужно подготовить маркетинговые материалы или рекламную компанию. Или команда тестирования у нас работает отдельно от команды разработки и имеет свой отдельный pipeline. Или команда девопсов, которая отвечает за деплой в продакшен, у нас находится на аутсорсе и работает обособленно от команды разработки. Для того, чтобы процесс разработки сделать понятным и прозрачным для всех участников данного процесса, нам и необходимо выработать соглашение Definition of Done, которое будет описывать, что именно команда разработки обязуется сделать в рамках процесса Development. Вся работа, которая, по какой то причине, не может быть сделана на этом этапе, будет выполнена в процессе Undone Work. Чем больше работы нам необходимо сделать в Undone Work, тем дальше мы отодвигаем состояние «Potentially shippable» от состояния «Done».
Potentially shippable — задача/фича потенциальна готова к релизу на пользователей. В этом состоянии мы уже имеем полностью функциональную фичу. На этом этапе менеджер принимает решение о том, катим ли мы фичу на пользователей (процесс Delivery) или нет (такое тоже иногда бывает). Раскатка может происходить как на всех пользователей сразу, так и поэтапно, это уже зависит от выбранной стратегии релиза.
Shipped — фича доступна всем пользователям, для которых она предназначалась.
Исходя из вышеизложенного, мы можем вывести следующую формулу:
Potentially shippable = Definition of Done + Undone Work
Чем больше Undone Work, тем больше у нас расходятся взгляды на готовность фичи/задачи между менеджерами и разработчиками. Из этого следует, что чем сильнее у нас Definition of Done, тем ближе мы к состоянию Potentially shippable. Рассмотрим примеры слабого и сильного соглашения Definition of Done.
Слабый DoD:
Код написан
В данном соглашении описан единственный базовый критерий готовности. Достаточен ли он для того, чтобы считать фичу в состоянии «Potentially shippable»? Вероятнее всего — нет. У нас остается еще огромный пласт работы в рамках Undone Work, который, к тому же, не структурирован и непрозрачен для большинства участников процесса разработки.
Сильный DoD:
Код написан
Автотесты написаны
Пройдено код ревью
Пройдено дизайн ревью
Функциональность протестирована командой/стейкхолдерами/QA
Документация написана
Код в продакшене
Данное соглашение позволяет нам минимизировать наш Undone Work и максимально приблизиться к состоянию Potentially shippable. Так же оно помогает структурировать ту работу, которую инженеры выполняют в Development процессе. При таком DoD, в рамках Undone Work у нас могут быть активности за рамками инженерной части, например, подготовка маркетинговых материалов.
Важно не забывать про часть работы, оставшуюся в Undone, и стараться делать эту часть максимально прозрачной для всех участников процесса разработки. Также важно следить чтобы у Undone Work были ответственные люди. Если в рамках Undone Work мы наблюдаем регулярные паттерны, стоит подумать над тем, как мы можем усилить наш DoD, чтобы уменьшить Undone часть, сократив разрыв между состояниями Done и Potentially shippable.
Делитесь своим опытом в комментариях!
