Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo

Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo

В руководстве про Скрам-разработку и просто в статьях о Agile практиках разработки часто встречаются методы чек листов типа DoD, DoR, CoS и ToDo. Давайте разберемся что это такое и как ими пользоваться.

DoD – Definition of Done

По каким критериям мы можем сказать что задача выполнена (Done)?

Критерий готовности инкремента продукта. Также можно сказать что это критерии готовности задачи для доски или всех задач в команде.

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

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

Например:

  • если есть новые методы, по ним должны быть написаны тесы
  • код должен быть протестирован
  • код должен быть прокоментирован
  • стиль кода должен соответствовать PSR-1, PSR-2
  • если тесты подразумевают контроль на боевом контуре, задача остается на контроле до полного подтверждения результатов

CoS – Conditions of Satisfaction

Conditions of Satisfaction — переводится как условия удовлетворенности.

CoS – это чек лист приемки результатов работ по конкретной задаче. Помимо DoD которые на все задачи распространяется в целом. CoS пишется на конкретную задачу. Чтобы разработчики понимали что именно является результатом. Условиями удовлетворенности результатами.

Часто CoS именуют как AC или Acceptance Criteria – Критерии Приемки. Оба термина правильные, являются синонимами. Просто в сокращенном варианте CoS понятнее чем AC. Потому получил больше популярности.

Например:

  • Клиент может купить товар и оформить его через быструю форму обратного звонка, чтобы сэкономить свое время
  • Статистика о использовании формы передается в Гугл Аналитику

DoR – Definition of Ready

По каким критериям мы можем сказать что задача подготовлена (Ready)?

DoR – это чек лист с критериями по которым мы можем сказать что задача готова к разработке. Описана, подготовлена, декомпозирована и может передаваться в разработку.

Если в команде нет DoR, то возникают проблемы с пониманием задачи разработчиками, результаты есть, но они не те что ожидалось Клиентами.

Появляются ошибки и растут затраты на переделку задач.

Например:

  • сформулированы пользовательские истории
  • задача декомпозирована по методу ВИСИ
  • у задачи прописан CoS

У разных команд чек лист может быть разным.

ToDo – Что делать?

Этот чек лист отвечает на вопрос что делать? Или чаще на вопросы кто и что делает?

Просто список шагов, что позволяет лучше понимать кто и что делает или уже сделал.

Например:

  • создать отдельную ветку в репозитории (Вася)
  • прописать базовые юнит тесты (Петя)
  • протестировать интеграцию с системой поставщика (Катя)
  • согласовать изменения по протоколу с отделом маркетинга (Инокентий)

Этот чек лист обычно меняется по ходу дела. Может менять по 5 раз в день. Обновляется по ситуации.

Многие системы имеют функционал который позволяет быстро обновлять этот список дел и менять акценты (приоритеты).

Итого

Управление по чек-листам это очень простые, эффективные и удобные практики разработки.

Самые важные и нужные тут это CoS & ToDo. Они применяются очень часто, для команд любых размеров. И даже в индивидуальный разработке.

Реже используются DoD & DoR. Как правило это инструменты для крупных команд, сложных систем. Где есть аналитики, тестировщики, сложна предметная область и т. д.

При умелом применении они позволяют существенно улучшить взаимодействие и взаимопонимание в команде. Заметно сократить ошибки и риски. И как следствие вывести результаты на качественно новый уровень.

Информация была полезна для вас?

Расскажите пожалуйста что мы можем улучшить?

оцените контент и участвуйте в выборе трендов