《硝烟中的Scrum和XP》第12章 怎样制定发布计划，处理固定价格的合同

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

• 有时候，一次只计划一个sprint中要做的事情会略显不足，我们还得提前多做些计划。尤其是签了固定价格的合同之后，我们就不得不预先计划了，不然就会有无法近期交付的危险

定义你的验收标准

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

1. 所有重要性>=100的条目都必须在1.0版中发布不然我们就会被罚款
2. 所有重要性在50-99之间的条目应该在1.0中发布，不过也许我们可以在紧接着的一个快速发布版本中完成这些
3. 重要性在25-49之间的条目也都是需要的，不过可以在1.1版中发布
4. 重要性<25的条目都是不确定的，也许永远不会用到

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

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

1. 让团队来做估算
2. 不要让他们花太多时间
3. 确保他们理解时间估算只是粗略计算，而不是承诺

估算生产率

• 假设我们决定了团队的投入程度是50%（相当低了，一般我们都是70%左右），sprint长度是3个星期（15天），团队是6个人
• 这样来看每个sprint都是90个人-天，但是只能完整交付45个人-天的故事（投入程度是50%）
• 所以我们的估算生产率是45个故事点

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

• 现在我们有了时间估算和生产率（45），可以很容易地把产品backlog拆到多个sprint

• 我们通常都会增加相当多的时间缓冲，以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。在这种情况下，我们可能会同意把发布日期定在三个月后，让我们“保留”一个月
• 我们可以每隔三个星期就给客户演示一些有用的东西，并在过程中邀请他们更改需求（当然也要看是什么样的合同），这很不错

调整发布计划

• 每个sprint之后，我们都要看一下这个sprint的实际生产率。如果实际生产率跟估算生产率差距很大，我们就会给下面的sprint调整生产率，更新发布计划。如果这会给我们带来麻烦，产品负责人就会跟客户进行谈判；或者swjg下是否能够在不违反合同的情况下调整范围；或者他跟团队一起找出一些方法，通过消除某些在sprint中发现的严重障碍，提高生产率或是投入程度

书

• 《敏捷估计与规划》