一、敏捷开发简史
敏捷简史 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 vanBennekum、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)