Definition of Done

Как у вас дела с разработкой в целом? Такой вопрос может запросто сбить с толку. Хочется ответить или слишком коротко, или слишком длинно. С чего вообще начинать рассказывать? Лайфхак: в следующий раз, когда вам зададут подобный вопрос, в ответ показывайте ваш Definition of Done. Там есть многое из того, о чём вас спросили. Сейчас объясним на примере DoD на одном из наших флагманских проектов.

dod_new_small

Строго говоря, помогать отбиваться от неудобных вопросов — не то, чтобы самое прямое назначение DoD. В канонах Agile этот артефакт — список критериев, что команда будет считать выполненной работой. Обсудить; проверить, что все понимают критерии плюс-минус одинаково; повесить на видном месте; сверяться со списком в конце работы над фичей, спринтом или релизом. Алгоритм такой.

Критерии не выполнены — такие user story (или job-to-be-done, или на что вы нарезаете бэклог) считаем не готовыми; не учитываем при подсчёте velocity. Выполнены — учитываем.

Если посмотреть на DoD внимательно, там можно увидеть не только формальные критерии. Список рассказывает об особенностях проекта.

Слишком много пунктов? Возможно, были инциденты и теперь команда перестраховывается, или где-то сбоят коммуникации.

Не обновлялся с тех пор, как появился? Возможно, проект так и не вышел на желаемый уровень качества кода; по сроку должна бы уже быть зрелая стадия развития, а по факту ещё нет.

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

В действительно используемом DoD каждый пункт отражает важные события из проекта. Что-то часто ломалось? Запишем в DoD. Что-то никогда не должно ломаться ни при каких обстоятельствах? Запишем в DoD. Запишем всё, что можно забыть или нужно обязательно проверить.

Это что-то вроде свода законов в системе прецедентного права. На упаковке с орехами написано раскрыть перед тем, как начать есть? Значит, кто-то пытался сделать иначе.

Пример

Вот DoD на одном из наших проектов:

  • + Вся бизнес-логика задачи покрыта юнит-тестами
  • + Обеспечена совместимость с предыдущими версиями API
  • + API задокументировано
    • + все ошибки перечислены и описаны
    • + все устаревшие вызовы перенесены в соответствующий раздел документации соответствующую часть кода
  • + Мониторинг и логирование добавлены в нужном объёме
  • + Процедура отката нового кода с сервера настроена
  • + Все связанные задачи проверены и закрыты
  • + Проверены и закрыты все недостатки, о которых сообщила автоматическая система анализа кода (мы используем Sonar)
  • + Документация обновлена — записаны:
    • + описание задачи
    • + детали реализации
  • + Конечный результат проверен вместе с Product Owner

Что здесь можно увидеть? Работу распределённых команд, погоню за зрелыми DevOps-практиками, коммуникацию с заказчиком. Намётанный глаз даже разглядит здесь примерный размер кодовой базы.

Ок, что из этого списка можно унести в другие проекты?

It depends. DoD у всех уникальные. Но есть общие паттерны.

Не гнаться за всеобъемлющим DoD. Там должны быть минимальные требования к тому, что можно считать готовым.

Не раздувать DoD. Искать способы автоматизировать проверки и убрать из списка то, что можно проверять системно, без участия человека.

Не стремиться создать жёсткий стандарт, запрещающий всё, что в него не вписывается. Для отдельных фичей требуются дополнительные acceptance criteria, которых нет в общем DoD? Ок, пусть для этих задач это будет так.

Проверить, что DoD — это не просто формальность в духе «да-да, мы всё обсудили и теперь понимаем критерии готовности задачи одинаково», а озвученные, записанные и вывешенные на видном месте правила.

И самое главное: регулярно делать ревизию DoD.

Нам эти принципы сильно помогли в своё время.

Следующий шаг

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

***

Участвовали в создании статьи:

Женя Степченко
Евгений Степченко,
Project Manager
Серёга Никитин
Сергей Никитин,
Frontend Engineer
Соня Королёва
Софья Королёва,
System Analyst
Жеря Горбачёв
Евгений Горбачёв,
Software Developer