•10万/100万/1000万代码行的项目有20%/48%/65%被取消（Jones, 1998）
•成功交付的产品中，约2/3延期交付（The Standish Group, 1992~2004）
•所有软件平均60%左右的功能从未或很少被使用（个人是PPT和Excel高手，但是发现： PowerPoint: 53/116用过，Excel: 51/132用过）
•约？%的文档内容在后来的维护、升级中从来没有被阅读过
•约？%的代码在后来被抛弃或重新编写
所以，若你能做到下面的工作，则能为企业提供难以想象的生产力提升：
1. 100%：若能避免100万行代码的项目不被取消，则生产率接近提升100%（因为原来有接近50%的可能性被取消）
2. 50%：若能避免无用功能减少一半，则生产率大约可以提升50%（若能彻底消除则接近100%）
3. 50%～1000%：若能避免代码被大量乃至完全重写，则生产率大约可以提升50%～500%（个人曾遇到13人编写9年的软件被1人编写1.5年重建）
4. 约10%：若只写有用的文档，则生产率可以提升10%以上
因此只是在站着开会、共同估算、每月反思、按优先级排序等等层面来推广敏捷是不行的，应该时刻注意上述效果是否达到。比如：
1. 我的项目整体的工期/成本策略是什么？我应该在哪些节点交付哪些功能来证明什么？
2. 哪些功能是客户最常使用的？（不要过度相信“现场客户”那个人，更应该多接触那个群体）
3. 竞争对手都做过些什么？哪些功能其客户评价高？哪些功能其实华而不实（而我们却以为是对方强项）？
4. 这个项目或产品的生命有多久？需要我们注意可维护行吗？要写点文档说明哪些无法从代码中看到的东西？（“给政府做个网站”和“新型4G通讯基站软件”的生命周期可相差10倍）
5. ……
掌握好这些事情之后，会发现人的积极性不但因受激励而提高了，产品的生命力也似乎提高了，很少走弯路。而最终表现结果就是生产率提高了。

本文来自CSDN博客，转载请标明出处http://blog.csdn.net/cheny_com/archive/2011/03/07/6228223.aspx
原帖地址：http://bbs.techexcel.com.cn/bbs/Agile%20Development/thread-228-1-1.aspx