你的位置:软件知识原创基地 >> 知识海洋 >> 项目管理 >> 详细内容 在线投稿

敏捷开发纵横谈

热度4308票  浏览2033次 时间:2009年12月04日 11:53


摘要
在IT界中,“敏捷”是一个很酷的词汇,“敏捷”的相关理论可谓铺天盖地。
“敏捷”一词实质没有统一定义,各家有自家的说法,本教程将让你了解“敏捷”的来龙去脉,抓住“敏捷”本质,并能在工作中实践“敏捷”。

特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。


大纲:
“敏捷”陷阱
为什么会有“敏捷”这个说法?
极限编程
敏捷开发
RUP
敏捷开发的实质是什么?
如何才能敏捷起来?

正文:

“敏捷”陷阱

小甲想到某开发公司应聘开发工程师,向该公司的某开发人员打听他们的开发方式。
小甲:请问贵公司开发模式是怎样的?
开发人员:咱们敏捷开发!不用写文档,写好代码就可以了。
小甲心想:哇,爽啊!赶紧去应聘!

小甲已经在该公司工作了数周,他觉得很郁闷:
无需求文档,要做东西都是口头分配的。
无计划可言,想到啥就做啥。
加班不在话下,返工是家常便饭。
这就是敏捷开发吗?

不少公司搞CMMI认证,推行过程改进,往往被开发人员嗤之以鼻,开发人员喜欢自由奔放有创造力的工作模式,喜欢敏捷!
然而很多号称“敏捷”的公司,其实只是手工作坊的工作模式,想到啥就干啥,如果你是开发人员可能还会好一点,如果你是测试人员、实施人员,在这样的公司你简直会觉得无法沟通无法工作!

到底什么是敏捷呢?如何才不会跌入敏捷陷阱呢?

为什么会有“敏捷”这个说法?

大学时我们就被灌输了这样的知识:
生命周期模型有瀑布型、喷泉型、迭代型、螺旋型等。
一般来说,大型的、复杂的、对安全要求高的系统,应该采用传统的瀑布型来开发,应采取重型过程。
对于中小型、需要快速投产的系统,应采用灵活的生命周期,采用敏捷的方式开发。

其实“敏捷”是相对于“重型”提出来的,重型开发有这样的特点:(摘自互联网)
1.刻板而严格控制。
2.很多活动和工件,官僚主义气息浓重。
3.文档繁多。
4.长期而详细的计划。
5.过程高于本质核心的工作。
6.面向过程而不是面向人,把人看成机械方法中的插件。
7.预见而不是适应。

于是我就很有疑问了,如果重型开发有这样的特点,那么请问:对于大型的、复杂的、安全要求高的系统,也需要用具备上述特点的重型过程来开发吗?如果是这样,谁愿意在这样的工作环境下工作?具备这样特点的过程对项目成功有什么好处?

“重型”的重要特点是呆板,因为大家不喜欢呆板,喜欢灵活,所以提出了“敏捷”的说法!
我猜想:
1.重型过程其实是一些没有实际项目经验的理论家搞出来的产物。
2.重型过程的出发点纯粹就是为了过程而过程。
当然上述论述纯属瞎猜,无法证实。

每个人对“重型”与“敏捷”的理解其实都不太一样,这里我用一个问题来测试一下你:
我国的航天事业取得长足的发展,让国人振奋,请问:你认为嫦娥工程采用的过程是重型的还是敏捷的?

这么重大的项目,很多人可能认为应该是重型过程,很多人可能认为敏捷的过程是不太严禁的过程,其实嫦娥工程是灵活而又十分严谨的工程。
大家有没有留意到我们火箭发射时间是如何预报的?是不是具体说某天某时某刻发射?
不是!而是说某段时间内择机发射!“择机发射”是多么灵活、科学、严谨的发射计划啊,完全与我们传统的计划想法不一样,难道你能说这也是重型过程吗?

所谓“重型”与“敏捷”其实都是相对的,我们没有必要去争论到底是“重型”还是“敏捷”。我们平时见到这么多“重型”“敏捷”的不同说法,其实大家都是各自从不同的标准出发。

下面我们将介绍常见的几种敏捷开发,每种理念其实背后的道理是很类似的,我们没有必要去争论哪种方式更好,你完全可以吸取百家所长化为自己的理念,按照你的想法将项目做好。

极限编程

极限编程英文叫:Extreme Programming,简称叫XP,最开始我接触到XP的说法时,还觉得是Windows XP的XP呢!

我第一次学习极限编程的最佳实践时,让我震撼不已,后来再工作中不断体会,有了自己的见解。我将这些最佳实践分为几类:需求、设计、测试、编码、项目管理。

需求方面的最佳实践:

1.客户故事:强调以客户的语言来表达需求。

需求分析有很多科学系统的方法,采用这些系统方法有时候往往不如使用最原始的土方法,就是用客户的陈述来表达需求!
极限编程认为,客户不能清晰认识自己想要什么是很正常的事情,项目组也没有必要成为业务专家,所以通过这两个最佳实践让客户来引导项目。项目的开发工作讲究短平快,系统会分为多个小版本发布,客户经过多个版本发布会逐步清楚认识到自己想要什么。

这个最佳实践鉴于我国的情况,其实是很难执行的。我们的项目一般合同价钱是签死的,项目时间也是死的,基本都没有机会让我们来回折腾,如果我们不能在项目初期精准地分析出客户真正的需求,项目失败的机会是非常高的。

我在实际工作中往往会通过用户故事来获取原始需求,然后对这些用户故事进行提炼,提炼后的需求再跟客户确认。我认为项目组还是很有必要成为业务专家,项目组中还是很需要有需求分析方面的高手,项目经不起折腾啊!

2.客户全程参与:强调从项目一开始到最后,客户应该与项目紧密联系,发挥更大的作用。

这个实践在实际工作中应该很好地贯彻,不要仅在需求阶段才让客户介入,客户最好就能常驻在项目小组内。下面有一些让客户多参与的建议做法:
1)需求阶段要与各用户反复确认需求。
2)系统做出界面时马上让客户看看。
3)项目计划要让客户知道。
4)每周向客户发送项目进展报告。
5)让客户参与测试软件。

设计方面的最佳实践只有一条:

1.简单设计:不用长远考虑,只要设计能保证当前功能可以实现就行。

软件开发的可谓千变万化,能将功能做出来的最简单设计就是最好的设计,你不需要考虑以后发生变化还能重用这些设计和代码,明天的事情鬼知道,搞定今天的事情就可以了!

这个实践有点剑走偏锋,有人还会因为这个实践不仔细思考软件设计就编码了,我们有很多项目因为设计得太烂而吃了不少苦头。实战简单设计时,我有这样的一些建议:
1)对于没有类似经验的项目,设计应该尽量简单,但简单的设计是需要严谨的思考得到的,你不要认为简单想一个设计出来就是简单设计。
2)思考项目设计时,应考虑有什么东西可以重用,同时适当考虑本项目有什么东西可供以后的项目重用。

TAG: 敏捷开发 项目管理
顶:285 踩:286
对本文中的事件或人物打分:
当前平均分:-0.54 (1261次打分)
对本篇资讯内容的质量打分:
当前平均分:-0.44 (1186次打分)
【已经有1290人表态】
262票
感动
143票
路过
110票
高兴
158票
难过
132票
搞笑
145票
愤怒
171票
无聊
169票
同情
上一篇 下一篇
软件知识大学