敏捷开发纵横谈

　　“敏捷”陷阱

　　小甲想到某开发公司应聘开发工程师，向该公司的某开发人员打听他们的开发方式。

　　小甲：请问贵公司开发模式是怎样的?

　　开发人员：咱们敏捷开发!不用写文档，写好代码就可以了。

　　小甲心想：哇，爽啊!赶紧去应聘!

　　小甲已经在该公司工作了数周，他觉得很郁闷：

　　无需求文档，要做东西都是口头分配的。

　　无计划可言，想到啥就做啥。

　　加班不在话下，返工是家常便饭。

　　这就是敏捷开发吗?

　　不少公司搞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.简单设计：不用长远考虑，只要设计能保证当前功能可以实现就行。

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

原文转自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html