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