企业架构  |  业务分析   |   敏捷研发  |  自我成长

在每周敏捷布道课的第0课给大家看过一张讲义，

这是Scrum框架，其中有一个工件是完成标准。那么，你知道敏捷中的完成标准是什么呢？如果不知道，今天的课程正好给你补一补。

《Scrum指南》 “完成”的定义

    既然是布道，那自然要给大家一些正规渠道的说明。那我们先来看看《Scrum指南》中官方的说明吧。（关于这个文档，可以在本文最后说明进行下载）

当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum 团队之间会存在巨大的差别，但是每个团队成员必须对完成工作意味着什么有相同的理解以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。

这一定义也同时被用来指导发团队开了解在Sprint 计划会议时能选择够多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。

开发团队开在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。如果“完成”的定义对增量来说是发组织开的惯例、标准或指南，那么所有Scrum 团队都必须遵守它，以此为最低标准。如果增量“完成”的定义不是发组织开的惯例，那么 Scrum 团队中的发团队开就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起发开，那么所有 Scrum 团队中的发团队开必须一起参与制定“完成”的定义。

每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。

随着团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。任何产品或系统都应该对其上面发开的工作有“完成”的定义。

《Scrum实战》我们如何知道何时才算完成

下面是有李娜老师给大家做的课程分享讲义，详细课程内容可扫码学习

我的观点

我成立IT帮，主要是想帮助更多人成为复合型人才的学习者，成为一个有思想、有目标、有行动的完整个体。我会开展一系列的学习和分享，这次敏捷课堂就是其中一期书虫会内容。作为分享者或老师，我希望能带给大家不一样的内容：

• 它不一定面面俱到，但应该视角独特

• 它未必百分之百正确，但或许能给你启迪

• 它也许给不出答案，但能拓展你的思考空间

在前面课程中我说到，敏捷中质量是很重要的一个维度。在传统开发中，我们有很多评审，一到敏捷了，很多人误以为不要文档，也不需要评审了。其实，我的观点与此正好想法，正因为这些隐藏的东西让很多团队实施敏捷时遇到很多障碍：

• 不仅不是不需要文档，而且文档要求更高了。这些文档不仅要技术人员能看懂，而且要全员都能看懂，并且帮助大家沟通协作。

• 也不是不要评审了，而是要大家在自组织的状态频繁的评审，只是由正式评审改为非正式评审了，其中对DoD的检查就是一种“评审”。

在我以前带过的所有团队，在还没用敏捷开发时，我经常会告诉研发人员每人根据自己的任务制定一个checklist。这个检查列表干嘛用的呢？就是把自己要做的工作都列出来，如果认为自己工作做完了，再转移到下一步之前先自我检查一遍。后来用敏捷开发了，这个检查列表就可以作为DoD的一部分。

那敏捷下的DoD该如何去做呢？

我除了深入思考敏捷之外，我也在企业架构上不断学习，并在不同体系间思考之间的联系。在企业架构中对流程架构会分层分类，讲究价值。所以我认为一个完整的DoD应该首先分层，

然后可以针对每一层进行各自交付物、流程等分类。例如对于sprint可以参考本次授课的示例，我想说的就是一定要注意这些流程是不是value-added的。

具体细则如何定义，可以看前面李娜老师的步骤，我就不再重复了。

当然，DoD会有敏捷中带来的更多含义：

• 工作质量：不一致标准会带来bug、不满意的客户和低维护性。DoD能有效的变为团队的价值声明。

• 透明：每个人都明白每个可发布增量是如何制定决策以及需要做什么

• 反馈：我们对Done进行跟踪就能给我们及时的反馈

• 除了以上这些，在沟通、预期、决策和计划上都给团队带来帮助。关于DoD能带来什么，在本次课上李娜老师也做了分享，我不再细说了。
  

上面这些都是敏捷中常提的一些内容，但是很多敏捷新团队并不能马上能够做好，所以制定DoD呢就正好可以帮助初级敏捷团队去做得更好一些。

如果你作为ScrumMaster，在你带着团队去制定DoD时，一定要知道，你负责引导，你不制定细则，即使你看到你认为应该包括的细则没有出现在团队的DoD中你也不要太激动，你要做的是观察到团队会这样的根本原因：

• 团队没有足够的技能去完成为一个sprint或特性所要做的活动

• 团队没有正确的工具（例如持续集成环境、自动构建、服务器等）

• 团队实质不是在做敏捷，而是小瀑布方式

• ......

除了去观察这些DoD产生背后的原因之外，你还要比成员更加清楚的知道：

• DoD不是静态的，它要持续变化。因为前面的障碍如何解决了，你对完成的定义肯定也不一样了，那DoD自然也要变了

• 你可以把DoD当做一个检查列表，这就意味着你在过程中一定不要让它形同虚设，你可以在每日站会、评审会议、回顾会议加入对DoD关注的环节。这个在本次课程李娜老师也讲到了一些。