敏捷教练修炼（一）、敏捷估算技法，一只妖孽的猴子

，你们自己看，到底谁在胡说，一目了然）
 
05团队速率（通常是实际完成的故事点）
 
06完成度（实际完成/计划完成）
 
07团队效率（完成故事点/团队容量，看得出一天他们完成了多少个点）
 
其实还有额外的指标，比如每个人的计划工作量，按道理来说，同工同酬，如果有些人拿着高薪不干活，这种人就应该就地解决。所以有了这种让人胆寒的指标。
 
要是对这些数字无感，那么把他们做一个简单的图表： 如果需要团队的绩效改进，最好能追踪团队的速率，如果呈缓慢上升，就说明团队在不停地改进，这个就是学习曲线理论。
 
三、管理客户需求
 
回到文中最初的那个问题，客户问，我的需求什么时间可以做好？回答这种问题首先要做好心里建设，如果没有图表，没有数据，那你需要一副处变不惊的厚脸皮，以及一副饱经沧桑的专家的模样：我想大概可能也许是3个月后吧。
 
此时客户不会掐死你，他们还需要你做交付，但是绝逼不会信你。客户关系为啥那么差，为啥？还不是因为你信口雌黄，天花乱坠，一簧两舌，轻若寡言，最终言而无信导致。
 
所以需要一个小小公式来建立起客户和你之间的信任，做好客户的干系人管理，也需要故事点管理。
 
比如针对上述问题，假设客户本身的需求有30个点，而排他前面的大概有100个点有待开发，所以你需要解决掉130个点的需求，才能认为客户的需求达成，那么怎么算时间？
 
假设我们2周一个迭代，而团队之前迭代中完成的平均速率为30个点，那么客户的完成时间有了没？大约4-5个迭代之后可以完成，也就是8-10周后可以完成客户要求。
 
我坚信这么一说，客户绝逼不会不信你的推断过程，不过他们会跟你搞为啥前面要等100多个点才能轮到他们… 所以摁下葫芦起了瓢，客户关系不是那么好搞滴… 
 
四、结语
 
敏捷项目的基于故事点的优点，至此基本都已经罗列：
 
可视化，可预测化统统因为有了故事点的存在而变得可落地而非纸上谈兵，这是项目管理的一个比较好的实践。
 
用数据说话，是最有力度的一种表达方式，而这个数据归根到底，离不开故事点的使用，并逐渐扩展到整个敏捷项目的各种管理细节。
 
目前的团队，已经不太能接受“人天”，比较前一段那种声嘶力竭，誓与“人天”共存亡的呐喊声，都转变成了“真香”的赞扬声。
 
改变，是不容易的，而跨过去，前面是片天…