硝烟中的Scrum和XP-我们如何实施Scrum 12)发布计划 13)组合XP _scrum

12 怎样制定发布计划, 处理固定价格的合同
一次只计划一个的事情会显得提前量不足, 提前做计划是个好习惯;
尤其是签了固定价格的合同之后, 不得不预先计划好, 防止无法按期交付的危险情况;
在制定 plan的时候尝试回答:"最晚到什么时候可以交付新系统的1.0版本?"
定义验收标准
除了产品外, PO会定义一系列的验收标准, 从合同的角度将产品中重要性级别的含义进行简单分类;
e.g.
1) 所有重要性>=100的条目都必须在1.0版本发布;
2) 所有重要性在50~99的条目都应该在1.0版本发布, 不过也许可以在紧接着的一个快速发布版中完成一些; [patch, 补丁]
3) 重要性在25~49之间的条目也是需要的, 不过可以在1.1版本发布;
4) 重要性
>红色表示必须在1.0版本发布黄色应该在1.0版本发布; 绿色表示可以以后再做;
应当尽量在最后期限之前能够发布红和黄的所有条目;
对最重要的条目进行时间估算
为了制定发布计划, PO需要进行时间估算, 特别是合同中包含的故事; 估算也应该是PO和团队一起完成的 -- 团队估算, PO描述内容, 回答问题;
如果时间估算和最后的结果有很大偏差, 那它的价值就打了很大的折扣;
1) 让团队来做估算;
2) 不要花太多时间;
3) 确保时间估算只是粗略估算, 不是承诺;

文章插图
通常PO会把团队聚到一个房间, 提供食品饮料, 告知团队目标是得出产品上前20个US的估算; [] PO先描述一边所有的故事, 然后团队开始工作, 而PO就在房间里回答问题, 解释需求范围, 使用"如何做演示"的方式描述有助于减少发生误解的情况;
会议的时间要严格控制, 防止团队把时间花费在少数几个故事上; 如果PO想花更多时间, 可以在安排会议; [] 团队必须保证PO认识到这些会议对当前的影响[消耗了当前的时间], 让PO理解时间估算这个动作本身也是有代价的;
e.g.时间估算结果:
估算生产率
现在对重要的US有了粗略的估算, 下一步是估算每个的平均生产率;
确定投入程度: 投入程度表示"团队有多少时间可以放在当前承诺的US上" 这个数字不可能为100% [除非机器人], 因为团队会把时间用于完成未经计划的条目, 切换环境. 帮助其他团队, 检查邮件, 修复电脑, 休息娱乐...
假定团队的投入程度是50%(一般为70%), 长度3周(15个工作日), 团队6人;
这样每个是90人/天, 能交付45人/天的故事, 估算生产率为45个故事点; 如果每个US的估算都是5天[纯理想情况, 基本不可能], 团队差不多能在一个完成9个US;
统计一切因素, 生成发布计划
有了时间估算和生产率(45), 可以很容易把产品放到中:
在不超出估算生产率(45)的前提下, 尽可能把每个填满US;
>大约要3个来完成所有"必须"和"应该"完成的US; 3个 = 9周 = 2个月; 是否是要向客户许诺的最后期限, 要看合同情况, 范围限制的严格程度而定; 通常的做法是增加相当多的时间缓冲, 避免糟糕的时间估算, 未预期的问题和未预期的特性造成影响; 这种情况下, 可能会把发布日定在三个月之后;
每隔三周就可以给客户演示一些有用的东西, 在过程中邀请他们提出/更改需求(按照合同而定);
调整发布计划
每个之后, 都要看一下这个的实际生产率; 如果实际生产率和估算生产率差距很大, 就会给下面的调整生产率, 更新发布计划;
如果不能简单得调整发布计划, PO就需要和客户谈判; 或者检查是否能在不违反合同的情况下调整范围; 或者和团队一起找出方法, 消除某些在中发现的严重障碍, 提高生产率或投入速度 [1)加人, 2)加班不过都是效率低下的办法]