敏捷开发入门教程

作者: 阮一峰

日期: 2019年3月 6日

敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。

但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。

一、迭代开发

敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发的方式。

那么什么是"迭代开发"呢?迭代的英文是 iterative,直译为"重复",迭代开发其实就是"重复开发"。

对于大型软件项目,传统的开发方式是采用一个大周期(比如一年)进行开发,整个过程就是一次"大开发";迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。

举例来说,SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发,它可能直到现在还无法上天。

迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能。通过频繁的发布,以及跟踪对前一次迭代的反馈,最终接近较完善的产品形态。

二、增量开发

迭代开发只是要求将开发分成多个迭代,并没有回答一个重要的问题:怎么划分迭代,哪个任务在这个迭代,哪个任务在下个迭代?这时,一般采用"增量开发"(incremental development)划分迭代。

所谓"增量开发",指的是软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。

举例来说,房产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼......每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶......

增量开发加上迭代开发,才算真正的敏捷开发。

三、敏捷开发的好处

3.1 早期交付

敏捷开发的第一个好处,就是早期交付,从而大大降低成本。

还是以上一节的房产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。

敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。

3.2 降低风险

敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。

请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?

对于软件项目来说,先有一个原型产品,了解市场的接受程度,往往是项目成功的关键。有一本书叫做《梦断代码》,副标题就是"20+个程序员,三年时间,4732个bug,100+万美元,最后失败的故事",这就是没有采用敏捷开发的结果。相反的,Instagram 最初是一个地理位置打卡 App,后来发现用户不怎么在乎地理位置,更喜欢上传照片,就改做照片上传软件,结果成了独角兽。

由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

四、如何进行每一次迭代

虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。

具体来说,每次迭代都必须依次完成以下五个步骤。

  1. 需求分析(requirements analysis)
  2. 设计(design)
  3. 编码(coding)
  4. 测试(testing)
  5. 部署和评估(deployment / evaluation)

每个迭代大约持续2~6周。

五、敏捷开发的价值观

《敏捷软件开发宣言》里面提到四个价值观。

  • 程序员的主观能动性,以及程序员之间的互动,优于既定流程和工具。
  • 软件能够运行,优于详尽的文档。
  • 跟客户的密切协作,优于合同和谈判。
  • 能够响应变化,优于遵循计划。

六、十二条原则

该宣言还提出十二条敏捷开发的原则。

  1. 通过早期和持续交付有价值的软件,实现客户满意度。
  2. 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
  3. 不断交付可用的软件,周期通常是几周,越短越好。
  4. 项目过程中,业务人员与开发人员必须在一起工作。
  5. 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
  6. 面对面交谈是最好的沟通方式。
  7. 可用性是衡量进度的主要指标。
  8. 提倡可持续的开发,保持稳定的进展速度。
  9. 不断关注技术是否优秀,设计是否良好。
  10. 简单性至关重要,尽最大可能减少不必要的工作。
  11. 最好的架构、要求和设计,来自团队内部自发的认识。
  12. 团队要定期反思如何更有效,并相应地进行调整。

七、参考链接

(完)

留言(58条)

可惜这个开发模式,不太适合为银行、运营商等机构开发移动互联网应用的产品。比较适合互联网公司这些允许 BUG “多一点点”,经常更新的系统。

感谢分享,通俗易懂!

出入职场,今天算是对敏捷开发有了比较深的了解了,之后不再排斥迭代的繁琐流程了。

具体实践操作就是:白天开会、交流,晚上撸码。。

赞一个,我们的禅道项目管理软件就是基于敏捷研发的。

引用不要问我从哪里来的发言:

具体实践操作就是:白天开会、交流,晚上撸码。。

哈哈哈,精辟

敏捷开发意味着需求的不断变更,不断的加班。。。。。

第四大点很重要,
实践操作: 变成产品经理的甩锅工具,需求任意改,还说是迭代

非常棒 。 看板管理 ,周会,晨会

持续交付,持续迭代,需求分析和设计才是关键

现代软件从 “购买产品” 到 “购买服务”,从“一次购买”到”订阅付费“,其实也是一种敏捷开发到体现。

引用bbb的发言:

可惜这个开发模式,不太适合为银行、运营商等机构开发移动互联网应用的产品。比较适合互联网公司这些允许 BUG “多一点点”,经常更新的系统。

合适啊。敏捷指的过程,不是结果。最终交付的还是那个产品。

这样子感觉增加了沟通的成本,对效率要求和对迭代功能的划分要求也很高。

“敏捷开发”的目的是要改善以往那种遵循“瀑布式开发”流程的产品最终接受率偏低的情况,付出的代价就是过程工作量繁琐了,开发效率降低了。不过,对于一个以产品为主的企业来说,“敏捷开发”的价值是比“瀑布式开发”大的多的。

这一篇能将敏捷开发落地,给阮大点赞

我们之前的是,早上搞一堆计划,一周搞一个会议,问进度

通俗易懂,连门外汉都看懂了!

我们的创业公司就是没有采取这样的敏捷开发,一次就想做到最完美,已经开发了8个月了,也只实现了各个板块的小部分功能。看了这篇文章深有体会,感受良多!

那我前两天写了个简易博客系统,算是敏捷开发的一次应用了(^~^)。写作它,虽然没有明确的规划、设计、编码、测试、评估等五步骤,但心中是有这五步骤的,或者说不经意间用到这五步骤。

很多公司在实践中都走了样,我理解是因为对敏捷开发的价值观和原则没有真正理解. 很多都是照葫芦画瓢....

大神,提个建议,能否考虑换下字体,某些情况下'0'和'o'无法分辨

一直知道这个方法,但是真的说不明白其中的原理什么的,看完了真是受益匪浅。3q

引用bbb的发言:

可惜这个开发模式,不太适合为银行、运营商等机构开发移动互联网应用的产品。比较适合互联网公司这些允许 BUG “多一点点”,经常更新的系统。

然后支付宝的装机量是所有银行APP加起来的10倍还多

请问敏捷开发和快速应用开发(rad)有什么关联?

真的非常感谢阮一峰老师!非常感谢!

觉得用房地产行业做敏捷的比喻不是很合适,哈哈哈,盖10栋楼,不是一栋栋来的,而是同时进行的

引用westlin的发言:

觉得用房地产行业做敏捷的比喻不是很合适,哈哈哈,盖10栋楼,不是一栋栋来的,而是同时进行的

是吧,不过意思还是讲得挺明白的,马斯克造火箭的例子倒。
其实呢,在项目管理中,项目被定义一次性、具有独目标的、独一无二的任务。

10幢的楼的开发显然是重复性的任务。例子改成10个任务独特的、快速迭代的、增量改进的一次性目标(王总说了先赚100万的小目标哦): 第1幢楼的目标为市场验证,第2幢楼加入节能环保设计,第3幢楼再融入智能家居....

如果10个任务都是一样的,那就直接批量生产的。第1幢楼目标是验证市场,后9幢批量生产

老师,我作为一个刚入门的小白。无意间发现您,真的是我的荣幸。感谢您用通俗易懂的话语让我很容易的明白。谢谢您。愿您以后生活幸福,天天开心。

你好,我想知道你这个网站主页的模板出吗?很喜欢

弱弱指出,这个说的更像是Scrum,最常用的一种Agile development methodology,不代表全部。

总结的简单明了,对于理解概念很有帮助。

非常感谢老师的分享!

迭代开发的周期2~6周;em....

简单来说就是用最短的是时间,开发一个粗糙的产品投放到市场,不断收集客户的反馈意见,然后逐步打磨产品,直到成熟稳定。

说的很棒,我们技术总监把敏捷开发说成了每个人都是全栈,完全牛头不对马嘴

我怎么感觉和建筑设计的过程这么像。。。

引用westlin的发言:

觉得用房地产行业做敏捷的比喻不是很合适,哈哈哈,盖10栋楼,不是一栋栋来的,而是同时进行的

恰恰相反,我们大昆明就有现成的房地产例子。同样在南市区拿下了一大块地。润城地产,优先引入名校,住宅区一期一期来开发,卖完一期才考虑下一期,到后期学校的学生出来了成绩不错,一期比一期火爆,甚至成功度过了公司在另一处房地产失败引发的资金链危机。另一家仁泽地产西南海,同样引入名校,但住宅区几乎所有地块全部同时上马(时间间隔不长),前期偌大一个工地,非常壮观,后来资金链断裂,整个盘全部被拖累,而且几乎所有地块都已经被使用了,大公司连来接盘的兴趣都没有,现在还在各方扯皮。作为成功的案例润城地产,前两期房子公认的质量一般,但后期的盘改进明显,现在看来,就是一个典型的敏捷开发成功案例。

没有具体的需求,一个大概的方向?算是敏捷开发吗?

引用gogogo的发言:

敏捷开发意味着需求的不断变更,不断的加班。。。。。

很对哎~ 我司就是敏捷开发
天天加班
需求根本停不下来
程序员 小哥哥 小姐姐 都累坏了

原来这就是敏捷开发 面试的时候 问我你们公司是怎么样的敏捷开发 ? 我一时竟答不上来
就是需求评审 开发 测试 部署 交付 反馈 说了下 哈哈

需求不明确就开始要开发,领导要求先上线,再修改。前端人员自己想UI
做好后再给到产品,产品参考着出UI,不满意的再修改,咋个搞哦

敏捷开发是每个阶段都要进行测试吗?

感觉敏捷开发变成加班撸代码的同义词了,可能真正敏捷的起来的团队很少吧

先把功能做上,后期再改,根本没设计,现在项目没人想维护了...

我以前所在的公司,有个老油条把变量名字乱命名一通,怎么简单怎么来,大小写混用。美其名曰,敏捷开发

很有效的方法论,总比做到最后推翻了更好。

引用bbb的发言:

可惜这个开发模式,不太适合为银行、运营商等机构开发移动互联网应用的产品。比较适合互联网公司这些允许 BUG “多一点点”,经常更新的系统。

你没有了解敏捷方法!迭代不是为了bug才迭代,相反敏捷开发里有许多最佳实践可以减少bug

容易理解

这个模式不太适合非资深的工程师,国外搞这个主要是因为他们正经开发流程已经很强大了,工程师进大厂小厂3年内各种格式规范,文档工具都是全标准化的。这个时候有人提出打破这个舒适圈,让更强的人加入到更快更强大的敏捷开发中,这个是能讲通的。

但中国,我觉得大家想太多了,真的,想太多了,基本面的东西就算大厂的人都不扎实,再敏捷只能是越来越不扎实,都变成百度那种白天开会写ppt,晚上写代码不睡觉的笨办法。

从纯银微博来的,了解一下什么是敏捷开发, 发现我们的日常开发就可以算作是敏捷开发。

引用amadis的发言:

第四大点很重要,
实践操作: 变成产品经理的甩锅工具,需求任意改,还说是迭代

敏捷开发还有最重要的一点就是和客户一起工作,对于程序员来说,客户就是业务员也就是产品。建议去看看经典著作。

敏捷开发有一个重点在于,代码大于文档,这篇文章也写出来了:软件能够运行,优于详尽的文档。

引用xx的发言:

先把功能做上,后期再改,根本没设计,现在项目没人想维护了...

评论好多人根本不懂什么事敏捷开发,建议让团队领导或者自己先去把那本书通读两遍吧

虽然之前没有认真研究过敏捷开发,但是好像很多工作都是这样实践的

引用薛才杰的发言:

赞一个,我们的禅道项目管理软件就是基于敏捷研发的。

不好意思,禅道开发团队极大的混淆了项目和迭代,导致使用体验极差。
可以多参考以下微软的TFS或者Jira

先抛一个问题:

举房地产的例子,如果我采用“敏捷”的办法盖房子,先盖好一栋,再盖下一栋,但等所有房子盖好才卖。
这个能叫敏捷吗?

敏捷的术,迭代和增量。
敏捷的道,快速进市场。

引用EvanHu的发言:

先抛一个问题:

举房地产的例子,如果我采用“敏捷”的办法盖房子,先盖好一栋,再盖下一栋,但等所有房子盖好才卖。
这个能叫敏捷吗?

敏捷的术,迭代和增量。
敏捷的道,快速进市场。

按照敏捷开发模式,应该是盖一层卖一层,一边盖一边根据市场需求修改建筑施工图纸

阮老师真的是绝了啊,10多年前在学校时,老师给的六字真言:小增量快迭代,在这里又看到了

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接