有开始就有结束，万事有始有终。在敏捷开发中，完成定义的好坏不仅关系到团队的承诺是否实现，更关系到交付成功与否。所以在开始进入迭代之前，一般团队都会用一定的时间来做完成定义。
于我而言，在每次进入迭代之前我会在前一天或者计划会议上做完成定义的新建/回顾，确保团队对团队公约都已经明确了解，当然完成定义一定是其中必不可少的一部分。
一般来说对于迭代的完成定义有如下简单规则以供团队参考：
1、代码是否通过静态扫描
2、单元测试的覆盖率
3、用户故事的验收条件是否满足
4、是否通过产品负责人的验收
5、代码是否通过评审
6、一些非功能性的要求是否得到满足
7、回归测试通过与否
8、其它 - 主要指一些非软件产品的完成定义或者称为非功能性定义。
非功能性指的是，为满足业务需求除功能性以外的特性。包括系统的完整性、性能、可靠性、可维护性、可扩充性、安全性等。而非功能性完成定义即对于上面的非功能性需求的满足条件的具体描述。
但是团队公约并不是一开始就能尽善尽美的，是需要随着时间的推移对其进行修正使其符趋向完善。所以建立一个迭代的完成定义，对于团队来说是一项必须的工作。以下是我曾经带过团队的一个完成定义例子：
《团队名称》
目的：我们为迭代完成设定一个标准，使我们今后的工作能符合这个规范。
内容：我们认为我们和产品负责人汇报发布完成，那么其一定已经满足以下条件：
1、所有代码，上传前都经过代码互审。
2、所有代码已经上传到github服务器上，且通过代码静态扫描。
3、发布代码分支已经创建，编译通过。
4、编译后代码，在测试环境和预生产都通过通过自动化回归和手工回归无重大缺陷。
5、产品所有设计，在预生产环境都通过视觉还原。
6、代码通过产品负责人的验收且符合用户故事中的验收条件。
7、Scrum Master在团队发布完成后，会通过电子邮件告知相关负责人相关消息。其包括，版本信息，更新内容（新需求和缺陷修复列表）、发布时间、更新地址等信息。
（签名）
以上为今天所有内容，欢迎探讨。
网友评论