«Выполнено ли это задание?»
Чтобы ответить на такой, казалось бы, простой вопрос, необходимо проверить, элемент или инкремент продукта завершен или находится в работе. Однако это не поможет, если команда и заинтересованные стороны прямо не указали, что он готов.
В методиках Agile для управления проектами, таких как Kanban или Scrum, выполненная работа попадает в крайний правый столбец доски. Четкое определение критериев выполнения (DoD) позволяет agile-командам, включая DevOps и Scrum, эффективнее завершать свои задачи.
В этом руководстве объясняется значение DoD в методологиях Agile, а также рассказывается о том, как создать DoD, чтобы повысить эффективность и ценность проектов.
Понимание критериев готовности работы в Agile
DoD — это набор критериев, которым должен соответствовать инкремент продукта, чтобы команда могла считать его завершенным и готовым для поставки клиентам. Все участники команды должны понимать, когда инкремент продукта готов к выпуску, даже если он объемный и состоит из множества элементов. Определив четкие критерии готовности работы для проекта, Agile-команда может сосредоточиться на том, чтобы поставлять ценные результаты в каждом спринте и свести к минимуму количество доработок.
Обратите внимание, что критерии выполнения не определяются одним человеком. Они согласовываются всей командой проекта, включая разработчиков, тестировщиков, владельцев продукта и другие заинтересованные стороны. Благодаря этому команда работает над спринтом без недоразумений, потому что, прежде чем отметить элемент как завершенный, участники сверяются с критериями DoD и контрольным списком (при его наличии).
«Если вам приходится передавать материалы другим командам, убедитесь, что в ваших критериях выполнения (DoD) учитывается все, что им необходимо для успеха, — говорит тренер Atlassian по современной работе Марк Крут. — Обсудите с другими командами, участвующими в потоке создания ценности, что следует включить в DoD, чтобы поддержать их».
Примеры критериев готовности работы
Критерии готовности работы в рамках проекта различаются в зависимости от типа проекта и занимающейся им команды. В следующих примерах показано, как эти критерии отличаются для разных типов проектов.
Для проекта по разработке мобильного приложения критерии DoD могут быть следующими.
- Все изображения сжаты.
Весь код минифицирован и добавлен в GZIP-архив.
Критерии DoD в проекте по разработке программного обеспечения могут быть, например, следующими.
- Весь код тщательно проверен с помощью модульных, интеграционных и сквозных тестов.
Команда выполнила развертывание инкремента продукта в разделе проиндексированных файлов и протестировала инкремент.
В проекте общего характера могут быть следующие критерии DoD.
- Все ошибки устранены.
Вся документация по релизу написана и отредактирована.
Критерии готовности работы и критерии готовности к работе
DoD — это набор общих критериев, определяющих то, когда инкремент продукта можно считать завершенным. Они обеспечивают качество и согласованность результатов. Обычно команды используют DoD в конце спринта, чтобы проверить качество инкремента.
В свою очередь, критерии готовности к работе (DoR) представляют собой набор подробных и конкретных критериев, применимых только к элементам бэклога продукта. DoR определяют, когда элемент бэклога можно передать команде в работу в предстоящем спринте. Команда использует DoR для уточнения бэклога в начале спринта.
Почему критерии готовности работы важны?
Наличие DoD крайне важно для поставки качественного продукта, востребованного клиентами, поскольку эти критерии позволяют определить, когда элемент можно отметить как завершенный и включить в инкремент продукта. Хорошо продуманные DoD дают следующие преимущества.
Повышение качества: проверяя каждый инкремент по критериям DoD, Agile-команды придерживаются целевых показателей качества на протяжении всей разработки продукта. Это гарантирует, что стандарты качества для релиза выполняются постоянно.
Снижение рисков: соблюдение DoD сводит к минимуму риск доработки и связанных с этим возможных задержек, поскольку команда точно знает, каким критериям должен соответствовать элемент, который она отмечает как завершенный. Так поддерживается качество на всех этапах проекта.
Слаженность в команде: поскольку критерии DoD проекта понимает и разделяет вся команда, ей легче сосредоточиться на требованиях клиентов и поставлять ценность в каждом спринте.
Измерение прогресса: наличие четких критериев DoD позволяет командам отслеживать количество инкрементов продукта, соответствующих условиям готовности. Так, например, одним из показателей Scrum может быть скорость, которая отражает, сколько завершенных инкрементов продукта сотрудник поставляет за указанный период.
Этапы создания критериев готовности работы
Хотя конкретные этапы различаются в зависимости от команды или проекта, общий алгоритм при создании критериев готовности работы всегда одинаков. Ниже приведены этапы создания DoD.
1. Работайте с нужной командой
При формулировании DoD важно работать с нужными участниками команды, поскольку выбранным критериям должны будут единодушно следовать все сотрудники, задействованные в проекте. Привлеките всех, кому есть что сказать о том, как должна выглядеть завершенная работа в проекте: владельцев продуктов, Scrum-мастера, участников Scrum-команды, тестировщиков, менеджеров по продуктам, спонсоров и другие заинтересованные стороны.
Каждый участник команды привносит в проект знания своей предметной области и может указать, какие критерии имеют смысл с точки зрения его области компетенций. Если вы выбрали не тех участников команды или не привлекли ключевых участников, критерии DoD могут получиться недостаточно исчерпывающими, что приведет к снижению качества продукта.
2. Определите критерии
Самая трудоемкая задача состоит в непосредственном определении критериев, которые команда будет использовать для оценки готовности работ в проекте. Определение этих критериев имеет решающее значение, поскольку на кону — качество выполняемой работы.
Как понять, завершен ли каждый компонент проекта? Какие условия указывают на то, что конкретный инкремент продукта готов? Критерии должны быть конкретными, измеримыми, достижимыми, уместными и ограниченными по времени. Чтобы выбрать подходящие критерии, команда должна ответить на два основных вопроса.
- Достаточно ли критерии конкретны? Не давайте расплывчатых формулировок («весь код протестирован»). Будьте конкретны («весь код тщательно проверен с помощью модульных, интеграционных и сквозных тестов»).
- Ориентированы ли критерии на клиента? Хорошим примером будет критерий «вся документация написана и обновлена», нацеленный на облегчение поиска инструкций по использованию продукта для конечного пользователя.
«Помните, что критерии выполнения — это не то же самое, что критерии приемки, — объясняет Крут. — DoD — это набор действий, которые, по мнению команды, необходимо выполнить, чтобы присвоить пользовательской истории статус „готово“ (что может включать критерии приемки). Но это не эквивалентно утверждению, что пользовательская история была реализована корректно».
3. Составьте контрольный список
Использование критериев DoD кажется естественным для команд c крупными проектами. Однако команды, работающие над небольшими заданиями, задачами или ошибками, могут применять те же концепции для создания менее обширного контрольного списка. Наличие такого списка для каждого задания или задачи гарантирует, что команда будет стабильно поставлять результаты высокого качества.
4. Назначьте пользовательским историям критерии приемки
Критерии приемки (AC) означают условия, которым должны соответствовать пользовательские истории, чтобы считаться приемлемыми для клиентов. Они отличаются от DoD тем, что относятся к пользовательским историям или возможностям, а не к инкрементам продукта.
Критерии AC служат для определения готовности пользовательской истории или отдельного задания и, как и DoD, подлежат согласованию. Для примера возьмем такую пользовательскую историю: «Как пользователь, я хочу использовать поле поиска, чтобы находить нужные продукты». Критерии приемки могут быть в том числе следующими.
- Поле поиска находится на верхней навигационной панели.
- Поиск выполняется при нажатии кнопки «Поиск».
В поле поиска содержится серый замещающий текст «Что вы ищете?».
5. Пересматривайте и обновляйте DoD
DoD — не тот документ, который составляют раз и навсегда. Каждый баг или ошибка, обнаруженные во время спринта, являются проблемой качества, причиной которой могли быть нечеткие критерии готовности работы. Таким образом, чтобы данный баг не возник снова, крайне важно обновить DoD.
«Критерии выполнения должны быть живым документом. По мере того как вы узнаете что-то новое о своей работе, команде следует обновлять DoD, — добавляет Крут. — Подумайте о ежеквартальном пересмотре DoD, чтобы критерии оставались актуальными и включали все необходимые элементы».
Пересматривайте и обновляйте DoD во время обзоров итогов спринтов, чтобы критерии не теряли актуальности для проекта. По мере развития проекта и изучения требований клиентов, команде, возможно, также придется корректировать критерии DoD, чтобы они по-прежнему оставались достижимыми. Предоставьте участникам команды возможность предлагать изменения DoD во время обзоров итогов спринтов или на собраниях по уточнению бэклога.
Четко определите критерии DoD с помощью Jira
Пользуясь Jira, команды разработчиков ПО могут без труда сформулировать критерии выполнения. Создав пользовательские поля или скачав соответствующее расширение, можно сформировать контрольные списки по каждой задаче Jira. Создавайте отдельные критерии DoD для разных типов работы, настраивая типы задач Jira.
Миллионы высокопроизводительных agile-команд доверяют Jira поддержку своих потребностей в управлении программами и проектами, от agile-планирования до стендапов по спринтам и не только. Попробуйте бесплатно.
Критерии готовности работы: часто задаваемые вопросы
Кто отвечает за разработку критериев готовности работы?
Обычно их создает команда разработчиков под руководством Scrum-мастера. При этом нужно учитывать мнение владельцев продуктов, тестировщиков и других заинтересованных сторон.
В чем разница между критериями готовности работы и критериями приемки?
DoD — это набор общих критериев, определяющих то, когда инкремент продукта можно считать завершенным. Они применяются ко всем инкрементам продукта и в целом определяют его качество.
Критерии приемки, в свою очередь, — подробные условия, применимые только к конкретным пользовательским историям или возможностям. Критерии AC определяют, приемлема ли пользовательская история для клиента. Пример DoD: «Вся документация написана и обновлена». Пример AC: «Ссылка на пользовательскую документацию доступна в меню навигации».
Каковы рекомендации по созданию критериев готовности работы?
Определите критерии вместе с командой: определять DoD нужно совместно, при участии всей команды, включая разработчиков, тестировщиков, владельцев продукта и другие заинтересованные стороны. Критерии DoD позволяют команде прийти к единому мнению о том, когда работу над инкрементом продукта можно считать завершенной.
Держите документ на видном месте: сотрудники должны иметь под рукой критерии DoD, когда планируют спринт или вырабатывают оценку элементов в бэклоге продукта. У команды должна быть возможность постоянно сверяться с этой информацией. Напечатайте документ и повесьте его на стену или добавьте в вики либо план проекта.
Ставьте реалистичные цели: критерии DoD должны быть достижимыми в установленные сроки и с имеющимися ресурсами. Более того, эти критерии должны соответствовать реальным потребностям клиентов.