敏捷-语录学习（1）

一、敏捷简介

1、敏捷开发方面的书籍

《Scrum敏捷项目管理》、《Scrum与企业管理》、《Scrum要素》、《敏捷回顾》、《用户故事与敏捷方法》、《敏捷估计与规划》、《Agile Development》、《敏捷软件开发》。

2、敏捷是一种策略，可以应用在很多方面。

在软件开发方面的话，有敏捷开发、敏捷测试、团队级别敏捷等。

3、敏捷是可以应用在大型组织（>500人）的。

二、敏捷历史

1、敏捷最开始还不叫“敏捷”，是叫“迭代和增量式开发”。

2、敏捷并不是在瀑布式开发方式之后，在最近才出现的。实际上，敏捷开发和瀑布式开发是同时产生并同时进行发展的，只不过在最开始出现软件项目危机的时候，瀑布式开发更加让人容易理解，所以才导致瀑布式开发更让人知道。

3、敏捷开发并不只是存在于互联网领域。比如，美国在1975年开始进行宇航飞船的研发的时候也是包含敏捷思想的。当时宇航飞船在研发过程时时间跨度大，需求也是在不断的更改的，这样的现象，如果按照瀑布式研发的话，就会出现很多问题。

4、瀑布式开发是怎么流行起来的？

当时有一个人写了一篇关于软件项目开发的文章，文章中的逻辑大概是下面这样的：

瀑布式开发就是按照“系统需求--软件需求--分析这个需求--程序设计--编码实现--测试编码--运营”这样一个流程。用这个流程来开发软件是存在很大风险的（软件做出来之后，已经没用途了）、注定也是要失败的。这样一步一步的进行，会发现这个过程永远都无法顺序的走下去。在编码实现过程中经常会发现程序设计有问题，测试编码的时候经常会发现编码实现有问题等等。

后面提出了“5步走”来解决这种现象：第一，一定要做好程序的设计。毕竟程序没有设计好就去开发势必会出现问题的，有很多需要注意的问题是需要事先就考虑清楚的。第二，一定要把这些设计记录下来，考虑到后面的维护和传承。这里有一点需要注意的是，这个“设计”是一种广义的含义，上一个步骤就是下一个步骤的设计。第三，建议把一个软件至少做两次。第一次以软件实现为目的把软件开发出来能够跑动起来。然后在按照规范把软件在做一次，相当于是重构一次吧。第四，一定要做计划，做控制，做测试。第五，在软件研发过程中一定要让客户参与进来，这样才能从客户的反馈中知道这个软件是不是客户想要的。

后来这个被绝大多数人误解成了后面的瀑布式开发，其实文章作者的本意不是这样的，关于这点，这个人的儿子后面出来澄清到他的父亲一直都是增量式开发的推崇者。瀑布式开发是不能工作的。

另外还与美国国防部（DoD）标准有关：

1980年代，美国是世界上最大的软件分包商，有大量的软件外包出去给其他地方的做。既然这样的话，很定是需要一些约束文档的。所以发布了软件开发或采购的标准，名为DoD-STS-2067，这个是基于瀑布模型和文档驱动方式（比如在进入开发时，所有的设计文档有没有全，这样的文档式驱动）。

1985年，一份针对国防部早期项目失败率的报告指出：在总值370亿美元的样本集中，失败或从未被使用过的项目占75%，只有2%的项目无需经过大量修改即可使用。

1988年，旧标准被更新为更贴合IID（迭代增量式开发）的2167A标准所替代。但最初始的单步瀑布图表仍在其中。

最后在1994年12月，2167A标准被MIL-STD-498替代。后面这个标准就描述了增量式版本。每个版本都实现计划功能的一个特定子集。每个版本都会重复所有流程步骤，而且及时在每个版本内，步骤也可以是重叠和迭代的。每次版本都是有些新功能的，都是可以运行的。

比如一个2年的项目，把它拆成8个版本，每个版本里面也进一步拆分成更小的版本，这样的话就可以形成“小步快跑”的节奏，可以不断的拿出新的成品给客户使用，为了迎合客户的要求，需求也不断的进行调整，通过这种滚雪球的方式，最终作出一款符合客户愿景的产品。

5、国外有人对高效研发团队作出了成功模式的总结：

（1）迭代式开发，而不是一次性闷头干到底（2）简单的组织结构，角色数量低于平均值（3）架构师也是程序员，不去做编码就不知道架构的出错地方（4）团队内高度口头沟通，而不是通过各种流程各种发邮件等，口头沟通也可以减少误解。每天都开一次技术同步及讨论会议（5）小型飞虎队先搭建出核心架构，然后在扩大团队。

6、为什么敏捷会流行起来

主要应对的事需求的变化。需求变化与项目大小是成正比关系的。项目越大，时间跨度大，这个时间过程中需求肯定是会不断变化的。

其实总的说起来，就是玩游戏一样，开发项目也要及时反馈。对！敏捷开发，其实就是可以理解为及时反馈～

7、做敏捷，不用犹豫

在国外谷歌、Facebook，国内的华为、海尔、联想、百度、阿里巴巴、腾讯、京东、点评，包括国外的美国国防部，都在用敏捷的思路。所以，不用考虑“要不要使用敏捷”，而应该思考的是“如何做好敏捷”。