前因

在软件研发过程中，有很多事项需要与团队达成一致。需要与团队中的所有人同步产品规划、业务蓝图、技术规范、技术蓝图等等内容。这样为团队在长期上制定目标之后、团队内部再自行制定短期目标时就会更加贴近我们的最终目标。从而形成公司文化氛围，提高公司的整体运行效率。

在软件研发过程中为了解决软件的复杂度，领域驱动设计（DDD）为我们提供了《统一语言（UBIQUITOUS LANGUAGE）》解决产品、项目中客户、运营、研发中思路，方向不一致的问题。在架构设计与架构演进过程中，正如《PPT架构师与写代码这件事儿》所描述的，团队人员对技术的理解也是不一致的。

综上，在软件研发过程中可能会遇到各种各样的认识不一致，思想不一致，方向不一致的问题。我们接下里说明在团队技术实现过程中的不一致问题。

意义

在软件研发团队中对于一项工作怎样算完成其实是没有完全定义的。在一些比较有经验的成员手中只需要说明一次既可以完成整体工作，在一些新手手中可能需要多次的说明，多次反复之后才能完成一项工作。再推广到团队，由组织合理，配合默契的团队完成一件复杂任务和组织不合理或配合不默契的团队完成复杂任务是需要更多的时间或者损失质量的。

并且在软件研发团队中人员的更替是在所难免的。人员变更给团队带来了不确定性，团队的完成任务的能力，团队完成任务的质量，团队的理解任务的方式等都会发生变化。所以，怎样保证保证任务的正常进展？成为一个比较重要的问题。

业界也有借鉴其他行业的很多经验，有很多方法将这些问题的成本降低到最低。例如：量化，Checklist，PDCA等等。我们这里说明软件研发的CheckList。

使用敏捷Scrum中的DoD概念，推广到软件研发中的各个过程中得到这里的完成准则。完成准则是为一项重复性事项创建的CheckList。在做某一项事项时需要检查列表中的内容，已确定是否真正的完成了工作。这里以代码提交的完成准则作为最简单介绍。

制作完成准则

完成准则最主要的目标是解决团队中遇到的问题。所以，制作完成准则需要注意的是需要团队所有成员参与。需要团队内所有成员的认同之后才能真正的推行。

具体步骤：
第一步：完成准则需要根据团队的问题，针对这些问题需要做问题调查。可以采用不记名投票的方式将所有的问题全部采集到一起。
第二步：针对这些已经采集到的问题，讨论是否有可以落地的解决办法，这些解决办法必须是可以操作与检测的。
第三步：按照重要性与优先级将解决办法排序到完成准则中。
第四步：申明《完成准则》是团队红线，这里已经达成对《完成准则》的认识，制定违反《完成准则》的惩罚。

以下为完成准则例子：

具体跟进

需要执行《完成准则》的惩罚，这样才可以让团队成员真正的认为完整准则的重要性。以及思想统一的认识。

参考：

Techniques for using the Definition of Done (DoD)
Definition of Ready (DoR) vs. Definition of Done (DoD)