Scrum и Definition of Done

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

В этом посте я хочу описать, как мы пытались решить эту проблему в Softline, и про мой опыт работы в Scrum-команде в Финляндии, где эта проблема была решена с помощью Definition of Done.


Методом проб и ошибок

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

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

В результате довольно долгого процесса из проб и ошибок, мы пришли в конце концов к следующим двум пунктам:

1. Баги (defects) должны были содержать информацию и инструкцию по их воспроизведению:
   • Версия платформы (в нашем случае версия SharePoint)
   • Версия продукта
   • Номер ревизии в Source Control
   • Какие права должны быть у пользователя, какой вид аутентификации и т.п.
   • Браузер
   • Шаги, которые приводят к возникновению ошибки: нажать то-то, набрать то-то, кликнуть туда-то, бац ошибка
   • Скриншот самой ошибки
2. Задачи (tasks) должны были содержать, помимо описания самой задачи, план тестирования этой задачи - т.е. какие вещи надо проверить по окончании задачи

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

А вот со вторым пунктом оказалось хуже - попросту говоря, он не принес ожидаемого результата. Сам план тестирования часто оказывался неполным и надуманным, и задачу все равно фейлили или считали не выполненной до конца, хотя план тестирования выполнялся.

Definition of Done

В Финляндии мне посчастливилось 3 месяца проработать в Scrum-команде, в которой я узнал о термине Definition of Done (DoD) и ощутил все преимущества использования Definition of Done на практике.

Если вкратце, Definition of Done определяет, что мы имеем в виду, когда ставим у задачи статус "Выполнена".

Т.е. штука в том, что все задачи разные, и ставя "Выполнено" напротив двух разных задач, мы часто имеем в виду под "Выполнено" совершенно разные вещи.

Например может быть такое, что код был написан, но протестировать его не представляется возможным пока не готова часть, которую делает например вообще другая компания или другой отдел или другая команда. В этом случае есть несколько вариантов решения:

• Слепо посчитать задачу выполненной и создать еще одну задачу по "интеграции", которую кинуть в бэклог и не брать в спринт, пока не будет готова "чужая" часть.
• Вместо тестирования провести code review, и считать задачу выполненной по итогам code review.
• В рамках этой же задачи создать заглушки и тесты, чтобы можно было протестировать выполнение задачи без необходимости ожидания другой компании/команды/отдела.

Все три варианта имеют полное право на существование в разных случаях, и как сами понимаете это три разных варианта и как раз если бы для задачи был задан Definition of Done, он бы как раз описывал, какой же из этих вариантов имеется в виду (потому что по умолчанию разработчик всегда выберет первый вариант, самый бесполезный - да еще и задачу по интеграции скорее всего не создаст).

А например для задач, которые получены через HelpDesk или Change Request (т.е. непосредственно от клиентов) - важно прежде всего отгрузить фикс клиенту, но также отдельной задачей может быть "предотвратить возникновение этой проблемы в дальнейшем/у других клиентов". И снова понять, что конкретно требуется сделать, поможет именно Definition of Done.

Последний пример: для каких-то новых модулей / фич часто важно, чтобы модуль был не просто сделан, но задокументирован, включен в установщик, обеспечено обновление со старых версий и т.п. И снова здесь Definition of Done очень помогает понять, что конкретно требуется выполнить в рамках именно этой задачи.

В общем, на текущий момент я считаю, что Definition of Done - должен быть. Это помогает не только не ссориться разработчикам и тестировщикам, но также помогает product owner'у лучше выразить свои желания по scope спринта, и команде - более точно оценить user stories.

Как писать Definition of Done

Технически, Definition of Done - это одно предложение в конце задачи, начинающееся со слов "done=..." (или можете конечно писать по-русски, "сделано=..."). Кстати именно эта лаконичность - один из атрибутов успеха DoD. Одно предложение легко можно написать на planning poker'е - это быстро и не отвлекает команду от процесса.

Давайте я приведу несколько вариантов Definition of Done:

1. done=функционал реализован и выгружен на продакшн
2. done=модуль реализован и написан Deployment Guide
3. done=создан документ "спецификация по модулю", пройден ревью с архитектором
4. done=проведена встреча с клиентами и вынесено решение по вопросу, описанному выше. соответствующие задачи добавлены в бэклог.
5. done=клиент закрыл задачу в HelpDesk (или done=клиент закрыл change request)
6. done=код написан, пройден code review с Васей
7. done=функционал реализован и продемонстрирован на Sprint review meeting

Несколько рекомендаций по написанию Definition of Done:

1. Желательно описывать в Definition of Done что-то материальное, что можно проверить. Создан документ, проведен ревью, фича выгружена на продакшн, созданы задачи, и т.п.
2. Definition of Done должен писаться в терминах задачи. Не надо еще раз описывать все то, что в задаче уже написано.
3. Definition of Done должен быть максимально кратким, в одно предложение.
4. Не стоит писать в DoD очевидные вещи, типа "CI билд не падает" или "код закоммичен". Если вы хотите где-то прописать такие базовые вещи, создайте себе "default'овый" DoD, обговорите его с командой, распечатайте и повесьте на доску или каждому положите на стол, чтобы проверяли в виде чеклиста.

Что еще почитать

Описанная выше методика - это то, что мы успешно использовали на практике в нашей Scrum-команде на протяжении трех месяцев (6 спринтов). В интернетах вы найдете другие руководства по использованию Definition of Done, которые могут значительно отличаться от того, что я описал выше. Scrum он такой: только самые общие техники совпадают, но в деталях Scrum всегда сильно адаптирован к конкретной команде и компании.

Если вам интересна эта тема и вы хотите еще почитать про Definition of Done и вообще Scrum, рекомендую пошарить на InfoQ - там можно найти большое количество качественных материалов и презентаций по теме Agile, в том числе про Definition of Done.

Заключение

Definition of Done - это признак для определения, засчитывается ли выполнение задачи или нет. В Scrum'е, как известно, только выполненные user story идут в increment и участвуют в расчете velocity, поэтому наличие Definition of Done очень полезно для правильного расчета velocity и как следствие напрямую влияет на более точный estimation задач.

Кроме того, Definition of Done позволит избежать непонимания в команде, уточнить scope спринта, сделать задачи более четкими и определенными.

В общем, если вы еще не используете Definition of Done в вашем Scrum - рекомендую попробовать.