古龙的武侠小说推崇快，其实开发也是以快为最重要的指标

从一个敏捷的讨论里联想开来

我的理解，敏捷，最原始的敏捷，其实就是：快速原型，迭代，激励
并没有什么吓人的东西，也不需要多少外部改造、准备
如果不刻意说这个词，很多平时效率较高的开发人员，其实都已经随时随地在贯彻它了
最近有文章的标题是：为什么5%的技术人员开发效率是其他95%的20倍？
我的感觉是，20倍可能有点夸张，3-5倍是常见的，也是可以解释的

 

“治大国如烹小鲜”的意思就是不要翻来覆去，锅里的小鱼经不起翻，国家的制度也经不起折腾
国家如此，公司、项目也是如此
不要试图一来就是一整套的改造、改制，而 非敏捷 的开发模式，基本上都是有一整套自己的模式、机制
因为它们多是以重型的文档为基础，不一整套推行，就很容易拉下文档，最后就是什么都没有
而一旦一整套推行，又很容易忽略了对历史、积累的理解和利用

敏捷的好处就是可以从小处开始，从个人开始
所以，不会对组织（公司、项目）有一个翻天覆地的影响，只是一种潜移默化

 

它的根本之处，其实就是符合了人性，所以才会有这么高的效率和评价
人，尤其是开发人员，都是急性子，总想最快看到效果，总想只做有效的事情（其它繁琐、机械的事情，最好有别人代劳）
敏捷的快速原型、迭代，就是很好地满足了这些奢望
所以，它与那些重型开发模式的重型文档、流程相反，它直接带给开发者的是惊喜、成就感：马上就看到自己的解决措施生效了！
而不是等到项目的最后完成，才收获这种惊喜、成就感，而这时已经时隔太远，而且概率不会太高

 

古龙的武侠小说推崇快，其实开发也是以快为最重要的指标。
当然，快首先是在同样的错误率的前提下的快，不但自己写的快，而且也能让别人理解的快，维护的快
当一个任务能以80%的时间完成的时候，你就有20%的时间可以重构、反思、总结，

结果，下一次的任务，可能就可以以60%的时间完成了，则你的反思、总结时间也就可以更多，
这样就是一个良性循环了。工作的成就感会越来越丰厚。
同样，反过来就是一个恶性循环的悲剧了。
快的另一个好处是，及时看到问题，而不是等很久。问题的早发现、早改进，代价是可以少很多的，也就是说你可以更快：节省更多的资源了。所以，本来也就快1、2倍的，加上纠错代价因此而减少，就成了：总体、最终的效率高3、5倍！

而在java这样的重型开发模式下，效率高20倍，倒也是可能的了。。。。。。。。