昨日，与一同事，就敏捷和需求文档之类的问题，有一点小小的争论。本人口拙，未能完整表述我的观点，回来整理一下思绪，写下来吧。

首先要说的是，敏捷与需求文档的关系。

敏捷并非排斥需求，它只是给用户一个舒适地表述需求的环境。事实上，敏捷相对于古老的RUP模式，更是把需求和测试抬到了一个前所未有的高度。

传统的软件工程模式，想让程序员介入，就要求先有明确清晰的需求规格书，经过多轮的评审确认，还要用户签字画押。

且不说『签字画押』给人带来的严重心理不适，就说这冷冰冰的需求规格书，就如冰封千年的雪山，横亘在用户与程序员之间，上帝（用户）与我们（程序员）的距离变得如此遥远，抱怨、指责、怀疑，不安，一切人类不好的情绪都会由此而引发……

而且，什么样的需求描述是清晰明确的？每个人都有不同的理解。

上帝：  我要个喝水的杯子。
程序猿：高度为多少CM的杯子？口径多少？什么材质？奥氏体304？只是用于喝水吗？水温多少？是否需要支持盛放盐酸？或者可乐？
上帝：  &%￥#……
程序猿：天啊？My God。你连自己要个什么样的杯子都说不清吗？

敏捷过程要求用户与程序员在同一个团队，共同工作（上帝与我们同在！从来没有谁能让我们如此接近上帝！！），上帝随时提出需求，我们随时给出响应。

上帝：我要杯子 ，于是就有了杯子；
上帝：杯子小了点，于是杯子变大了；
上帝：我要盖子，于是有了盖子；
上帝：杯子太素了，于是杯子壁上有了图案；
上帝：我要水，于是杯子里就有了水。

敏捷用UserStory来代替需求规格书，用即时反馈来代替评审，用讨论来代替签字画押。

敏捷是真正意义上以用户为中心的开发模式。

其次，我想再说的是敏捷与设计的关系。

传统的过程，我们在跋山涉水历经九九八十一难之后，终于完成需求规格书的确认，还有，概要设计书、详细设计书两座大山横在面前。

可是，你知道吗？上帝已经等得有点不耐烦了。

敏捷也不排斥设计，但敏捷强调的战略设计，整体的架构，而不是战术战法。

战场情况瞬息万变，战术上的事情，交给现场指挥员临机应变就好了。

《45个好习惯》中说『程序员不是打字员』，我是非常赞同。我从来不认可『软件蓝领』这样的职业，软件行业，没有白领蓝领之分，只有师傅徒弟。观点见我以前的博文：http://blog.csdn.net/sharetop/article/details/2145572

敏捷过程强调快速开发快速迭代，并非抛弃了设计，而是将一个原本独立的设计阶段，揉碎了，填充到开发的全过程中，让设计滋润着代码，让代码变得更有生机，设计也更接地气。

让设计浸润着代码，对每一个程序员都有更高的要求，所以，敏捷的流行催生了『全栈工程师』的概念。

再分享《45个好习惯》中的观点：好的设计，是正确的，而不是精确的。

回想我以前的痛苦的RUP经历，用ROSE做详细设计，定义每一个类，每一个方法以及所有的参数……如此繁琐细致的工作，需求一点点的变化，都可能会将所有的工作努力化为乌有。

最后，要说的一句话是：敏捷也并不适用于所有场景，比如你要做一个操作系统。

关于敏捷的一些事儿