Scrum master 成长旅程
2012-11-12
声明：本博客欢迎转发，但请保留原作者信息!
作者：[罗勇] 云计算工程师、敏捷开发实践者
博客：http://yongluo2013.github.io/
微博：http://weibo.com/u/1704250760/
一直以来，关于敏捷软件开发的书读了不少，但是一到自己亲自实施scrum 的时候感觉有些茫然了。不过我相信混乱应该是暂时的!
场景截取
在一天的站立式会议上：
张XX：“今天我完成了两个新的功能，#2345和#2341 不过就是还需要再做一下load 测试，这个应算是Done 了吧。今天我打算开始做那个比较简单的自动化测试脚本，预计需要4小时做完 ，噢 …”
李XX：“昨天A team 报过来先前做的那个功能#3457不会用，我临时补了一个readme 文档，就是简单描述了一下怎样使用这个新的功能,其他什么也没有坐 …”
PO:“哦，李XX昨天你不是说这个功能#3457已经做好了吗？怎么又在做？”
李XX：哦，我！@#￥@￥%
什么是DoD？
那我们先来看一下什么是DoD （Done of Definition），他应该是用来定义一件事情是否做完或者一个活动的完成的定义。用来帮助敏捷团队自我检查日常工作是否真正的完成，从小到说一个User Story完成的DoD；或者一个Sprint 完成的DoD，大到一次release 完成的DoD。要想高效并且高质量的完成软件开发工作，没有他还真的不行。也许，一个经验丰富的工程师知道一个user story实现完代码后要检查代码unit test 的覆盖率，记得写auto function test ，记得写简单的readme 文档，担是任刚刚进来的实习生就不知道了，有了清晰的DoD定义，加上严格的check，这样每个活动的结果就都有了保障，这样不至被优美的burn down chart 所欺骗了。
不同的层次的定义如下：
User Story
用于定义一个具体的User Story 完成检查列表。
- 验收条件已经和客户完成确认
- 新增代码已经审查通过
- 新代码已经集成到代码库，CI运行单元测试通过且覆盖率没有减少
- 功能测试通过，能自动化的用例已经自动化
- 实现技术方案已经记录到wiki
- 新增的用户使用手册内容已经准备好
Sprint
用于定义一次迭代完成的检查列表。
- 提交的 User Stories 点已经完成
- 没有阻止软件潜在可发布的issue
Release
用于定义一个产品阶段性release 完成的检查列表。
- 提交 Sprint 已经完成
- 通过所有的功能点客户验收测试
- 必要的性能测试，稳定性测试和健壮性测试通过
- 没有阻止软件发布的bug
- 代码库已经做好必要的tag
- 用户手册已经准备好
DoD对团队和项目的好处有以下这些方面：
为项目进度提供真实的反应
在很多缺少DoD的项目组，往往我们会被美丽的burn down chart 所迷惑，我们的勇士们的确是每天都报告了完成了多少多少的任务，哪些user story已经完成，直到最后那一天也就是要交付软件那一天，我们忘了写必要的文档，我们忘了写单元和集成测试，我们忘了给软件代码库在合适的点打上tag dengd，所有的这一切会打乱我们的计划我们会忙得不可开交！在每每交付的前一天我们得拼命的加班，我们很累很郁闷。在样的压力下，我们抛弃了单元测试，这个时候它已经不如按时交付软件重要，因此我们留下了新的技术债务！新的代码开发更容易引人bug。 有了合理的DoD，我们可以再日常工作的频繁的检查工作的完成情况，可以由scrum master每日站立式会议后花点时间逐个检查。所以的检查项都完成了才会修改对应的图表，这样burn down chart 就真实的反应了我们项目的进度了！
为团队提供了有价值的活动清单
当拿到一个新的用户故事，除了关注到工作如何去实现，我们还会更多的去考虑到可测试性可维护性等等对产品另有价值的活动。DoD 包含了一个简单的活动列表（设计，编码和单元测试，写必要的注释，集成测试，发布文档），确保团队把经历放在软件构件必须完成的任务上，同时减少了不必要的使得软件开发工作变得复杂的任务。
为拆分任务时提供指导和审计
有了这个活动列表，我们就可以这样依次的拆分user story 的任务。比如先是分析设计，编码和单元测试，集成测试再是编写必要的发布文档等。用它去检查我们的拆分是否有遗漏和疏忽，一般按这样下来八九不离十。
DoD应该是灵活定义的 随着时间的推移，或者不同的流程我们要灵活变动DoD的内容，比如一旦产品的CI平台建立，我们就可以为其添加一项：所有的代码必需要和其他成员的代码成功集成，并对应的测试代码检查也要通过才能算做完等！
总之，DoD不关系到具体的项目的验收功能点的内容，但是它是一份必要的，综合的活动完成定义清单。它包含了一系列有附加值得活动完成定义，用于确保软件质量而不是功能点。用于确保项目的完成真实反应了现实情况，她囊括了团队在不同层次（task，user story ，sprint 和 release）完成的活动定义。