@(Diary)
谈谈今天读《构建之法》关于敏捷开发一部分时候的一些想法，因为还没做总结笔记，所以原文怎么说的也不引述了，就是讲敏捷开发虽然是挺棒的一种开发方式，但是它绝对不是万能的而且绝对不是代表了最权威，真正的项目开发，其特点千变万化，任务的变化造成解决任务的方法不能一成不变。
看起来，说了些有用的废话，因为任何人都知道，做事要灵活要因地制宜云云，但人们的大多数错误，往往都出现在这些重复最多的点上。
关于敏捷开发 agile，有两种追随者，一种是“原教旨”的 Agile 追随者，一种是实用型的 agile 追随者。前者按照敏捷开发设定的流程，严格执行，将敏捷开发奉为圭臬，变通视为错误。后者奉行实用原则，主体参考敏捷开发流程规范，细节上贴近实用。
不用我说，估计所有人都知道哪一种更优秀了，但是现实中，第一种人却存在着而且数量还不少。为什么会出现这么多第一种人呢，很简单，新人很多，没有经验。
每个人都当过新人，大概也都办过许多没经验的事情，新入职的成员，急于展现自己的才华，往往会将自己所学倾囊送出，这个时候，无力面对各种现实情况的新人，往往只好有板有眼的依照所谓规范来进行，因为他们心目中觉得，如果我严格按照这个流程规范来进行，应该是不会有问题的，而且即使出了问题，也应该和我执行这个规范无关。
现在我们回到这个敏捷开发的讨论上，敏捷开发固然好，但是有一些问题没有解决好，敏捷开发就会变成坏的开发。
- 敏捷开发只是优先级，而不是圣旨，严格按流程只会一团糟。
- 敏捷开发追求简洁的人际关系，可是在中国这样的环境下，将矛盾摆在明面上，可能会带来不小的麻烦。
- 敏捷开发的每日立会，讲了些什么，是毫无营养的过场，还是有真实用处的报告评估。
- 敏捷开发适用的项目，并非大型项目或者需要高可靠性的项目，比如火箭发射程序，因为敏捷开发容忍较多错误，这对火箭发射来说是致命的。
- 敏捷的方法只是帮助你更早的知道你能否如期完成任务，仅此而已，能实现快速的交付和反馈。
- 敏捷开发针对的项目，是人数不多，需求经常变化，可以容忍错误出现的项目，如果不满足以上，需要绕道。
说了这些，也都能看出来，敏捷开发绝非万能，不可轻信，唯一能解决问题的能力，是经验，而非这些规范或者是流程。
另外，为什么会有很多机构说，测试表明，敏捷开发是很有效果的。其实这叫Hawthorne 效应，例如你可以测试“给每一个程序员发毛绒玩具，然后测试劳动生产率”，你会发现毛绒玩具能提高劳动生产率，具体可参见 wiki 。中文名叫霍桑效应，简意是指那些意识到自己正在被别人观察的个人具有改变自己行为的倾向。
回到本文主旨，解决问题的办法，绝不是教条式的，书本上所能提供的仅仅是一种指导法，依照指导法原样进行基本上解决不了问题，真正需要的是相机而动的应变能力和足够强的洞察力，然后最最重要的，其实是经验，是从案例中总结出适合自己，具有更多应变能力的方式。
所以，想要走一条快速发展的道路，那就是尽早实践，多经历，多思考，如此而已。（写了那么久，好像最后说了一句废话。）
以上。
