昨。和一位同事，像敏捷的问题和需求文件，有一点争议。我结结巴巴，未能充分表达我的观点。回到他的想法整理，写下来。
首先要说的是，敏捷与需求文档的关系。
敏捷并不是排斥需求，它仅仅是给用户一个舒适地表述需求的环境。其实，敏捷相对于古老的RUP模式，更是把需求和測试抬到了一个前所未有的高度。
传统的软件project模式，想让程序猿介入，就要求先有明白清晰的需求规格书。经过多轮的评审确认，还要用户签字画押。
且不说『签字画押』给人带来的严重心理不适，就说这冷冰冰的需求规格书，就如冰封千年的雪山。横亘在用户与程序猿之间，上帝（用户）与我们（程序猿）的距离变得如此遥远，抱怨、指责、怀疑，不安，一切人类不好的情绪都会由此而引发……
并且。什么样的需求描写叙述是清晰明白的？每一个人都有不同的理解。
上帝： 我要个喝水的杯子。 程序员：高度为多少CM的杯子？口径多少？什么材质？奥氏体304？仅仅是用于喝水吗？水温多少？是否须要支持盛放盐酸？或者可乐？ 上帝： &%￥#…… 程序员：天啊？My God。 你连自己要个什么样的杯子都说不清吗？
敏捷过程要求用户与程序猿在同一个团队，共同工作（上帝与我们同在！从来没有谁能让我们如此接近上帝！
！
），上帝随时提出需求，我们随时给出响应。
上帝：我要杯子 ，于是就有了杯子； 上帝：杯子小了点。于是杯子变大了； 上帝：我要盖子。于是有了盖子。 上帝：杯子太素了，于是杯子壁上有了图案； 上帝：我要水。于是杯子里就有了水。
敏捷用UserStory来取代需求规格书。用即时反馈来取代评审。用讨论来取代签字画押。
敏捷是真正意义上以用户为中心的开发模式。
其次，我想再说的是敏捷与设计的关系。
传统的过程，我们在跋山涉水历经九九八十一难之后，最终完毕需求规格书的确认，还有，概要设计书、具体设计书两座大山横在面前。
但是，你知道吗？上帝已经等得有点不耐烦了。
敏捷也不排斥设计。但敏捷强调的战略设计。总体的架构，而不是战术战法。
战场情况瞬息万变，战术上的事情。交给现场指挥员临机应变就好了。
《45个好习惯》中说『程序猿不是打字员』，我是很赞同。
我从来不认可『软件蓝领』这种职业，软件行业，没有白领蓝领之分，仅仅有师傅徒弟。观点见我曾经的博文：http://blog.csdn.net/sharetop/article/details/2145572
敏捷过程强调高速开发高速迭代。并不是抛弃了设计，而是将一个原本独立的设计阶段，揉碎了，填充到开发的全过程中，让设计滋润着代码。让代码变得更有生机，设计也更接地气。
让设计浸润着代码。对每个程序猿都有更高的要求。所以，敏捷的流行催生了『全栈project师』的概念。
再分享《45个好习惯》中的观点：好的设计，是正确的，而不是精确的。
回忆我曾经的痛苦的RUP经历。用ROSE做具体设计，定义每个类，每个方法以及全部的參数……如此繁琐仔细的工作，需求一点点的变化。都可能会将全部的工作努力化为乌有。
最后。要说的一句话是：敏捷也并不适用于全部场景，比方你要做一个操作系统。
版权声明：本文博主原创文章。博客，未经同意不得转载。