Чек-листы в 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. Как правило это инструменты для крупных команд, сложных систем. Где есть аналитики, тестировщики, сложна предметная область и т. д.
При умелом применении они позволяют существенно улучшить взаимодействие и взаимопонимание в команде. Заметно сократить ошибки и риски. И как следствие вывести результаты на качественно новый уровень.
