敏捷DoD完成定义的多种形态

作者:张克强    作者微博:张克强-敏捷307

关于Definition of Done 完成的定义
在以往的说法中,常见用 退出标准 , 完成条件,成功标准,等等
在敏捷软件开发中,存在多级的不同的完成定义。
典型的是迭代的DoD,这也是最初DoD应用的地方。
常见在Scrum中,需要预先定义DoD,常见的迭代DoD条款有:
1,所有完成的用户故事得到PO的验证
2,所有代码得到静态分析,纠正最高级别的不符合项,静态分析的规则参见...
3,所有新增代码得到人工评审
4,所有完成的用户故事都有对应的测试用例

而对于发布,一般就有更加严格的要求,发布DoD的典型条款有:
1,完成发布规划所要求的重点内容
2,通过发布的全量测试,回归测试范围是全范围,回归比率不低于50%
3,修复所有等级为1、2、3的缺陷,4级及4级以下缺陷不超过200个。1、2级缺陷必须修复,3级缺陷经过带缺陷发布审批后可以发布。

由于发布需要达到比迭代更高的要求,所以一般很难强制规定发布测试所需要的时间长度,也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上,因为高质量发布是第1要务,如果到了原计划测试结束的时间,仍然留有妨碍发布的缺陷的话,应当修复后才能发布。
而迭代成果一般是为了内部或者可控范围内的展示,相对发布而言,要求较低,所以适用时间箱方法,当然迭代本身就是时间箱,迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处,在这样的安排下,回归覆盖率就应当是一个变量,用于观察,而不应当是一个要求指标。

为了更好的达成迭代DoD,就需要提前注意,所以有些更加细节的DoD得到识别并使用。
最典型的是每日DoD,典型条款有:
1,搭建每日构建环境,晚上自动静态代码检查、编译、部署和测试,每日修复前一日构建和测试发现的缺陷和问题。
2,下班前必须检入当天书写的代码
3,当天的代码必须在当天或者第2天邀请同伴进行代码评审
4,搭建持续集成环境,当天上下午必须至少各检入代码一次(这与第1条可能冲突)
5,采用TDD,凡是检入的功能代码必须要有对应的单元测试(严格采用TDD)

还有针对用户故事(或者用例)的DoD,比如
1,用户故事最终的描述符合INVEST
2,用户故事得到测试用例的对应覆盖
3,用户故事得到对应的自动化测试用例
4,用户故事得到用户代表试用并初步认可

有少数组织考虑到测试集过于庞大,无法在1天之内测试完成,开展每周全量回归自动化测试,这样就有每周DoD,典型条款有:
1,上上周发现的缺陷是否解决
2,上周新增功能的自动化测试是否加入到每周测试集。





发布了154 篇原创文章 · 获赞 45 · 访问量 59万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览