怎么建立DoD

在软件开发过程中，经常会有这种场景：

项目经理问某个功能做完了没有？

开发人员说：差不多了。

项目经理接着问：什么时候可以做完呢？

开发人员说：明天可以做完。

项目经理：那后天早上就可以上线交付给用户了吗？

开发人员：那不行，还要交给测试人员测试一下。

项目经理：那么什么时候可以交付给用户呢？

开发人员：我不能确定。

在这里有一个核心问题：在软件开发过程中，什么叫做“完成”？

敏捷开发的核心价值观有一条：可工作的软件  胜过  面面俱到的文档。可工作的软件才能衡量项目进度，每个功能是否完成，需要以上线为标准。

但是在实际上，对于同一件事，每个人都会有自己的标准。如果团队中每个人的标准不一样，就会引起误解，造成信息上的不对称，影响协作效率。所以，作为一个团队，我们需要在完成标准（DoD）上达成一致。

怎么达成一致呢？不是项目经理说了算，需要团队一起讨论，共同认可。下面介绍一个团队达成完成标准（DoD）的引导议程。

一、拿历史数据，展示当前的问题

常见有如下场景：

1、代码开发完成了，没有测试；

2、测试用例写完了，没有评审，提交bug后开发和测试互相扯皮；

3、任务完成了90%，用户故事才完成了10%；

4、需要交付时，才发现代码不能集成；

5、迟迟拿不出可工作的软件，不能达成迭代目标。

首先需要引导团队能够认识到当前的问题，以及当前问题对我们的迭代目标、项目目标的影响。在这里需要跟团队一起对齐目标。

二、和团队一起梳理，每个用户故事达到可交付状态，需要做的工作有哪些

在这时，引导团队成员各抒己见，每个人写报事贴，把自己想到的写出来，然后统一搜集后，进行分类整理，然后贴在白板上。

三、对贴出来的项依次讨论，确保大家能够理解一致

四、对贴出来的项进行投票，对于大家达成一致的项，选择作为我们的完成标准（DoD）。

依次引导后，得到如下的完成标准（DoD）：

1、代码提交到git，通过每日构建流水线；

2、代码静态扫描不包含bug和漏洞；

3、用户故事下有测试用例；

4、测试用例在tfs上有执行记录；

5、M1、M2、M3级别的bug已关闭；

6、后端代码单元测试代码覆盖率达到 50%；

7、自动化的验收用例覆盖率达到 100%；