敏捷的本质
捷已经从一个宣言演变成为一项业界标准。
多数的软件厂商都在应用敏捷来解决瀑布式中导致的诸多问题。简而言之，使用固定时间长度的sprint来达成预先设定好的目标以及敏捷所主张的整个实施风格能够解决软件项目中痛处。因此，很多软件开发商都使用敏捷，并且通过做项目计划让他们的客户也参与到敏捷当中来。
敏捷是使用适应型生命周期来替代预测型生命周期。预测型生命周期预先定义和设计产品，它的目标是根据计划来实现设计。
那么，当无法对产品进行预测时，就可以使用适应型生命周期。在适应型生命周期中，它遵循一个反馈环，那就是先创建一个小的但可以使用的产品的子集，并通过对它们的使用获得反馈，然后根据获得的反馈设计和创建下一个产品子集。
如下图：
敏捷的两大特征：
1、增量交付
增量交付意味着你应该一步一步地创建产品的“可用”子集，而不是在项目结束时一次性交付。比如说一个软件系统：你可以拥有一个简单的版本，并通过每隔几周添加新特性来创建一个新版本(增量)。每个版本都是可用的，新的特性为用户/客户带来了更多的价值。而无法使用的可交付物不能创建所需要的真实反馈
预测型方法和适应型方法的不同
2、迭代开发 为了增量交付，你需要迭代开发，这意味着你应该重复开发过程。对于一个软件来说，你需要单独的设计、编码、集成和测试每一个产品的子集，而不是将所有的东西一起设计、一起编码，然后一次性集成(瀑布模式)。比如在建筑类项目当中有可能实现吗？你能在不设计建筑其余部分的情况下设计地基吗？不可能，因为在这一类产品中，元素之间存在不可避免的依赖关系。
敏捷项目管理是一种遵循敏捷宣言中传达的价值观和原则的方法，并遵循简短的开发周期是提供产品或服务的最有效方式的理念，因为它允许持续改进并且易于变更。
它使用的项目管理框架，
- Scrum（其中开发以递增和迭代的进度提供） 迭代开发。这是大多数软件开发过程的例程需要的图片，不管是不是敏捷的。在 Scrum 中，迭代校正 sprints，定义为 30 天。
- Kanban（高度可视化的调度系统）来执行项目。
- 短期会议固定的日常循环 下，每一位团队成员都回答三个问题：
- 上一次会议我完成了什么？
- 达到我的目标碰到了什么障碍？
- 下一次会议之前我需要做些什么？
Sprint backlog . 创建和管理一个sprint待办列表对售后和维护团队来说是全新的事物。基本上，它要求团队将所有的BUG或者问题的浏览一遍，这些所有的BUG和问题组成了产品待办列表，然后和product owner一起为这些BUG或者问题估算故事点数，最后团队可以根据这些BUG（也就是用户故事）来制定当前sprint以及以后的sprint的目标。曾经需要由经理或者lead来分配任务的团队，现在需要自己评审，估算，制定故事点数来管理BUG，然后再自己承诺在一个sprint中要解决的问题。
Scrum团队的动力 将开发团队、测试团队、客服团队和product owner放到同一个团队中也是一项挑战，因为通常遇到的情况是QA和product owner的人数不能和团队个数很好地搭配。
梳理问题 Sprint计划要求团队承诺在sprint中要完成的任务。这样就要求售后开发团队对待办列表进行梳理，评审，然后给每个用户故事指定故事点数，最后制定sprint中要完成的任务。这就意味着ScrumMaster要和团队一起，评审所有的BUG和对应的修复。这样的方法让团队能够在一起以有效的方式评审BUG，然后根据它们的复杂度给定故事点数。
有时限的sprint 在敏捷流程中，主张一个sprint应该有固定的时间限制，而且不应长于3到4周。对于支持和维护团队来说，由于每一个BUG的修复都需要在同一个sprint中由QA团队成员验证，否则团队在燃尽图中显示的速率将会降低，而这一切将是一个全新的理念。时间限制给团队带来紧迫感和设定目标的需要，否则将很难在售后的环节中实施敏捷。
QA和开发团队协作 在经典的瀑布式中，开发团队完成编码以后将移交给QA团队进行测试。敏捷将这一过程看作成整条瀑布的一小部分，敏捷要求QA在同一个sprint中完成对代码实现的验证以保证团队健康地持续运作。