敏捷流程，它是一系列价值观和方法论的集合。
完成敏捷分为三步：
1.找出完成产品需要做的事情－product backlog
2.决定当前的冲刺需要解决的事情－sprint backlog
3.冲刺。
冲刺期间，每天要开一个每日例会（Scrum Meet-ing），团队成员大多站着开会，所以又称每日立会。大家依次报告：
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时启动每日构建，让大家每天都能看到一个逐渐完善的版本。用简明的图表展现整个项目的进度，这个图最好放在大家工作的环境中，或者每天传达给各个成员：图表可以是燃尽图（Burn Down Chart，想象我们把一堆Backlog的木头给烧光）。
敏捷开发原则
尽早并持续地交付有价值的软件以满足顾客需求
敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
业务人员和开发人员在项目开发过程中应该每天共同工作
以有进取心的人为项目核心，充分支持信任他们
无论团队内外，面对面的交流始终是最有效的沟通方式
可用的软件是衡量项目进展的主要指标
敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
只有不断关注技术和设计，才能越来越敏捷
保持简明—尽可能简化工作量的技艺—极为重要
只有能自我管理的团队才能创造优秀的架构、需求和设计
时时总结如何提高团队效率，并付诸行动
敏捷的团队
软件开发流程有好多种，我们怎么衡量一个开发流程是否对当前的项目/团队合适？Scrum/Sprint能成功实施的关键在于Scrum Master。我听到有些团队也实施Scrum，但是他们随机挑一个成员来做Scrum Master，好像Scrum Master就是招呼大家开开会，记录每个人的进度而已。这种方法失败的可能性很大。一个好的Scrum Master能在两种语境（描述软件需求的商业语境，描述实现细节的技术语境）间自如地翻译和切换，事实上是一个强有力的项目经理（PM，参见本书“项目经理”一章）。如果团队还要求他/她做全职的开发工作，这样的人就更难找了。敏捷对团队的要求很简单：自主管理（Self-manag-ing）、自我组织（Self-organizing）、多功能型（Cross-functional），但是这很难做到。软件项目的团队各式各样，假设一个团队做得还不错，现在要变成敏捷流程，那团队要做下面的改变：
1. 自主管理： 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
2. 自我组织： 以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3. 多功能型： 以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要多次Sprint才能让Scrum走上正轨。换句话说，如果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么用不用Scrum都能写好软件！