一、敏捷开发简史
敏捷简史 1975-2010:
- 1957年,增量软件开发方法出现。
- 1975年,Fred Brooks 提出“No Silver Bullet”,出版《人月神话》,相关概念和内容已与敏捷方法极其类似。
- 1986年,竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发。
- 1993年,Jeff Sutherland在Easel公司首次将Scrum方法用于软件开发。
- 1995年,在OOPSLA‘95 会议上,Sutherland和Schwaber共同发表论文介绍Scrum方法。
- 1996年,Martin Fowler,Kent Beck,Ward Cunmingham将XP方法引入C3项目,是第一个被正式的XP项目。
- 1999年 Martin Fowler 著作《Refactoring: Improving the Design of Existing Code》出版,对敏捷开发中的“重构”实践首次进行系统化阐述。
- 2001年2月,由17位软件开发专家起草的敏捷宣言发表,敏捷联盟成立。
- 2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》
- 2003年,《Lean Software Development: An Agile Toolkit》出版,精益开发方法被业界广泛认知,并完善了敏捷方法。
- 2010年,ScrumBan(The first article on Scrumban)方法发表,综合了Scrum和Kanban
- 2010年,ThoughtWorks Jez Humble出版《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation》首次正式提出构建流水线(Build Pipeline)的概念,通过从根本上改变开发团队与运维团队的协作方式,达到敏捷软件交付,创造软件价值。
来自 csdn:敏捷十年简史回顾,我略有精简。csdn 这个链接地址已经失效。另外有效地址:有效地址。
二、敏捷宣言和12条原则
大家更为熟悉的应该是《敏捷宣言》。
2001年2月,Martin Fowler,Jim Highsmith 等 17 位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地,举行了一次敏捷方法发起者和实践者的聚会。
在这次会议上面,他们正式提出了 Agile(敏捷开发) 这个概念,并共同签署了《敏捷宣言》。
看敏捷简史我们可以了解到,虽然敏捷宣言是 2001 年提出,但它其实是对前面几十年软件开发实践探索的一个总结。
2.1 敏捷宣言
我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。
由此我们建立了如下价值观:
《敏捷软件开发宣言》:
个人和交互 高于 流程和工具
软件产品 高于 综合文档
客户协作 高于 合同协商
应变 高于 遵循计划
换言之,尽管右边各项也具有重要价值,但是我们更注重左边各项。
©敏捷宣言。2001 年。版权所有:Kent Beck、Mike Beedle、Arie van
Bennekum、Alistair Cockburn、Ward Cunningham、Martin Fowler、James
Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、Jon Kern、Brian
Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、Jeff Sutherland 和
Dave Thomas。
来自:https://agilemanifesto.org/iso/zhchs/manifesto.html
2.2 敏捷宣言遵循的12条原则
1.我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
2.欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
3.经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作,项目中的每一天都不例外。
5.激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
6.不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
10.以简洁为本,它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效,并依此调整自身的举止表现。
来自:https://agilemanifesto.org/iso/zhchs/principles.html
敏捷宣言和 12 条原则,都是很好的对软件开发过程有用的价值观。比如 1,2,4,5,6,10,11 等都是开发好软件必不可少的原则,都是我们努力的方向。
三、瀑布开发模型
瀑布模型(Waterfall Model) 是 Royce 在 1970 年提出的。它强调软件开发的一个完整周期。
瀑布模型将软件生命周期划分为 6 个阶段:
1.制定软件计划
2.需求分析
3.软件设计
4.程序编写
5.软件集成与测试
6.软件发布与维护
并且是自上而下的顺序,如同瀑布一样,开发步骤逐级往下流动。
瀑布模型把软件开发的各个阶段分解的很清楚很明白。
不论后来的什么开发方法开发模型,都是对这几个软件开发阶段进行优化。
早期软件功能不复杂,需求也比较简单,瀑布模型很实用。
随着时间发展,软件功能越来越复杂,软件协作人数越来越多,瀑布模型也暴露了一些缺点:
1.整个软件开发到最后阶段才能看到软件运行结果
2.各个软件开发阶段之间较少的反馈
3.有时客户也不能明确自己的需求,如果需求变了,那这种开发模式导致的返工量就比较大
后来又出现了原型模型、增量模型和迭代模型。
原型模型又叫快速原型模型,它是增量模型的另外一种形式。它是在编码开发真实系统之前,构建一个产品原型。现在是产品经理要掌握的技能。
在下面一节简要介绍下增量模型和迭代模型。
四、增量模型和迭代模型
4.1 增量模型
增量模型(Incremental Model),也叫增量式开发,增量是指在软件开发过程中,先开发主要功能模块,再开发次要功能模块,逐步完善整个软件功能。
增量式开发,就是把大型程序分解成若干个小的模块,然后对这些模块进行开发,最后把这些模块集成到一起,成为一个完整的软件。
现在用编程语言写软件基本都是用的这个方法。
有人画一张图来形象说明增量开发:
(来自:https://blog.csdn.net/chktsang/article/details/87010449)
4.2 迭代模型
迭代模型(Iterative Model),也叫迭代进化式开发。迭代模型把整个开发工作组织为有固定长度工期的小项目,被称为一次迭代。经过多次迭代完善整个软件。
每一次迭代都包括需求分析、设计、软件实现、集成与测试。这样开发工作可以在需求被完整确定前启动,因为有时候客户也不能明确功能需求。在一次迭代中完成系统的一部分功能,或业务逻辑的开发工作。再通过客户/用户的反馈来细化改进需求,进行下一轮的迭代工作。这个与瀑布模型是相反的,瀑布模型是计划整个项目,然后一次性开发完成。
迭代模型图:
迭代模型形象图:
(来自:https://blog.csdn.net/chktsang/article/details/87010449)