Agile, Scrum, статья

DoD |Definition of Done| Критерии готовности

By

Definition Of Done (DoD) — критерии, определяющие степень готовности задачи.

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

DoD — это чек-лист, c помощью которого можно понять, что задача готова. Каждая команда имеет свои критерии готовности. Они определяются в зависимости от контекста и состава команды. Очень важно, чтобы каждый член команды полностью понимал и принимал каждый пункт в этом списке. Другими словами DoD это разновидность командного соглашения по конкретному вопросу.

Критерии готовности, которые выбрала команда, это открытая информация, доступная всем заинтересованным лицам. Их наличие обеспечивает прозрачность, как внутри команды, так и во вне по отношению ко всей организации. Со временем команда улучшает критерии готовности путем ретроспективных изменений. Уровень DoD является показателем зрелости команды.

DoD в LeSS

Если продукт развивают несколько команд, использующих LeSS-фреймворк, то критерии готовности должны быть общими. Другими словами, нужен единый Definition of Done.

Пример DoD Scrum команды

  • Код опубликован на Dev среде
  • Unit тесты пройдены
  • Истории соответствуют реализации
  • Автотесты
  • Регресс пройден
  • CRQ — done

Пример DoD Kanban команды

Аналитика

  • Создано описание по задаче в спейcе команды согласно шаблону
  • Внесены изменения в базу знаний в разрезе элементов описания (сценариев, функций, экранных форм, печатных форм, активностей, сервисов, внешних интерфейсов, ролевой модели, домена). Изменения зафикированы в Истории изменений на странице каждого элемента описания.
  • Есть ссылка на задачу в Jira, в рамках которой было сделано изменение.
  • Выполнено ревью описания задачи и изменений базы знаний со стороны аналитика команды
  • Выполнено ревью описания задачи и изменений базы знаний со стороны поддержки
  • Описание задачи согласовано с заказчиком

 Разработка

  • Созданы отдельные ветки(а)
  • Выдержан CodeStyle
  • Unit-тесты написаны, пройдены и/или не уменьшено общее покрытие
  • Указаны компоненты (Jira)
  • Компоненты задачи раскатаны на тестовой/превью среде
  • скрипты SQL подготовлены(лежат в нужных папках) и присутствуют в конфигурации
  • Указан сервер в задаче (Jira)
  • Создан(ы) Pull Request
  • Пройдено код ревью
  • Команда проинформирована  о влиянии новых доработок

Тестирование

  • В чек-листах указана связь с требованиями (Traceability) и задачами в Jira
  • Созданные по фиче чек-листы прошли ревью со стороны тестирования, разработки и аналитики
  • Все чек-листы успешно пройдены
  • Выполнены функциональное и регрессионное виды тестирования
  • При необходимости также должны быть выполнены интеграционное, нагрузочное и др. виды тестирования, применимые для фичи
  • Успешно пройдены и заапрувлены приёмо-сдаточные испытания: UAT или Demo
  • Нет открытых дефектов по выводимой фиче.
  • Автотесты написаны в запланированном объёме
  • Сформирована автоматизированная отчётность с результатами прохождения чек-листов и автотестов

 

Definition of Ready

Кроме критериев готовности  хорошей практикой считается использовать Definition of Ready или DoR.  Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *