什么是Scrum中的DoD和DoR？（译）

What are DoD and DoR in Scrum?

什么是Scrum中的DoD和DoR？

Matthias Orgler

Definition of Done (DoD) and Definition of Ready (DoR) are important — and too often misunderstood— concepts in Scrum. Let’s clarify what they are…

完成的定义（DoD）和就绪的定义（DoR）是Scrum中重要的--但常常被误解的--概念。让我们澄清一下它们是什么吧...

Definition of Done (DoD) tells you when something is finished and ready for shipping 完成的定义(DoD)告诉你什么时候东西已经完成并准备好发布了

DoD = Definition of Done

DoD=完成的定义

The DoD is usually a short document in the form of a checklist, that defines when a product backlog item (i.e. user story) is considered “done”. It has various rationales and various ways to explain it:

完成的定义一般是一个简短的文件，通常是一个检查列表形式，里面定义了什么时候产品待办清单（即，用户故事）会被认是“完成”的。它有多种理由和解释的方式：

· You need a common definition of what “done” (= “this user story is finished”) means. Otherwise it will mean something else for every person on the team.

· All your non-functional requirements reside in the DoD.

· A general list of acceptance criteria to be added to every story’s specific acceptance criteria.

· Many improvements you find in your retrospectives end up in the DoD.

· 你需要对 "完成"有五个共同的定义（="这个用户故事已经完成"）。否则，它对团队中的每个人都会有不同的含义。

· 你所有的非功能需求都存在于DoD中。

· 在每个故事的具体验收标准中加入一个验收标准的总清单。

· 你在回顾中发现的许多改进最终都在DoD中。

Most teams start with no or a very simple DoD. They then add to the DoD after each sprint as needed. Tip: Don’t paralyze yourself with an excessive DoD! But keep in mind: “done” in an agile project means “no more work needs to be done before shipping”. So if someone says “the feature is done, but it only needs to be integrated, tested, deployed, …” it would NOT be considered “done” in an agile sense!

大多数团队开始时没有或只有非常简单的DoD。然后他们在每个冲刺阶段之后根据需要增加DoD。提示：不要用过多的DoD来麻痹自己。请记住：敏捷项目中的 "完成 "意味着 "在发布前不需要再做任何工作"。所以，如果有人说 "功能已经完成，但只需要集成、测试、部署......"，在敏捷的意义上，这不会被认为是 "完成"。

The best check whether something is “done” is to simply ship it! If you can ship it, it’s really done; if you cannot ship it, simply do the work missing before you can ship it to make it “done”. Mind you: you don’t need to actually ship it, but you need to make believable that you could.

检查一件事是否 "完成 "的最好方法是直接发布它！如果你能发布，它就真的完成了；如果你不能发布，就在你发布之前做那些缺失的工作，以让它“完成”。请注意：你不需要真的发布，但是你需要让人相信你可以发布。

A typical DoD might look like this example:

一个典型的DoD可能看起来如下：

· Automated tests are written and all tests are green

· Code is refactored and reviewed

· Code is integrated with master branch

· Deployed to staging environment

· Translated into English and German

· 编写自动化测试，并且所有测试都已通过（变绿）

· 代码已经进行了重构和评审

· 代码与主分支已经集成

· 部署到了准生产环境（中间环境）

· 已经被翻译成了英语或者德语

A concise definition of done will help you deliver quality, keep your slate clean and react flexibly to changing requirements.

对 "完成 "的简明定义将帮助你交付质量，保持你的清白，并对不断变化的要求作出灵活的反应。

DoR = Definition of Ready

DoR=就绪的定义

The DoR is the little cousin of the DoD. It is a checklist of what needs to be done to a product backlog item before the team can start implementing it in the next sprint. You can view the definition of ready as the “DoD” the Product Owner has to fulfill so that the Development Team accepts the story in the Sprint Planning meeting.

DoR是DoD的小老弟。它是一份清单，列出了在下一个冲刺阶段团队开始实现产品待办清单之前需要做的事情。你可以把就绪的定义看作是产品负责人必须完成的 "DoD"，以便开发团队在冲刺计划会议上接受这个故事。

Note that the DoR is NOT part of the Scrum Guide — and that is for good reason. The DoR should not be used as a phase gate for Sprint Planning or as a way push away responsibility! It should rather be a guideline for the team of what needs to be done during backlog refinement. If you’re interested in the reasons why the DoR is not part of the Scrum Guide, see Why isn’t the Definition of Ready described in the Scrum Guide? by @Barryovereem for more insight.

请注意，DoR不是Scrum指南的一部分--这是有很好的原因的。DoR不应该被用作Sprint计划的阶段性门禁，也不应该被用作推卸责任的方式。它应该是团队在梳理需求待办列表时需要做什么的指南。如果你对DoR不是Scrum指南的一部分的原因感兴趣，请看@Barryovereem的《Scrum指南》中为什么没有描述就绪的定义？

Most teams start out with an empty DoR and add to it as needed. Again: don’t paralyze yourself by coming up with lots of bullet points here! It’s better to start simple and then add to the DoR as needed.

大多数团队开始时没有DoR，会根据需要添加到它。再次强调：不要用大量的检查点来麻痹自己。最好从简单的开始，然后根据需要添加到DoR中。

A typical DoR might look like this example:

典型的就绪定义如下例所示：

· PO and Dev Team need to have talked about the story at least once

· Story must have clear business value

· Effort needs to be estimated

· Story must be broken down enough to fit a single sprint

· Story needs at least one acceptance criterium

· PO和开发团队至少就故事已经讨论过一次

· 故事必须具有清晰的业务价值

· 工作量需要被估算出来

· 故事已经被拆分到小到可以在一个Sprint内完成

· 故事至少已经有了一条验收条件

In all honesty, you will likely not need to write this down. When you talk about new user stories in a backlog refinement session, you will intuitively drive stories towards being “ready for sprint”.

说实话，你不一定要把这些写下来。当你们在一个需求梳理会议中谈论新的用户故事的时候，你会直觉驱动故事朝着“迭代就绪”的状态推进。

In case you want a good guideline for your DoR, consider the INVEST schema: A user story should be Independent, Negotiable, Valuable, Estimable, Small and Testable. Read this wonderful article by @jeremyjarrell about How to invest in your user stories. Here is a short description:

如果你想要给你的DoR一个好的指南，可以考虑INVEST模式：用户故事应该是独立的，可以协商的，有价值的，可估算的，足够小并可以测试的。阅读@jeremyjarrell关于《如何实现你的用户故事》这篇精彩的文章吧。下面是简短的描述：

· Independent. A user story should be independent from other stories. If you really write “user stories” as opposed to traditional work items or tasks, you will end up with drastically fewer dependencies automatically. Occasionally you might still have dependencies — in that case simply note the dependencies.

· 独立的。一个用户故事应该是独立于其他故事的。如果你真的写了 "用户故事"，而不是传统的工作项目或任务，那么你最终会自动减少依赖性。偶尔，你可能仍然有依赖关系--在这种情况下，只需注意依赖关系即可。

· Negotiable. A user story should describe what the customer needs, not how the developer should implement it. The development team should always be able to propose alternative solutions/implementations to deliver the business value for the customer.

· 可以协商的。一个用户故事应该描述客户的需求，而不是开发人员应该如何实现它。开发团队应该总是能够提出其他的解决方案/实施方案，为客户提供业务价值。

· Valuable. The business value must be stated. This is often the “…so that…” part of the user story format: “As a persona I want feature so that I get business value”.

· 有价值的。必须说明业务价值。这通常是用户故事格式中的"...以便于... "部分。"作为一个角色，我想要的功能是让我获得业务价值"。

· Estimable. The development team has to be able to roughly estimate the effort of the user story. This often means that the development asked the product owner a few clarifying questions and came up with a rough idea of how it could be implemented.

· 可估算的。开发团队必须能够粗略估计用户故事的工作量。这通常意味着，开发向产品所有者询问了一些澄清的问题，并提出了一个关于如何实现的粗略想法。

· Small. It has to be small enough to be done within a sprint. If it is estimated to be bigger than a sprint, keep splitting the user story until you have small stories.

· 足够小。它必须小到可以在一个Sprint完成。如果估计要比一个Sprint大，就继续拆分用户故事，直到你获得了小的故事为止。

· Testable. You need to be able to test, whether the user story is done and fulfills its purpose. This usually means you need a set of clear acceptance criteria that you turn into test cases.

· 可测试的。你需要能够测试，用户故事是否完成，是否达到了目的。这通常意味着你需要一套明确的验收条件，并将其转化为测试案例。

Again, don’t over-theorize the DoR. Stick with INVEST or agree on a simple format the development team needs before they can sensibly start work. Both the product owner AND the development team are responsible for getting a story ready in the sense of your DoR.

同样，不要把DoR过度理论化。坚持使用INVEST或者商定一个简单的格式，让开发团队在合理地开始工作之前需要。产品所有者和开发团队都有责任在DoR的层面上准备好一个故事。

When do you create the DoD & DoR?

什么时候可以创建DoD以及DoR？

Both, DoD and DoR, are typically edited and extended in the most important meeting in Scrum: the retrospective.

这两个定义，DoD和DoR，一般情况下会在最重要的Scrum会议，即回顾会议中进行修改和扩充。

In my experience it pays to start with a very simple (or even empty) DoD and no formal DoR. Most teams quickly write this down collaboratively during an initial meeting before the project starts.

从我的经验而言，从一个非常简单（或者即便是空的）DoD或者非正式的DoR开始是好处的。大多数团队在项目开始的会议里会快速写下这些内容。

As the project continues, you will often find solutions to impediments during your regular retrospectives (a meeting to improve your work process held after every sprint). Many of these solutions end up in the DoD or DoR.

随着项目的进行，你可以在定期的回顾会议（一个在每个Sprint之后旨在提升工作过程的会议）中找到解决障碍的方法。其中一些解决方案最终会被写入DoD或者DoR。

Summary

总结

The DoD is a very important concept in Scrum. It helps to have a common understanding of what work needs to be done before a user story is considered “finished”, it is a place for process improvements and it holds non-functional requirements. You should keep it minimal or you will hardly ever get something done in a sprint.

DoD是Scrum中非常重要的概念。

The DoR is kind of the “DoD for the Product Owner”. It helps the PO to know what to do to a user story, before she can hand it to the Development Team in the next sprint planning meeting.

DoR是一种“PO的DoD”（对此我很难认同，译者）。它可以帮助PO知道，如何在她下一个Sprint计划会中提供给开发团队之前如何处理一个用户故事。

Both, DoD and DoR, are mostly formed during retrospectives — so keep these important retrospectives productive and never skip them. Don’t over-theorize the DoD or DoR — let them develop from your real, practical needs. Your goal is to have a shippable product increment at the end of each sprint — what that means for your product will be your DoD.

DoD和DoR都是在回顾会议中形成的--所以要保持这些重要的回顾会议的成果，不要跳过它们。不要把DoD或DoR过度理论化--让它们从你的真实、实际需求中发展。你的目标是在每个冲刺结束时都有一个可交付的产品增量--这对你的产品来说意味着什么将是你的DoD。

If you liked this article, you might also want to check out my other articles on Scrum, for example Why your Daily Dcrums suck (part 1) .

如果你喜欢本文，你还可以查看一下我的其它关于Scrum的文章，比如：《为什么你的每日站会如此糟糕（第一部分）》。

About Me

关于我

I’m Matthias Orgler, an agile coach and Scrum trainer with more than a decade of practical experience in agile projects. I have worked in Silicon Valley, coached many international companies and today offer my experience in video courses and classroom trainings from my European home in Germany. Feel free to contact me with questions — I always love to help and to make the world a better place by spreading the agile mindset.

我是Matthias Orgler，敏捷教练及Scrum培训师，有着超过十年的敏捷项目实践经验。我曾在硅谷工作，为许多国际公司提供教练服务，如今我在德国的欧洲家中以视频课程和课堂培训的方式提供我的经验。如有问题，请随时与我联系--我总是喜欢帮助别人，并通过传播敏捷思维使世界变得更美好。

What are DoD and DoR in Scrum?Medium