《敏 捷 教 练：如何打造优秀的敏捷团队》—9.2 定义“完成”的意义

9.2  定义“完成”的意义

把团队聚集起来，一起商定“完成”的定义。从如下基本定义开始发起讨论。

“完成”意味着客户对开发出来的东西感到满意，而且所有的故事测试都通过了。

接下来问问团队，针对每一个故事，在认定它“完成”之前还需要执行哪些检查。鼓励他们参照自身经验，“完成”的定义要涵盖所有他们认为重要的检查。可以使用如下几条内容提示他们。

l  代码已经通过了团队中其他开发人员的评审。

l  代码有单元测试。

l  已经实现了故事测试的自动化测试。

l  团队中的测试人员已完成探索式测试。

l  用户文档已更新完成，记入了最新的功能。

l  已完成某个操作系统特定配置集的性能测试。

把他们各自的“完成”的定义都记录下来，写在白板上，让所有人都能看见。接着，和团队一块评审。还有什么别的事情必须在发布代码之前做完吗？认真听，留意他们是否假定了迭代结束之后还会做其他检查。问他们谁负责执行这些检查，很可能这些检查也应该被列入他们的“完成”的定义。等团队得到一份满意的“完成”清单后，鼓励他们醒目地展示到工作区里。

图9.1所示为一个团队的“完成”清单样例，它就显示在团队板上。我们可以仔细看看上面的检查项，即包括一些常见事项，例如测试和重构，还列出了源控制(source control)。通常，我们都不会把源控制列入“完成”的定义，但是这个团队需要让自己记住提交他们的诸多资产(图像、模板以及关键字数据文件)。开发人员用一头玩具牛的哞哞叫声庆祝每一次代码提交，作为一个信号，它提醒其他开发人员拉入最新的代码修改。对于这个产品来说，故事的“完成”也就意味着真的投产上线了。鼓励团队将功能切成片，这样就能在迭代中不断“完成”，而不是非得等到结束才能全做完。

图9.1  完成清单样例(Connextra，2002年)

选择什么时候和团队一起讨论“完成”的定义比较好呢？可以选择项目开始的时候，讨论完团队的工作约定之后，再继续讨论“完成”的定义。也可以晚些时候再处理这些细节，等到某个迭代团队没有做完所有故事的时候，再出手。团队兴许会在回顾会议上修订他们“完成”的定义，所以要有准备，它在项目期间是会演变的。

如你所料，“完成”的定义有些时候并不适用。探针是为了摸清需求或学习新技术使用方法而开发可抛弃代码的活动，它就不适合应用于“完成”检查。迭代规划会议时要提醒团队注意这一点，因为它会影响估时。

等团队明确了“完成”的定义之后，就注意观察他们是否很费劲地才能在迭代结束前完成故事。如果真是这样，就帮助团队找出瓶颈，并想办法改进他们的工作流。可以采纳看板方式，限制工作队列，并将其体现到团队板上。