敏捷开发01：敏捷简史和几种软件开发模型

🕗 发布于 2024-11-26 03:27 敏捷开发研发管理研发流程

一、敏捷开发简史

敏捷简史 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 位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。

为什么会与这次会议：

因为当时的软件开发和软件项目管理出现了很多问题，也叫”软件危机“，主要有以下几个方面的问题：

1.项目经费总是超出预算

2.开发的软件不能满足用户的需求

3.开发的软件代码难以维护

4.开发的软件质量低下

这 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)，也叫迭代进化式开发。迭代模型把整个开发工作组织为有固定长度工期的小项目，被称为一次迭代。经过多次迭代完善整个软件。

每一次迭代都包括需求分析、设计、软件实现、集成与测试。这样开发工作可以在需求被完整确定前启动，因为有时候客户也不能明确功能需求。在一次迭代中完成系统的一部分功能，或业务逻辑的开发工作。再通过客户/用户的反馈来细化改进需求，进行下一轮的迭代工作。这个与瀑布模型是相反的，瀑布模型是计划整个项目，然后一次性开发完成。

迭代模型图：

迭代模型形象图：