硝烟中的 Scrum 和 XP（三）

怎样制定发布计划，处理固定价格的合同

一般来讲，制定发布计划是在尝试回答这个问题:“最晚到什么时候为止，我们可以交付这个新系统的 1.0 版本?”

定义你的验收标准

除了普通的产品 backlog 之外，产品负责人还会定义一系列的验收标准，它从合同的角度将产品 backlog 中重要性级别的含义进行了简单分类。

对最重要的条目进行时间估算

为了制定发布计划，产品负责人需要进行时间估算，至少是要估算在合同中包含的故事。跟 sprint 计划会议一样，这是产品负责人和团队协作共同完成的——团队进行估算，产品负责人描述条目内容，回答问题。

估算生产率

估算每个sprint的平均生产率——这就意味着我们要确定我们的投入程度。

假设我们决定了团队的投入程度是50%(相当低了，一般我们都是70%左右)，sprint长度是3个星期(15天)，团队是6个人。这样来看每个 sprint 都是 90 个人- 天，但是只能完整交付 45 个人- 天的故事(投入程度是 50%)。所以我们的估算生产率是45个故事点。如果每个故事的估算都是5天(实际不是)，那团队差不多就能在一个sprint中完成9个故事。

统计一切因素，生成发布计划

现在我们有了时间估算和生产率(45)，可以很容易的把产品 backlog 拆到 sprints 中:

调整发布计划

每个 sprint 之后，我们都要看一下这个 sprint 的实际生产率。如果实际生产率跟估算生产率差距很大，我们就会给下面的 sprint 调整生产率，更新发布计划。

结对编程

结对编程可以提高代码质量。
结对编程可以让团队的精力更加集中(比如坐在你后面的那个人会提醒你，“嘿，这个东西真的是这个sprint 必需的吗?”)。
令人惊奇的是，很多强烈抵制结对编程的开发人员根本就没有尝试过，而一旦尝试之后就会迅速喜欢上它。
结对编程令人精疲力竭，不能全天都这样做。
常常更换结对是有好处的。
结对编程可以增进团队间的知识传播。速度快到令人难以想象。
有些人就是不习惯结对编程。不要因为一个优秀的开发人员不习惯结对编程就把他置之不理。
可以把代码审查作为结对编程的替代方案。
“领航员”(不用键盘的家伙)应该自己也有一台机器。不是用来开发，而是在需要的时候稍稍做一些探索尝试、当“司机”(使用键盘的家伙)、遇到难题的时候查看文档，等等。
不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。

测试驱动开发(TDD)

下面是有关 TDD 的一个 10 秒钟总结:

测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。