在软件开发过程中，经常会有这种场景：
项目经理问某个功能做完了没有？
开发人员说：差不多了。
项目经理接着问：什么时候可以做完呢？
开发人员说：明天可以做完。
项目经理：那后天早上就可以上线交付给用户了吗？
开发人员：那不行，还要交给测试人员测试一下。
项目经理：那么什么时候可以交付给用户呢？
开发人员：我不能确定。
在这里有一个核心问题：在软件开发过程中，什么叫做“完成”？
敏捷开发的核心价值观有一条：可工作的软件 胜过 面面俱到的文档。可工作的软件才能衡量项目进度，每个功能是否完成，需要以上线为标准。
但是在实际上，对于同一件事，每个人都会有自己的标准。如果团队中每个人的标准不一样，就会引起误解，造成信息上的不对称，影响协作效率。所以，作为一个团队，我们需要在完成标准（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%；
网友评论