敏捷开发说的很多了，我想和它那个酷酷的名字多少有点关系。如何实施敏捷开发，也要不少网文。而我非常想了解敏捷开发的真实缘由。我没有实施过，所以以下都是胡乱地猜想。
无外乎两种可能，一种是自下而上，内部自然形成雏形，后在书面规程上确定。另外一种是自上而下的。比如了解到敏捷开发的好处，领导就想尝试一下，要求下面去推广。
前者，有着很浓厚的个性或者是野性的色彩。要么是企业管理混乱，被迫依循着打到哪算到哪的思路，不断地迭代，不断地摸索。要么，就是团队能力特别强，已经可以丢开文档而能行如流水啦。不过无论如何，这时候，敏捷开发的雏形和一些自发的行为，都是由开发者从内心接受，并不断进化的。
而后者，就有点麻烦了。很多时候，一个舒心的项目，就等同于能在每个阶段里，把该做的都做好。例如需求分析的时候，踏踏实实地了解需求，写出一个清清爽爽，赏心悦目的文档规格书留给下一个阶段。我想，从软件开发诞生的那一天起，似乎人们就一直在追寻着这方面的最高境界。而一个拥有现代化管理的软件公司和其中的人，也会以此作为标榜。不过另类的极限，应该是从一个逆向的思维，挑战我们的极限的吧。但是下面的人都做好准备了么。举一个小例子，高度管理化的项目，都会尽量要求需求变动的前期发现。所以对以外包为主，也就是后期开发为主的公司来说，他们常常用需求变动的多少，来衡量做前期的责任和能力。而对于需求的大量变化的抗拒心理，也是当然的，因为这个会让人埋怨前期设计的人没有责任心，或者是大大抵消自己的成就感。可是在极限编程里，不仅不能去回避需求改变，还要尽量积极去促使它变化的更好。成就感，不在于明确的需求下的快速完美达成，而来自于最开始混沌的要求，通过不断变化而最终完美的过程。这两种的感觉是不一样的，开发者必须首先领会变化之美，领会驾驭之美，之后才能体会，锻造模糊需求的快乐，否则只会把自己的心情搞得一团糟。
说到这里，其实还是公司的事情触景生情。包括我，还有很多人还没有做好准备去迎接极限编程。所以，我倒是宁愿我的手下，之前都是在一个个混乱的项目中学会自己找寻出路，而不是在一个个一成不变的框架下，小心翼翼的做事。这样子，反而会更容易地接受极限编程呢。