怎样制定发布计划,处理固定价格的合同
一般来讲,制定发布计划是在尝试回答这个问题:“最晚到什么时 候为止,我们可以交付这个新系统的 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 秒钟总结:
测试驱动开发意味着你要先写一个自动测试,然后编写恰好够 用的代码,让它通过这个测试,接着对代码进行重构,主要是 提高它的可读性和消除重复。整理一下,然后继续。