十五、做计划
逐步完善计划
逐渐完善计划有非常多的优势
1）它可以最大限度地减少时间上的投资
2）它允许在最佳时机做决策——我们应推迟做决定，直到有一天，每个人都对项目有了更深入的了解
3）它允许我们改变路径——变化是必然的
4）它可以帮助我们避免落入相信计划的陷阱
不要用加班来赶计划
加班是项目严重问题的一个征兆
极限编程的规则很简单——你不能连续加两周班
1、历经挫折后才会明白
加班对速率的提升只能持续一个星期，后面逐渐下降，直到第四个星期，已经出现严重下滑
2、达到目标
按照可持续步调工作可以完成更多，胜过高速冲刺然后再恢复的方式
1）以可持续步调工作可以使你保留一些能量供真正需要的时候使用
2）它给我们留出更多保持创造性的空间
3）不要再说我们的大脑每天六个小时后就枯竭了
4）它值得一试
3、如果不加班，怎么办
加班是一个流行的工具，因为它便宜、简单、偶尔有效
项目中充满热情的人越多，团队就越有可能每天都充满能量
PO是关键，PO需要传达一个引人注目的产品愿景，让开发这个产品的团队满腔热情的工作
定时的短休，番茄工作法，每半小时左右就需要休息，如果不休息，你就会累，会精神不集中，会容易犯错，变得急躁，并出现意外
如果可能，支持改变范围
PMI铁三角
作为向Scrum转型的一个部分，项目关键的干系人、开发人员以及产品负责人需要学会把改变范围作为第一选择
1、考虑其他选择
1）牺牲质量？
降低质量是短视的，快速前进的最好方式是在开发过程中保持系统的高质量
尝试牺牲质量会导致一个更长的计划
2）增加资源？
向一个延迟的项目中增加人手，只能使它更滞后，项目越后期，增加资源越没用
3）延长期限？
可以解决问题，但是大多数情况，从商业角度看非常困难
虽然更改最后期限对开发团队来说是一个不错的、易于实施的选择，但它并不总是可行的
但是一旦可行，直接选它
4）调整范围？
丢弃一些需求，PO会失望，但不是世界末日
需要说服PO明白，完美的预测是不现实的
从商业的角度看，调整范围往往比延长期限好接受
2、项目环境是关键
不建议总是把缩小范围作为首选，但它往往更可行
如果一个产品必备功能不能够按时交付，有必要考虑延期交付
区别对待估算和承诺
1、用正确的数据来做
好的估算，需要知道两件事：工作的规模、团队的能力
速率：每个Sprint会完成产品Backlog的一些事项，把这些事项的故事点或者理想人天的估算做一个简单的加和，就是速率
首先尽量多收集以往Sprint的速率数据，接下来，利用这些排列好的速率来找到一个范围，得到置信区间，使用这个置信区间来预测我们按照给定日期可以提供多少功能
2、从估算到承诺
团队速率的置信区间
我们可以承诺从最高和最低箭头中间的某个值，这是一个最现实、最准确的承诺
建议先从靠近最高慢慢接近低点
3、历史估算是承诺的基础
1）团队从来没一起工作过
最好的解决办法是在做出承诺前，运行至少一个Sprint，并计算速率
计算初始速率只是第一步，可以使用直觉，把它变成一个范围，或许上下幅度25%
也可以基于其他团队来计算偏差，但团队最好有历史数据
2）团队规模频繁变动
停止改变团队，团队稳定有巨大的好处
收集数据，为团队改变做准备，并预测影响，团队改变的长期影响，一般发生在第三个Sprint
网友评论