Критерии готовности: менять или не менять?

28 Июн 2017

Критерии готовности (Definition of Done) –  контрольный список видов работ, которые команда должна сделать в спринте, чтобы создать кусочек продукта (инкремент), потенциально готовый к поставке. Они должны быть определены командой до того, как начнется первый спринт. Минимальный критерии готовности должен обеспечить на выходе готовый кусочек функционала продукта, который будет представлять для клиента определенную ценность.

Например: «чтобы считать, что мы доделали инкремент продукта, все функции должны быть спроектированы, разработаны, интегрированы в Х версию продукта, и протестированы». В общем, это и будут критерии готовности. В общем виде.

Можно ли менять критерии готовности, когда scrum-команда уже определила их? И да, и нет. Давайте разберемся в этом неоднозначном вопросе.

Можно ли ослаблять критерии готовности в ходе спринта?

Представим ситуацию: команда задалась вопросом: «Можем ли менять критерии готовности во время спринта?». При этом один из критериев готовности функции — это проверка, например, на тестовом сервере. Естественно, тестирование нужно провести до того, как scrum-команда заявит о готовности элементов бэклога спринта. И вдруг мы узнаём, что по причинам, не зависящим от команды, тестовый сервер еще не готов к запуску, а до конца спринта остаётся два дня. То есть, если сервер не станет доступен в ближайшее время, команда по определению не выполнит ни одну из пользовательских историй в текущем спринте.

Что же делать? Должна ли команда отказать от тестирования, выступающего в качестве условия критерия готовности в текущем спринте?

Препятствия на пути к успешному выполнению командой работы возникают постоянно. Важно, чтобы препятствия стали видимыми и понятными для всех участников команды. В особенности для тех, кто должен работать над их устранением (например, куратора проекта). Поэтому команде в такой ситуации не стоит вставать на скользкую дорожку «ослабления» критерия готовности во время выполнения спринта. Иначе возникает желание использовать этот «грязный приём» для того, чтобы «успешно» завершать спринты.

Так что краткий ответит на вопрос в подзаголовке – нет, не стоит.

Но если мы не ослабим критерий готовности, то нам будет нечего показать на обзоре спринта. Что делать?

Хорошо, допустим, мы не вносим изменения в критерии готовности, из вышеописанного сценария. Это приводит нас к ожидаемому вопросу от команды: «Если мы не внесем правки в критерий готовности, тогда у нас не окажется готовых элементов, выполненных в текущем спринте. Что же нам в таком случае показывать на обзоре спринта?». Хороший вопрос. Ведь согласно фреймворку SCRUM показывать на обзоре спринта нужно только законченные истории.

Должна ли команда отменить обзор спринта? В таком случае будет только одна тема для обсуждения – почему команда не успела доделать то, что запланировала? И хотя дискуссия на эту тему, проведённая в конструктивном ключе, может быть довольно полезной – это не цель обзора.

Для обсуждения и рассмотрения таких вопросов в Scrum существует отдельное мероприятие, под названием ретроспектива.

В случае, когда команде нечего показать (или она так думает), можно пойти двумя путями:

1) не проводить обзор спринта, тем самым избегая траты ценного времени заинтересованных сторон.

2) провести обзор и показать работу, которая прошла все стадии, кроме тестирования (если брать наш пример выше). Обязательно объясните заинтересованным сторонам, что результаты могут измениться после проведения тестирования. Да, это не то же самое, но можно попробовать собрать хоть какую-то обратную связь. В некоторых случаях показывать неоконченную работу также имеет смысл (обзор только выполненных работ – всего лишь правило, а не закон).

Можно ли усиливать критерии готовности в ходе спринта?

Да, когда это имеет смысл. Рассмотрим пример.

Есть компании, которые производят комплексные продукты, состоящие из оборудования и программного обеспечения. В начале разработки, скажем, команда разработчиков создает функции, которые в конечном итоге должны быть развернуты на аппаратном обеспечении, которое параллельно разрабатывается другой командой.

Во многих таких компаниях создается программный эмулятор аппаратного обеспечения, и софтверная команда первоначально тестирует свои новые функции на виртуальном оборудовании. Таким образом, до тех пор, пока пригодное для использования аппаратное обеспечение не будет доступно для команды разработчиков, его критерии готовности будут ограничены «эмулятором».

Однако, как только аппаратное обеспечение будет готово к использованию – «тестирование на эмуляторе» уже не будет таким важным критерием готовности. И если это произойдёт во время спринта, то команда может заменить «тестирование на виртуальном оборудовании» на «тестирование на реальном оборудовании». Такое усиление критерия конструктивно, эффективно и не противоречит принципам Scrum.

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

С другой стороны, если «железо» стало доступно под конец спринта –  команда может быть не уверена в том, что успеет всё переделать. В таком случае, встаёт риск не успеть доделать ничего. Брать на себя этот риск или нет – решать команде. Но мы рекомендуем не стоит ставить под угрозу целый спринт.

Это приводит нас к следующему выводу.

Предпочтительнее вносить изменения между двумя спринтами

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

Критерии готовности могут меняться со временем. Фактически, в любое время, когда то или иное препятствие исчезает, у команды появляется возможность «усилить» критерии готовности.

Предположим, что до недавнего времени у нас была только одна небольшая команда, которая проводит тестирование производительности. Все остальные команды пользуются её услугами для тестирования результатов своей работы. Тем не менее, мы наняли и обучили сотрудников тому, как проводить необходимые тесты, и теперь каждая scrum-команда имеет собственного тестировщика в команде. В этом сценарии «тестирование производительности», вероятно, не было первоначальным критерием готовности для команд. Ведь ранее они полагались на команду тестирования. Но поскольку проблема, связанная с недостатком ресурсов, была устранена, мы можем добавить новый критерий в наш список.

Заключение

Критерии готовности  ̶  контрольный список задач, который scrum-команда использует для проверки соответствия требованиям инкремента продукта, создаваемого в ходе спринта. Возьмите за правило, не ослаблять критерий готовности в ходе спринта во избежание расхолаживания команды и потери фокуса. Однако вы можете усиливать ваш критерий готовности, при условии, что это не поставит под угрозу цель спринта. При нормальном ходе проекта лучше всего изменять критерии готовности между спринтами.

Смотрите также:

• Обучение: Тренинг «Agile: гибкий подход в управлении проектами»
• Новость: Начала работу подгруппа применению Agile в госсекторе
• Статья: Ретроспектива: хлеб и масло Agile

Источник: http://www.innolution.com/blog/changing-the-definition-of-done

Перевод: Елизавета Дубовская, Артемий Анцупов