Упражнение на создание Критериев готовности (Definition of Done, DoD)

Источник: https://agilecomplexificationinverter.blogspot.com/2011/09/exercise-definition-of-done.html

Если ваша команда работает по скраму или с использованием других аджайл-подходов, то возможно одним из первых рабочих соглашений команды были Критерии готовности (Definition of Done).

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

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

Если у вас присутствует такой диалог (больше чем просто спор, а каждый объясняет свою позицию и озвучивает свои ценности), то ваша команда вступила во вторую из четырех стадию формирования команды (фомирование, шториминг, нормирование, высокая производительность) — поздравляем! Это кстати ещё одна причина для формирования Критериев готовности — переместить команду от незнакомцев к членам единой команды.

Поэтому вместо того, чтобы использовать чужой готовый список, лучше всего создать свой собственный. Да, иногда для запуска насоса нужно добавить немного воды. Вы можете создать энергию на встрече, предложив людям встать со своих мест (вы увеличиваете приток крови к мозгу на 20%, просто вставая) у белой доски и взаимодействуя друг с другом. Нарисуйте на доске три круга или прямоугольника друг в друге, назовите внутреннюю фигуру «Сейчас», внешнюю «Позже» и среднюю «Далее». Это способ расстановки приоритетов (сейчас -> далее -> позже), похожий например на один из способов упорядочивания бэклога.

Затем положите стикеры на стол и попросите членов команды написать на стикерах определения «Готово» (1 тезис на стикер), а затем поместите его на доску в нужном месте. Далее, следующий человек может или переместить карту в другое место (сейчас, дальше, позже), либо написать новый стикер и разместить его в выбранной им области. Игра продолжается до тех пор, пока вы будете чувствовать удовольствие или не получите список Критериев готовности, которое разделяет большинство участников. Возможно, вам захочется обсудить усиление вашего определения «Готово» со временем. Легко представить, что Критерии готовности в первом спринте будут отличаться от, например, 73-го после нескольких релизов и множества отзывов клиентов, когда у вас например будет внедрено непрерывное развертывание (Continuous Deployment, CD).

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

  • Компоненты кода развернуты на предпроде
  • Покрытие автотестами как минимум 65%
  • Настройки конфигурации интегрированы в поставку
  • Протестировано в соответствии с критериями приемки Владельца продукта (минимально)
  • Для каждой пользовательской истории указаны и пройдены критерии приемки
  • Модульные тесты написаны на уровне поведения пользователя и проходят
  • Интеграционные тесты (с использованием моков) проходят
  • Проходят все приёмочные тесты (Acceptance tests)
  • Обновлены карты тесового покрытия и отчеты
  • Код соответствует стандартам (автоматическая проверка)
  • Никаких ошибок или предупреждений при компиляции
  • Технический долг зафиксирован и понятен
  • Новая функциональность не нарушает существующую функциональность
  • Программист и тестировщик смотрят тест-кейсы
  • Используются комментарии в коде
  • В документацию добавлены новые и исправленные коды ошибок
  • Весь производственный код проходит рецензирование (просмотре кода или с помощью парного программирования)
  • Новые функции разрабатываются с учетом текущей архитектуры
  • Новые функции задокументированы, примечания к релизу обновлены
  • Код, зарегистрированный в репозитории, имеет связь с функцией / запросом на изменение / пользовательской историей и отслеживается при именениях
  • Критерии приемки протестированы в Интеграционной среде.
  • Изменения в окружающей среде документированы и доведены до сведения поддержки
  • Обновлен документ API и зарегистрирован в репозитории
  • Проверка критериев приемки программистом и тестировщиком
  • Нет дефектов с приоритетом 1 или 2 для реализованных историй
  • Тестирование подтверждает пользовательскую историю
  • Подготовлена демонстрация готового функционала (обновлены настройки БД и готов сценарий для демонстрации)
  • Владелец продукта видел демонстрацию готовой истории и принимает ее
  • Изменения инфраструктуры инфраструктуры описаны и понятны команде
  • Интеграционный тест пройден на уровне экосистемы
  • Пройдено нагрузочное тестирование
  • Команда понимает производительность систем (обновлен отчет)
  • Примечания к выпуску написаны и переданы в поддержку
  • Написаны процедуры развертывания (с откатом БД)
Share

Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение