敏捷开发纵横谈（1）——敏捷那些事儿

摘要： 在IT界中，“敏捷”是一个很酷的词汇，“敏捷”的相关理论可谓铺天盖地。 “敏捷”一词实质没有统一定义，各家有自家的说法，本文将让你了解“敏捷”的来龙去脉，抓住“敏捷”本质，并能在工作中实践“敏捷”。 大纲： “敏捷”陷阱 为什么会有“敏捷”这个说法？ 极限编程 RUP 敏捷宣言 敏捷开发的实质是什么？ 如何才能敏捷起来？ 我将分4篇为大家分享！ “敏捷”陷阱 小甲想到某开发公司应聘开发工程师，向该公司的某开发人员打听他们的开发方式。 小甲：请问贵公司开发模式是怎样的？ 开发人员：咱们敏捷开发！不用写文档，写好代码就可以了。 小甲心想：哇，爽啊！赶紧去应聘！ 小甲已经在该公司工作了数周，他觉得很郁闷： 无需求文档，要做东西都是口头分配的。 无计划可言，想到啥就做啥。 加班不在话下，返工是家常便饭。 这就是敏捷开发吗？ 不少公司搞CMMI认证，推行过程改进，往往被开发人员嗤之以鼻，开发人员喜欢自由奔放有创造力的工作模式，喜欢敏捷！ 然而很多号称“敏捷”的公司，其实只是手工作坊的工作模式，想到啥就干啥，如果你是开发人员可能还会好一点，如果你是测试人员、实施人员，在这样的公司你简直会觉得无法沟通无法工作！ 到底什么是敏捷呢？如何才不会跌入敏捷陷阱呢？ 为什么会有“敏捷”这个说法？ 大学时我们就被灌输了这样的知识： 生命周期模型有瀑布型、喷泉型、迭代型、螺旋型等。 一般来说，大型的、复杂的、对安全要求高的系统，应该采用传统的瀑布型来开发，应采取重型过程。 对于中小型、需要快速投产的系统，应采用灵活的生命周期，采用敏捷的方式开发。 其实“敏捷”是相对于“重型”提出来的，重型开发有这样的特点：（摘自互联网） 1.刻板而严格控制。 2.很多活动和工件，官僚主义气息浓重。 3.文档繁多。 4.长期而详细的计划。 5.过程高于本质核心的工作。 6.面向过程而不是面向人，把人看成机械方法中的插件。 7.预见而不是适应。 于是我就很有疑问了，如果重型开发有这样的特点，那么请问：对于大型的、复杂的、安全要求高的系统，也需要用具备上述特点的重型过程来开发吗？如果是这样，谁愿意在这样的工作环境下工作？具备这样特点的过程对项目成功有什么好处？ “重型”的重要特点是呆板，因为大家不喜欢呆板，喜欢灵活，所以提出了“敏捷”的说法！ 我猜想： 1.重型过程其实是一些没有实际项目经验的理论家搞出来的产物。 2.重型过程的出发点纯粹就是为了过程而过程。 当然上述论述纯属瞎猜，无法证实。 每个人对“重型”与“敏捷”的理解其实都不太一样，这里我用一个问题来测试一下你： 我国的航天事业取得长足的发展，让国人振奋，请问：你认为嫦娥工程采用的过程是重型的还是敏捷的？ 这么重大的项目，很多人可能认为应该是重型过程，很多人可能认为敏捷的过程是不太严禁的过程，其实嫦娥工程是灵活而又十分严谨的工程。 大家有没有留意到我们火箭发射时间是如何预报的？是不是具体说某天某时某刻发射？ 不是！而是说某段时间内择机发射！“择机发射”是多么灵活、科学、严谨的发射计划啊，完全与我们传统的计划想法不一样，难道你能说这也是重型过程吗？ 所谓“重型”与“敏捷”其实都是相对的，我们没有必要去争论到底是“重型”还是“敏捷”。我们平时见到这么多“重型”“敏捷”的不同说法，其实大家都是各自从不同的标准出发。 下面我们将介绍常见的几种敏捷开发，每种理念其实背后的道理是很类似的，我们没有必要去争论哪种方式更好，你完全可以吸取百家所长化为自己的理念，按照你的想法将项目做好。 请看下一篇…… 作者：张传波 创新工场创业课堂讲师 软件研发管理资深顾问 《火球——UML大战需求分析》作者 www.umlonline.org 创办人