​Определение готовности задачи

По мотивам предыдущего поста «Что значит «задача сделана».

В Scrum есть офигенный инструмент, который стоит втащить к себе, даже если у вас другой процесс и вы ненавидите скрам.
Этот инструмент - чеклист Definition of Done.
!Не путать с бизнесовыми критериями приемки!

С помощью DoD можно однозначно договориться, когда говорить «готово».
Делать каждую задачу с соблюдением DoD — способ не рождать техдолг. Потратить чуть больше времени сейчас и не занимать время у себя из будущего.

Есть несколько важных свойств DoD:

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

— Должен быть однозначным и выполнимым
Если хоть один пункт будет непонятным или невыполнимым, это может создавать впечатление необязательности.
Лучше стабильно выполнять слабый DoD из нескольких пунктов, чем игнорировать исчерпывающий но невозможный DoD.

— Составляется разработчиками
Этот пункт следует из предыдущего. Составляя чеклист, разработчики договариваются друг с другом и обязуются выполнять эти договоренности. Нельзя заставить разрабов делать то, чего они не понимают и под чем они не подписывались.

На скрине наш DoD из 12 пунктов. Мы составляли его составом участников из шести команд и потратили на это в сумме 8 часов. С тех пор прошел год, мы получили опыт использования. Наш DoD не идеален, но я точно могу сказать, что он помогает. Мы проходимся по нему на планировании и в конце спринта. Создаем карточки, если забыли о чем-то. Это не только контроль качества, но и шпаргалка: что именно нужно сделать, чтобы было качественно.

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