Блог SkillsCup.com

Scrum: Definition of Done – определение готовности

Что означает утверждение, что какой-то элемент бэклога "готов"? Понимает ли его вся команда и окружающие однозначно?



Increment
 — это конкретная ступенька к достижению Product Goal. Работа не может считаться частью Increment, если она не соответствует определению готовности.

Приверженность: Определение готовности

Определение готовности — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту.

В момент, когда элемент Product Backlog стал соответствовать определению готовности, рождается Increment.

Определение готовности обеспечивает прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Increment. Если элемент Product Backlog не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения.

Если определение готовности для Increment является частью единых стандартов организации, все Scrum Teams должны использовать его в качестве необходимого минимума. Если оно не определено стандартами организации, то Scrum Team должна создать определение готовности, подходящее поставляемому продукту.

Developers должны неукоснительно следовать определению готовности. Если несколько Scrum Teams работают над общим продуктом, они должны совместно определить и соблюдать одно и то же определение готовности.

Конкретные навыки, необходимые Developers, зависят от предметной области выполняемой работы и могут быть очень разными. Однако Developers всегда несут ответственность за: ...• стремление к качеству посредством соблюдения определения готовности; ...

Scrum Master служит Scrum Team несколькими способами, в том числе: ...• помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, соответствующих определению готовности; ...

Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовности в течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning.

Sprint Planning, темы 2-3 из 3:
Тема вторая: что может быть готово в этом Sprint?
Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения в текущий Sprint. Выбор элементов, которые получится завершить за Sprint, может оказаться трудной задачей. Однако, чем больше Developers знают о своей прошлой производительности, своих возможностях на следующий Sprint и своем определении готовности, тем более уверенно они могут прогнозировать работу на следующий Sprint.

Тема третья: как будет выполняться выбранная работа? Developers для каждого выбранного элемента Product Backlog планируют работу, необходимую для создания Increment, соответствующего определению готовности.

Sprint Retrospective
Цель Sprint Retrospective — запланировать повышение качества и эффективности. Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий, процессов, инструментов и определения готовности.

Каждый артефакт содержит приверженность, которая предоставляет информацию для поддержания прозрачности и сфокусированности, и по которой оценивается прогресс. • Для Product Backlog это Product Goal. • Для Sprint Backlog это Sprint Goal. • Для Increment это определение готовности.

SAFe
Set quality expectations with the definition of done.
The definition of done provides common criteria for all backlog items.
Teams create and adhere to the definition of done.
The definition of done communicates the completeness for an increment of value and creates a shared understanding of what work was completed as part of an Increment.
Definitions of done ensure functionality is delivered in accordance with internal rules and policies.

Acceptance criteria ensure functionality behaves as expected. Acceptance criteria provide the details of the User Story from a testing point of view. Acceptance criteria are created by the team and the Product Owner as User Stories are refined.

Policies about how to validate deliverables
  • Example: Stories satisfy acceptance criteria.
  • Unit and acceptance tests pass
Required tasks that reflect technical practices
  • Example: All code checked into version.
  • API and/or data model documentation updated
Required tasks that reflect Product management practices
  • Example: Releases notes created for control marketing and sales.
  • User documentation updated. Website FAQs updated.

Team Increment
• Stories satisfy acceptance criteria
• Acceptance tests passed (automated where practical)
• Unit and component tests coded, passed, and included in business verification testing
• Cumulative unit tests passed
• Assets are under version control
• Engineering standards followed
• NFRs met
• No must-fix defects
• Stories acceptance by Product Owner

System Increment
• Stories completed by all teams in the ART and integrated
• Completed features meet acceptance criteria
• NFRs met
• No must-fix defects
• Verification and validation of key scenarios
• Included in build definition and deployment process
• Increment demonstrated; feedback achieved
• Acceptance by Product Management

Solution Increment
• Capabilities completed by all trains and meet acceptance criteria
• Deployed/installed in the staging environment
• NFRs met
• System end-to-end integration verification, and validation done
• No must-fix defects
• Included in build definition and deployment/transition process
• Documentation updated
• Solution demonstrated; feedback achieved
• Accepted by Solution Management

Release
• All capabilities done and meet acceptance criteria
• End-to-end integration and the verification and validation of the Solution is done
• Regression testing done
• NFRs met
• No must-fix defects
• Release documentation complete
• All standards met
• Approved by Solution and Release Management


Эта страница – "заглушка", чтобы проверить спрос на эту тему. Ведь было бы странно, если бы я писал о проверке гипотез, но сам не проверял бы их. Если наберётся хотя быть 100 посещений этой страницы за квартал, то я перенесу эту статью сюда (статьи на Тильде получаются красивыми, но на оформление уходит несколько часов). А до этого момента вы можете прочитать другие статьи в моем блоге на SkillsCup.com.
Скрам Agile
Made on
Tilda