为什么要使用敏捷
1.敏捷Scrum框架
Scrum框架是在当今的软件开发界里面应用得比较广的一种框架，也是国内能看到的，大多数的敏捷在线项目管理工具的范本。
目前这个框架呢，有一个叫Scrum联盟的组织，在负责维护和管理。这个组织，每年会有一些认证，每年开一些会议，会定期地去更新这个框架。
Scrum框架的思想来源于一个著名的思想叫精益思想，这个思想是丰田在上世纪80年代提出来的。这个思想有两个重点，一个叫，respect people，尊重人；另外一个叫Continuous improvement，也就是持续改进。实际Scrum框架也是秉承的这样的原则。
三种角色
在Scrum这个框架里面我们会给团队分配这三类角色，第一类叫Scrum master，这是一个人；第二类叫产品负责人Product Owner；第三类叫团队，Team。
①Scrum 主管：Scrum master在这里不是项目经理的意思，他更像是这个团队的保姆，他要负责整个团队的鼓励工作，为团队服务，给团队提供理论支持，引导团队。更像是教练的一个工作。
②产品负责人：Product Owner是这个Scrum团队里边儿唯一一个经过授权的人，他负责的是整个产品。整个产品开发做什么，不做什么，哪一部分在哪个时间点交付的这个工作，也就是说，负责构建产品待办列表。
③开发团队成员：在Scrum里头，这个团队是近似于全功能的跨职能团队，其实敏捷对团队的要求是非常高的，这也是他成本高比较贵的原因之一。
三种工件
第一个工件，叫产品待办列表（Product Backlog），它其实有点儿像我们现在产品开发中讲的需求池的概念，通常来讲，我们会把所有需求一股脑的扔到这个列表中去，但是这个列表会有一个与传统的需求池不一样的地方。这个列表里面所有的需求，都是有价值的，有次序的。
第二个工件是冲刺待办事项(Sprint backlog)，通过我们价值的体现，包括我们对它的排序。我们就会得出这样一个结论，我们应该先做什么，后做什么。
第三个工件，叫潜在可交付产品增量，这个东西大致的意思是，我们在做产品的时候，是一个迭代增量的过程。
五个会议(事件)
①第一个叫Scrum计划会议，把产品待办事项列表里面的东西决定哪些可以在Scrum计划会议里边儿解决掉，做出冲刺待办列表。
②第二个会议，我相信很多的企业，很多的团队在做，叫做每日站会。
这个站会通常都问什么问题呢，我昨天做了什么，今天我要做什么，我遇到了什么问题，通常都是这样的对吧。但是我想告诉大家的是，大多数团队开这个会的时候，问的这三个问题都是不正确的，我们去看原文：
第一个问题：What did I done yesterday that helped the Development Team meet theGoal?
第二个问题：What will I done today to help the Development Team meet the Goal?
也就是说在敏捷开发这个环境里面，我们不会讲我做一件事情，做了百分之多少，在敏捷的世界里没有百分之几这个概念，它只有零和一。没完成就是零，完成了就是一。所以他的问题会说，我为了我们团队的目标，昨天做了什么；我为了我的团队目标，今天我要完成什么。
③第三个会议叫做Sprint评审，Scrum review。这个会议就是来评价你迭代的这个产品，是不是可以纳入到潜在可交付的产品增量，这还是个潜在的，还是不可交付的，经过了这个会，你能不能交付这个事儿就能定了。
④第四个会议叫Scrum回顾。希赛发过一篇文章，里面有一部分讲回顾（文章后附该篇文章的链接）。那就是敏捷回顾的一部分，叫做帆船工作法，或者帆船回顾，有兴趣可以翻回去看一看。敏捷回顾对敏捷这种活动来讲是非常重要的，应该说是在这几个敏捷Scrum的活动里面是最最重要。通过回顾，我们不但能够找到过去的一些缺点和失误，还能发现一些优点，并持续的改进下去，这对于敏捷团队尤为重要，为什么呢，因为敏捷这件事，第二个原则就是要持续的改进。
⑤第五个会议是一个持续的活动，这个活动叫产品列表梳理。说白了就是收集需求。因为敏捷相对于传统开发，这个需求不是那么稳定。但是我们讲拥抱变化，我们拥抱变化，不是为了让需求蔓延。拥抱变化，也不是为了让项目镀金，拥抱变化的意思是要让项目符合用户的价值，要让项目达成既定的目标或持续改变着的目标，我们要对这个需求做调整，这件事才叫拥抱变化。
SCRUM五条核心价值观
专注，公开，承诺，勇气，尊重。
1、承诺– 愿意对目标做出承诺
2、专注– 把你的心思和能力都用到你承诺的工作上去
3、开放– Scrum 把项目中的一切开放给每个人看
4、尊重– 每个人都有他独特的背景和经验
5、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
2.Stacey矩阵(Stacey模型)
这个模型能很好的告诉我们，为什么要使用敏捷去解决问题。
这个模型里面分四个部分，一部分叫Simple，just do it。第二部分叫Complicated，然后空白的部分叫complex，右上角那个我把它叫混沌，混沌的问题咱们不去讨论，实际上我们在软件开发里面，要做的事情就是三体里面讲的，叫降维打击。
在这个过程里，我们将复杂的东西划到一个相对简单的区域去解决。然而呢，对于一些很复杂的情况，比如说，我们需求很不确定，我们也不确定用什么方法去做这些事，我们就用敏捷方法去做。敏捷方法是什么呢，就是持续学习，持续迭代，持续规划这样一个方法。
这是一个实用的非预定义过程。
有同学问，敏捷项目和传统项目的区别，如何进行混合应用，相互取长补短？传统项目即预测型项目。
我们在预测性的项目里，做的事情是这样的。首先有一个发起人，然后我们做一个详细的计划，然后强制团队，或者说责令团队按计划去进行，然后在中间控制变更，按规定测试，结项等等，最后交付产品。
然而，敏捷不是这样的，一个敏捷软件的开发往往在敏捷初期，是不会预见到几个迭代之后的软件需求的。它往往是，以最小可行性产品，MVP，去交付给客户。也就是说我们用最基本的模型，最基本的能用的东西给客户去用，从而不断的得到客户的反馈，不停的迭代，改进，或者重构。这就是拥抱变化，或者叫检查和适应，敏捷和传统项目的一个比较好的区别的诠释。
所以敏捷，其实是一种轻量型的，最开始确实是用在软件上的，软件开发原则。它是一种方法，一种思想，是一种迭代的研发模式，而且是增量的，是一种一定时间盒的，以价值为中心的。
敏捷是一种适应复杂情况、不靠谱客户的，一种持续学习，持续增量的迭代模型。
敏捷有一个特别著名的东西叫做敏捷软件开发宣言，这个当时在2001年发布的时候，推动了硅谷的一个改革。
敏捷宣言里面提到了四点价值观，这四点价值观大家看看就行了。他最重要的一句话，尽管右向有其价值，我们更重视左向的价值。说白了就是，你一切从客户出发，一切从变化出发，一切从成果出发，一切从价值出发，比你那些花里胡哨，按规定来的这些东西，更有价值。
它是一种价值观，也代表了这一帮人的一种处事方式。
