Критерии готовности (Definition of Done)
В Scrum Definition of Done описывает список требований, которые должны быть выполнены, чтобы считать работу выполненной.
Конкретные критерии будут варьироваться в зависимости от команды, но типичный контрольный список Agile-команды для определения готовности будет включать:
- Кодирование завершено и соответствует бизнес-требованиям и функциональным требованиям
- Тестирование завершено, отсутствуют известные дефекты или дефекты, приемлемые для этого выпуска
- Документация полная, включает последний релиз
- Элемент (пользовательская история, функция и т. д.) готов к общедоступной версии (GA.)
Это определение используется всей командой для согласования общего качества и полноты, которые должен демонстрировать готовый продукт. Эта концепция отличается от критериев приемлемости. Это широкий набор требований, которые могут применяться ко всем элементам невыполненной работы (например, к качеству).
Есть много причин, по которым Scrum-команда хотела бы реализовать подход Definition of Done для своей работы над элементами бэклога продукта. Вот несколько основных преимуществ.
3 преимущества использования подхода Definition of Done
1. Это помогает команде добиваться стабильного и предсказуемого прогресса.
Когда у них есть четкий и конкретный список критериев, которым они должны соответствовать, чтобы считать свою работу завершенной, гибкая команда может более эффективно планировать свою рабочую нагрузку. Они могут оценить сроки завершения. Определение может помочь им сосредоточиться на самом важном. Таким образом, они также с меньшей вероятностью отклонятся от графика или обнаружат, что не соблюдают дедлайны в спринтах.
2. Повышает точность оценок для кросс-функциональной команды.
Definition of Done дает понять, что нужно сделать Agile-команде, чтобы считать проект завершенным. Это помогает команде обеспечить большую прозрачность для остальной части организации. Это связано с тем, что у команды есть общее понимание того, как будет выглядеть Done и releaseable. У них больше возможностей давать точные оценки внешним заинтересованным сторонам о том, когда ожидать завершения проектов.
3. Это помогает команде работать вместе более эффективно.
Когда команда собирается, чтобы обсудить предстоящую работу – например, во время планирования спринта, – команда Scrum с согласованным определением выполнения уже имеет общее понимание того, что потребует каждый элемент спринта. Это значительно упростит команде постановку задач, слаженную работу и, в конечном итоге, последовательную разработку более качественных продуктов.
3 ошибки, которые делают Agile-команды с твердым намерением.
1. Включать требования, которые находятся вне контроля команды.
Одна из распространенных ошибок, которую допускают гибкие команды, – это включать утверждения требований от заинтересованных сторон, не входящих в группу разработки продукта. Если Definition of Done требует одобрения со стороны внешних сторон, тогда продуктовая группа не имеет окончательного контроля над тем, когда и завершится ли ее работа.
Как объясняет Scrum.org, это иллюстрирует разницу между готовностью к отправке и выпуском. Команда может захотеть иметь и то, и другое. Пользовательская история или другое дополнение продукта будет считаться готовым к отправке, когда продуктовая группа выполнила все согласованные задачи, относящиеся к этому элементу. Но на этом этапе элемент все равно должен будет пройти процесс согласования с дополнительными заинтересованными сторонами. Команда может даже охарактеризовать этот этап как «Определение почти готово».
Когда заинтересованные стороны выйдут из системы, команда рассмотрит пользовательскую историю или другой элемент, подлежащий выпуску. Это будет их Definition of Done.
2. Внесение слишком большого количества деталей в список требований.
Еще одна распространенная ошибка, которую делают здесь agile-команды, – это составление очень подробных критериев списка для перевода элементов невыполненной работы в состояние Done. Включение слишком большого количества требований и слишком большой детализации может замедлить прогресс команды и вызвать путаницу и разногласия о том, когда элемент действительно выполнен.
Эффективное Definition of Done должно описывать только минимальные шаги, необходимые для перевода стандартной пользовательской истории или другого элемента невыполненной работы в завершенную. Чтобы сделать этот процесс эффективным и повторяемым, команда должна поддерживать свой список требований на высоком уровне. Место для включения детализированного набора требований для данного проекта – это критерии приемки команды, в которых подробно описаны конкретные требования, необходимые для отдельной части работы.
Всего комментариев: 0