什么是敏捷开发

敏捷的本质是什么？

“敏捷”一词实质没有统必定义，各家有自家的说法，本教程将让你了解“敏捷”的前因后果，抓住“敏捷”本质，并能在工做中实践“敏捷”。

“敏捷”陷阱

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

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

开发人员：我们敏捷开发！不用写文档，写好代码就能够了。

小甲心想：哇，爽啊！赶忙去应聘！

小甲已经在该公司工做了数周，他以为很郁闷：

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

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

加班不在话下，返工是屡见不鲜。

这就是敏捷开发吗？

很多公司搞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）思考项目设计时，应考虑有什么东西能够重用，同时适当考虑本项目有什么东西可供之后的项目重用。

测试方面的最佳实践：

1.测试驱动开发：先有测试再有开发。

咱们通常的顺序是先开发后测试，然则这个实践要求咱们先将测试想好，而后开发来知足这些测试。

这个思路其实就是目标驱动，咱们先假设软件已经作好，那么咱们先写出测试用例，而后咱们编写的开发代码应该能经过这些测试用例。这样思路的好处就是能让咱们想清楚目标，全部的开发都是有针对性的，减小无用功，提升工做效率，同时由于测试已经写好了，代码的质量会更加有保障。

这个思路实际上是至关优秀的，但这个实践多是这么多最佳实践中最难成功实施的！咱们公司曾经推行过一段时间，最终仍是失败了结。难以施行有如下缘由：

1）开发人员广泛没有这么高的编程素质。

先不说测试驱动开发，咱们每每连单元测试也作不到！测试驱动开发其实就是要求咱们先写出单元测试代码，而后再写出知足单元测试代码的代码。

2）编码是一个按部就班的过程，不太可能一开始接口就想好而且后面不会变了。

我本身编写代码也不太可能一开始就彻底想清楚类中的各个属性方法，有时候会以为方法名字很差会换掉，参数不太合适也会调整。若是咱们先写出测试的代码，其实就要求咱们先肯定各种名称以及各种的公开接口，但每每咱们须要不断调整，这样就会致使开发代码与测试代码都须要同时调整，工做量就增大了。

3）达不到自动化测试的技术层次。

自动化测试须要工具支持，并非全部公司都具有这样的条件。

测试驱动开发的意义仍是很重大的，我有这样的一些实践建议：

1）先写开发代码，而后写单元测试代码。

2）编写代码时，应该先想清楚类职责，类公开接口，而后再写具体实现代码。

3）某个类完成时或者阶段性完成了一些功能时，应该立刻写出相应的测试代码，并保证开发代码能经过测试。

4）若是不能针对全部类都写出测试类，那至少应该针对重要的、核心的、被使用次数多的类编写测试代码。

5）单元测试应该能作到自动化。

2.自动化测试：自动化单元测试、自动化UI测试。

自动化单元测试，目前不少开发工具都支持，技术上问题不大，问题大的是你们不去执行或者说是能力不够执行不了。

UI方面的自动化测试就有点麻烦了，有这样两点：

1）就算是比较好的自动UI测试工具，也难以捕捉到软件界面上全部的控件以及动做。

2）软件的界面常常调整是很常见的时间，界面不冻结，UI自动化测试步履维艰。

要推行100%的自动化测试难度仍是很高的，不过应该仍是尽可能自动化测试，单元自动化测试与性能自动化测试在技术上是没有问题的，是执行的能力与决心问题。

自动化测试这个最佳实践与测试驱动开发是紧密相关的，这两个最佳实践实际上是整个极限编程中最核心、最精彩、要求最严格的两个实践。只要将这两个实践作好，代码随便你改，只要能经过测试就行，不用惧怕需求变动带来的代码隐患，变就变，反正有自动化测试全面检查！

编码方面的最佳实践：

1）重构：不讲究一次将代码写好，但须要重构时应该绝不犹豫。

重构的意思是代码的接口和实现功能不变，但修改代码的具体实现，从而使代码的结构、可读性、性能、安全性等更好。

重构由于有测试驱动以及自动化测试这两个实践的支持，故不须要担忧重构带来的影响，万一重构失败，取回原来的代码即可。

2）结对编程：两我的，组成一对，共用一台电脑编程。

头次据说这个，还以为很难想象，两我的坐在一块儿，只用一台电脑，一我的写代码，另一个看，过一会两我的能够交换一下。

两我的一块儿写代码，至关于随时在作同行评审，彷佛效率下降了，但代码的质量获得保障，而且能保证全部代码至少有两我的了解的。

另外要注意的是：组成一对的两我的，应该水平至关。

这个实践颇有意思，不过每每也是很难实践的。

就我我的来讲，我就不喜欢两我的一块儿编程，我以为每一个人的思考其实很难同步的，每一个人都须要静下心来一我的思考问题，思考后才适合与别人讨论，若是思考过程也与别人在一块儿，很难想象这个思考能有好的效果。

咱们曾经将两位编码新手放在一块儿，让他们结对编程，尝试了这个实践，彷佛有一点效果，但咱们后期就没有再推行过。

3）代码共有：每一个人写的代码都是属于全体的，每一个人能够去改别人的代码。

这里强调共享与进步精神，欢迎互相研究代码，欢迎写出更好的代码，只要能经过测试就能够了！这个实践是依赖于测试驱动开发以及自动化测试这两个实践的，若是不能作到那两个实践，就不该该随便改动别人的代码。

4）强调编码标准

对于这点你们应该没啥异议了，如今有很多开发工具支持编码标准检查呢！

项目管理方面的最佳实践：

1.持续集成

持续集成与微软的“每日构建”是同样道理的，强调咱们的软件要随时处在能够编译经过能够发布的状态，持续集成让软件的问题提前暴露更快解决。持续集成须要必定的工具和管理措施支持，我有这样的一些实践建议：

1）代码的签入与签出要定下严格的规矩，如：天天工做前先获取最新代码，每次签入前必须先保证编译经过。

2）若是能作到测试驱动测试和自动化测试，那么还应该规定必须经过全部测试才能签入代码。

3）通常来讲咱们没有条件作到每日构建，也没有这么多工具支持，那么至少一周要编译一次内部版本，检查软件各部分的协调状况。

2.站立会议

天天早上项目组全体开5-10分钟会议，全部人站立讲话，简单讲述昨天工做概要、今天计划、须要别人协调或解决的问题。站立的目的就是让你们言简意赅，提升会议效率。天天开这个会，是保证你们有足够的及时的口头沟通。极限编程认为，口头沟通才是最有效直接的沟通。

在咱们的项目中，我也会推行站立会议，但不必定是早上，固然也不必定非要站立，可是会议必定必须是高效的！口头沟通颇有效，但必要的记录仍是应该有的。一些公司推行站立会议，每每是没有会议记录的。而个人作法是会议中若是有决定、有代办工做，我会要求记录下来。口头沟通算然来得直接，但容易理解错、容易忘记等缺点是避免不了的，应该辅以适当的书面记录。

3.小版本发布

分小版本屡次发布，最符合客户的利益，客户能够先使用部分功能，能够在此基础上更好地思考后续应该作什么。

小版本到底应该有多小呢？国外不少书会建议3个月，不过3个月对于国内的项目来讲，太长了！咱们常常要在很短的时间内作出一个大系统！

咱们公司每一个版本的发布周期之前大概是一个月，如今已经缩小到2-3周了。

4.每周工做40小时

加班是咱们IT人的屡见不鲜，极限编程反对加班！那么是否是咱们只要工做时间到了，哪怕不少事情没有作完，就直接下班呢？

这条实践的真正意思是咱们应该充分利用好工做的40小时，少作最好不作无用功，少返工。实际上咱们不少加班是由于咱们作了不少无用功、返工致使的。

人的脑壳天天能高速运转8小时其实已经很了不得了，若是还要加班，那么只能带来更多的bug，得不偿失！不过咱们不少公司的老板喜欢看到咱们这些打工仔忙，看到咱们加班，而无论实际的效果，这真是悲哀啊。

极限编程的各条实践是有关系的，我以为最基础的最重要的是测试驱动与自动化测试，这两条作不能作好，重构、代码共用等实践就难以实施。
极限编程不少东西很讲究灵活，但测试驱动这条是最死的要求最严格的，整个灵活的体系其实就是靠这一条来保证质量的。不少公司实践极限编程时，不能作到测试驱动，就简单设计，就随便改代码，随便因应需求变化而变更代码，这些工做都没有了质量保障的基础。

极限编程咱们须要总体来理解各条最佳实践，并根据实际状况加以调整，为我所用！

 

下面将会稍微简单一点介绍另外了两个比较常见的敏捷开发。

敏捷开发

有一种敏捷开发，就叫敏捷开发。你能够认为这种是“狭义”敏捷开发，而本文标题所说的敏捷开发是泛指全部带有敏捷特色的开发模式。

这种敏捷开发有这样的特色：

1.个体和交互赛过过程和工具。

以人为本，注重编程中人的自我特长发挥。

2.能够工做的软件赛过面面具到的文档。

强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

3.客户合做赛过合同谈判。

客户与开发者的关系是协做，不是合约。

开发者不是客户业务的“专家”，也不是为了开发软件，把开发人员变成客户业务的专家。

要适应客户的需求，就要经过客户合做来阐述实际的需求细节。

4.响应变化赛过遵循计划。

设计周密是为了最终软件的质量，但不代表设计比实现更重要。

要适应客户需求的不断变化，设计也要不断跟进，因此设计不能是“闭门造车”、“自我良好”。

要不断根据环境的变化，修改本身的设计，指导开发的方向。

你可能会感受到这些特色与极限编程的类似与不一样之处，同时你也会感受到这些特色不少与传统的重型开发针锋相对的。

RUP

统一软件过程，英文全写为：Rational Unified Process

要精确理解RUP的意思仍是有点难度的，简单谈谈我对RUP的理解。

按照时间顺序，项目分为初始（inception）、细化（Elaboration）、构造（Construction）、交付（Transition）四个阶段，
每一个阶段会有不少个小迭代。这四个阶段其实很难说有明显界限的，我以为你们大概了解每一个阶段的工做内容就能够了。

按照工做的性质，项目的工做能够分为如下几类：

商业建模（Business Modeling）

需求（Requirements）

分析和设计（Analysis & Design）

实现（Implementation）

测试（Test）

部署（Deployment）

配置管理与变动管理（Configuration & Change Mgmt）

项目管理（Project Management）

环境（Environment）

以上这些工做，在项目的不一样时期工做量分布是不太同样的，如：商业建模、需求这些工做每每是头大尾小，分析与设计、实现等是中间大两头小，项目管理、环境方面的工做一直都会持续进行。

RUP的思想打破了“需求-设计-编码-测试”这样的传统瀑布模式，需求、设计、编码、测试这些工做其实一直都在进行的，只是不一样时间比重不同。这个思想是很符合“敏捷”的特色，也和实际状况很是吻合。

你们理解这个意思后，我以为彻底能够按照本身公司的实际状况从新定义时间上的阶段，也能够本身从新定义项目的各种工做，以及思考各种工做在项目不一样时间的工做量分布。

关于敏捷开发的流派还有不少，如：自适应软件开发、水晶方法、实用编程等等，我觉不一样流派其实本质仍是很相似的，这里就不一一介绍了。

敏捷开发的实质是什么？

什么是敏捷？我想你们各有各的说法，我以为敏捷过程应该是这样的：

1.一个项目目标明确的过程。

2.有利于实现项目目标的事情，必定要作。

3.对项目目标没有帮助的事情，一概不作。

4.有效和高效是最重要的项目管理原则。

5.敏捷的过程是让人愉快、工做起来有战斗力的过程。

敏捷开发简单说就是有有效的办法去作有用的事情，过程的目的是让项目作得更好，不是为了过程而过程，不是用过程来“框死”项目，过程是为项目服务的。

各家各派的敏捷方法论，其实基本道理都是这样的，只是各自从不一样的角度来阐述如何作软件开发。咱们没有必要盲目崇拜某某方法论，各类方法论也没有必要PK，咱们应该集百家所长，为我所用！

如何才能敏捷起来？

有时候咱们会这样说：懒人会更聪明，由于他会想尽一切能够偷懒的办法。若是说，敏捷开发其实就是“懒人”想出来的，这样也不算奇怪。

那是否是咱们就能够作“懒人”了？固然不是了，若是你不足够聪明你就没有资格作“懒人”！

其实“懒人”一点都不懒，由于他的脑壳历来是不偷闲的，他的脑壳是很勤快的。

说了这么多，我其实想说的是：要敏捷，最关键在于多思考！

不要尽信各类敏捷方法论，你必须思考，必须能提出本身的疑问和看法，这样你才算理解这些方法论。

你须要多实践、多充实本身的知识，这样你才会有更多的思考本钱，更多的打仗用的武器。

你须要多总结，总结令人进步！

敏捷很容易，只要你开始思考如何让工做更有效，只要你开始改善你的工做方法，你已经开始敏捷了！