Post #28
2.07K
Определение готовности задачи
По мотивам предыдущего поста «Что значит «задача сделана».
В Scrum есть офигенный инструмент, который стоит втащить к себе, даже если у вас другой процесс и вы ненавидите скрам.
Этот инструмент - чеклист Definition of Done.
!Не путать с бизнесовыми критериями приемки!
С помощью DoD можно однозначно договориться, когда говорить «готово».
Делать каждую задачу с соблюдением DoD — способ не рождать техдолг. Потратить чуть больше времени сейчас и не занимать время у себя из будущего.
Есть несколько важных свойств DoD:
— Принадлежит продукту
Не команде и не программному компоненту, а всему продукту. При совместном владении кодом это гарантия стабильного уровня качества продукта, чтобы холакратия не скатилась в раздолбайство.
— Должен быть однозначным и выполнимым
Если хоть один пункт будет непонятным или невыполнимым, это может создавать впечатление необязательности.
Лучше стабильно выполнять слабый DoD из нескольких пунктов, чем игнорировать исчерпывающий но невозможный DoD.
— Составляется разработчиками
Этот пункт следует из предыдущего. Составляя чеклист, разработчики договариваются друг с другом и обязуются выполнять эти договоренности. Нельзя заставить разрабов делать то, чего они не понимают и под чем они не подписывались.
На скрине наш DoD из 12 пунктов. Мы составляли его составом участников из шести команд и потратили на это в сумме 8 часов. С тех пор прошел год, мы получили опыт использования. Наш DoD не идеален, но я точно могу сказать, что он помогает. Мы проходимся по нему на планировании и в конце спринта. Создаем карточки, если забыли о чем-то. Это не только контроль качества, но и шпаргалка: что именно нужно сделать, чтобы было качественно.
Если у вас еще нет DoD, советую начать с нескольких самых простых пунктов и постепенно его дополнять. Не надо рождать сразу исчерпывающий. Попробуйте итерационный подход к формированию DoD.
Эффект будет, вот увидите!
По мотивам предыдущего поста «Что значит «задача сделана».
В Scrum есть офигенный инструмент, который стоит втащить к себе, даже если у вас другой процесс и вы ненавидите скрам.
Этот инструмент - чеклист Definition of Done.
!Не путать с бизнесовыми критериями приемки!
С помощью DoD можно однозначно договориться, когда говорить «готово».
Делать каждую задачу с соблюдением DoD — способ не рождать техдолг. Потратить чуть больше времени сейчас и не занимать время у себя из будущего.
Есть несколько важных свойств DoD:
— Принадлежит продукту
Не команде и не программному компоненту, а всему продукту. При совместном владении кодом это гарантия стабильного уровня качества продукта, чтобы холакратия не скатилась в раздолбайство.
— Должен быть однозначным и выполнимым
Если хоть один пункт будет непонятным или невыполнимым, это может создавать впечатление необязательности.
Лучше стабильно выполнять слабый DoD из нескольких пунктов, чем игнорировать исчерпывающий но невозможный DoD.
— Составляется разработчиками
Этот пункт следует из предыдущего. Составляя чеклист, разработчики договариваются друг с другом и обязуются выполнять эти договоренности. Нельзя заставить разрабов делать то, чего они не понимают и под чем они не подписывались.
На скрине наш DoD из 12 пунктов. Мы составляли его составом участников из шести команд и потратили на это в сумме 8 часов. С тех пор прошел год, мы получили опыт использования. Наш DoD не идеален, но я точно могу сказать, что он помогает. Мы проходимся по нему на планировании и в конце спринта. Создаем карточки, если забыли о чем-то. Это не только контроль качества, но и шпаргалка: что именно нужно сделать, чтобы было качественно.
Если у вас еще нет DoD, советую начать с нескольких самых простых пунктов и постепенно его дополнять. Не надо рождать сразу исчерпывающий. Попробуйте итерационный подход к формированию DoD.
Эффект будет, вот увидите!
- ❤ 4
