• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

完工标准(DoD)究竟该怎么定义?

在我上一篇关于“专业软件团队创建工作软件”的文章中,David Corbin提出了一个很好的观点。您如何确定“无故障或缺陷”的含义?由于其因产品而不同,且可能随时间变化,因此您需要关注质量,并体现在完工标准(Definition of Done,DoD)定义中。

太长不看版本:

开发人员最终负责创建可工作软件的已完成增量,已完成的增量,已完成的

 

开发人员需要决定在组织环境和产品领域中“已完成”意味着什么。他们需要坐下来创建一个清单,清单上的每一项对于要交付的每个产品增量来说都是真实必须的。工作软件不特定于某个产品待办事项而是适用于整个交付。不仅仅是用于每个单独的产品待办事项。

完工标准(DoD)通过使所有人对于作为产品增量的一部分,什么样的工作算是已完成的工作有一个共同的理解来创建透明度。如果一个产品待办事项不符合“已完成”定义,则不能被发布,甚至不能在冲刺评审中进行展示。相反,它将重返产品待办列表以作后续斟酌。”

—— 2020版Scrum指南

如果你不能至少每30天发布一次工作的软件,那么根据定义你还没有在实施Scrum。因为“专业的Scrum团队构建的软件是可工作的”,所以请停下来,先创建一个符合你的“完工标准”的可工作软件增量,然后开始冲刺,并持续审查你赋予“可工作”的含义,最后至少有一个较为规律的交付节奏。

什么是完工标准(DoD)?

你需要从某个地方开始,通常我们没有从零开始的产品。要么我们交接了一个现有的产品,要么我们是创建产品的团队,正在转型到Scrum。无论您的产品起源于何处,代码以及产品当前都不会是可工作软件。如果你对什么是“可工作的”没有确切的定义,它如何能成为可工作的软件?但是你怎么可能对可工作的含义没有一个定义?那么你是怎么做的呢?

在砍掉一行代码之前,你需要决定“已完成”对你的产品和公司意味着什么。如果你正在为起搏器构建固件,或者是创建电子商务门户,则完工标准的定义将非常不同。以下是完工标准的一些特征:

  • 一份简短、可衡量的检查表 —— 尝试在DoD中设置可测量的内容,以便测试结果,最好是以自动化的方式。
  • 可发布的镜像—— 在你的产品可能还没有发布的时候,虽然我们推荐这样,你应该可以有这样的选择。你的产品负责人应该能够在冲刺评审中说:“太棒了……让我们来发布吧。”
  • 无需进一步的工作 —— 开发人员无需其它工作即可将产品交付生产。任何额外的工作都意味着没有完成,这会占用下一个迭代的开发容量。理想情况下,你有一个完全自动化的软件交付流程,并且永远不要跨迭代进行交付。

你需要定义一个简短的、可测量的检查表,它反映了产品的可用性,并且发布产品不需要额外的工作。我发现做到这一点最好的方法是让Scrum团队(产品负责人加上开发人员和任何干系人)参加一个有人引导的DoD定义研讨会。没有DoD我们就不会理解可工作软件意味着什么,而如果没有可工作的软件,我们就无法获得可预测的交付。你的产品负责人不能拒绝待办事项,只能判断产品增量是否可工作。

我的第一个完工标准(DoD)

你的完工标准不是神奇地出现的,而你的软件也并不可能魔法般地遵从这个标准。让你的软件符合完工定义是一项非常艰难的工作,虽然你对完成的定义应该有机地增长,但你需要创建一个可以在其上构建的种子。
我建议你与整个Scrum团队,以及其他领域专家一起举办一个研讨会。如果软件在开发人员完成后还必须通过阶段门闸,那么还需要这些门闸的代表参加研讨会。无论是什么样的产品,你都可能需要具备以下专业领域的代表:代码、测试、安全、用户体验、用户界面、架构等。你的团队中可能有这方面的专家,或者你可能需要从组织中,甚至组织外部引入他们。

以下是一些可以纳入DoD定义的例子:

  • 增量通过SonarCube检查,无严重错误 —— 你可以随着时间的推移逐渐提升标准,因此你可能需要说“代码通过Sonar Cube检查且不超过50个严重错误”,然后随着时间推移而努力。
  • 增量的代码覆盖率保持不变或更高 —— 查看一个特定的衡量标准,比如90%的代码覆盖是一个熟悉的说法,但不会告诉你任何关于代码质量的信息。然而,监控和测量代码覆盖率的不利变化可能是有好处的,我们始终倡导TDD实践。
  • 增量符合一致认可的工程标准 —— 你应决定方法、测试、变量以及其间所有事项的命名规则,从小处着手,随着时间推移而增加。在Wiki链接更新您商定的标准,并不断改进和扩展您的规则。尽可能自动化。
  • 增量通过产品验收标准 —— 确保至少满足规定的标准是一个值得称赞的目标,基于ATDD实践将其自动化则更好。
  • 增量验收测试是自动化的 —— 确保所有测试都自动化。如果你认为有些东西会有问题,那么你应该对它进行测试。
  • 增量通过安全检查 —— 使用自动化工具作为构建的一部分,并检查已知的安全漏洞。你不会发现所有的安全问题,但至少不要做我们知道的那些安全性匮乏的事情。
  • 增量符合一致认同的用户体验标准 —— 同样,要有一个Wiki页面并确保你复核过。如果您没有使用自动的完工标准门闸,那么就需要团队来同意是否符合标准。
  • 增量符合一致认同的架构指南 —— Wiki非常棒,但尽可能把它自动化。

无论你想出的完工标准如何定义,都不太可能整个产品目前就已经符合标准。你还没有实施Scrum,在开始冲刺之前,需要集中精力确保当前增量满足新定义的完工标准。专注于质量是开发人员的责任,在开始之前确保你的目标增量满足新的质量标准,达到所有定义的质量标准则是下一个增量“完成”的前提。

完工标准是对增量的质量承诺!

创建一个符合完工标准定义的可用增量,然后开始冲刺。保持你的软件处于工作状态将需要一个现代化的源代码控制系统,该系统为你提供良好实现DevOps实践的工具。

 

发展你的完工标准(DoD)

始终改善质量是非常重要的,这意味着你至少需要定期对完工标准进行思考和改进。在Scrum中,这种节奏是由冲刺的长度决定的,在冲刺回顾会中有一个改善时刻。这并不意味着你不需要一直考虑完工标准,恰恰相反。你不断地思考你的增量目前是否符合完工标准的要求,以及你需要做什么才能实现。你应该一直思考你的完工标准是否符合你的需要。如果开发人员在冲刺过程中发现完工标准缺少一些东西,那么他们应该继续添加以确保不会危及冲刺目标。

正如David Corbin在我之前的文章中指出的那样,你可能会发现产品存在性能问题。我们如何确保解决这个问题?在我看来,遇到这个情况你有两个方面可以考虑。你可以Scrumble(因为质量差而停止冲刺)并修复它,或者你可以将这些新知识整合到你的产品周期中。

如果这是一个导致你无法得到可用软件的重大问题,那么则需要中止并修复它。在Scrum中,这被称为Scrumble,这反映了开发人员由于缺少某些东西而陷入困境。在继续冲刺之前,应该停止添加新功能,并在继续冲刺和添加新功能之前创建一个可用的增量。一旦问题被修复,你就可以完善完工标准的定义,以确保将来的所有增量都满足新的要求。

如果问题不太严重,你可能希望继续工作,并将需要的内容添加到产品待办事项列表中。然后,你可以在接下来的几个冲刺中提交改进,以缓解并解决识别出的问题。一旦解决了这个问题,你就可以通过向完工标准中增加相应的内容来巩固效果。

我们应该始终寻找提高质量的方法。今天你对“完工标准”的定义是什么样的?欢迎在评论区留言。

 

【作者】Martin Hinshelwood

Martin Hinshelwood是一位专业Scrum培训师,专业看板培训师,以及微软开发技术MVP。他2000年开始从事软件交付工作,并于2010年开始从事DevOps和敏捷方面的咨询、辅导和培训工作。自2008年以来,Martin帮助了许多机构,并在全球37个国家培训了1000多名人员。

原文地址:https://www.scrum.org/resources/blog/getting-started-definition-done-dod

 

Search
最新敏捷认证课 ~ 火热报名中
3月2-3日
Scrum.org专业Scrum Master (PSM I) 认证课
丁志润 Derek Ding 授课
3月23-24日
高级Scrum Master (A-CSM) 认证课
Ethan Huang 授课
3月30-31号
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280