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