软件市场发展越来越迅速和成熟，传统瀑布式开发模式存在一定的限制，敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案，受到众多的关注。
定义：
理解：
- 首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
- 其次，敏捷开发都具有以下共同的特征：
1. 迭代式开发
2. 增量交付
3. 开发团队和用户反馈推动产品开发
4. 持续集成
5. 开发团队自我管理
- 最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。
具体方式：
上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？
Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。
我们可以简单的对比一下Scrum和XP：
1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；
2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。
敏捷宣言：
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
敏捷开发的12准则：
在敏捷开发中，我们遵循以下准则：
1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
什么是Scrum？
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程，通常用于敏捷软件开发。。原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。
评价：
很多觉得Scrum并没什么实质性作用，原因有这么几点：
1. 对于没有接触过Scrum的程序员来说，很难做到敏捷。
2. 用户故事的划分以及产品列表挑选最高优先级有点困难
3. 开发的过程中，团队中所有程序能够一直保持积极主动性很难把握
4. Scrum对于自组织的团队要求很高
5. 对于在实施Scrum的过程中，对于把握全局的master以及产品负责人的要求更高。
6. 能否在实施的过程中及时发现问题，及时解决问题
不可忽视Scrum作用：
1. Scrum团队总是先开发对客户具有较高价值的需求。
2. 更好的管理软件开发项目，它同样可以用于管理运行软件维护团队，或者作为计划管理，或者作为计划管理方法。
3. 提高团队的开发效率，降低项目的开发周期，最大限度的发挥团队的作用，更好的满足用户的需求。
优缺点：
Scrum的优点就是敏捷的优点，很注重实效，能更好的应对变化。
缺点是，他过于强调了人的自我管理。 有的观点认为，Scrum适用于一帮资深程序员组成的团队，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家缺乏能动性，没什么激情，很不适合Scrum。
还有一个问题，就是很容易不停的因为目标变化而重新设计，最终导致不能交付。
Scrum并不能保证项目成功，它只是给你更多的反馈，更多的可控性，让你更灵活的应对变化。在实际项目中我们应该对Scrum进行可适应性调整。
下面是《启示录》的作者Marty Cagan对敏捷开发的态度：P156,159
Scrum的详解【3355】
3角色
Product Owner：决定每个冲刺的任务，决定选择做什么和为什么做这些。
Scrum Master：Scrum团队教练和带头人，扫除实施障碍。
Team：是任务执行团队，可以是研发团队，也可以是跨职能团队，能够切实提供一个可用产品的团队。
3工件
Product Backlog：产品待办事项集合，我理解也是 用户故事，相当于当前版本所要做的所有需求。
Sprint Backlog：迭代功能开发列表，理解为一个冲刺目标阶段内的需求列表。例举如，当前版本总共要完成40需求，是我们的Product Backlog；我们把当前版本拆分4个冲刺阶段，即是4个Sprint。第一个Sprint需要完成10个需求，则这10个需求为当前Sprint的Sprint Backlog。
Burndown chart：燃尽图，确定需求实现阶段后，随时间往后推进，时间剩余消耗，同时任务列表也随工作的推进而消耗。即是，迭代显示剩余工作时间和任务的完成情况。
5价值观
Focus 专注：将故事拆解为冲刺阶段，目标细化，同时也是集中绝对的团队能力，解决既定目标，体现当前的专注，也排除其他插入时间的消耗。
Courage 勇气：在整个敏捷过程中，需要效率的提升，同时，面临的技术、环境、团队等一系列的问题并不会变少，就需要有勇气，有决断的阔步向前，用最优势的精力、资源解决当前最迫切的问题。
Openness 公开：团队内信息的完全公开，让问题无所隐藏，同时也让优秀和战绩能够很好地展示及引导，公开，从而大家平等，从而大家尊重。
Respect 尊重：在敏捷过程中，因为公开我们搭建了尊重的基础；同时因为效率的要求和冲刺任务的明确性，我们做自己最擅长的事情，从而让整体效率最大化。尊重他人，信任他人。
Commitment 承诺：构筑团队内部共同解决问题，最高效率突击任务环境，是因为我们信守承诺，敢于给出承诺；同时，也因为我们为别人为团队的承诺，我们必须是最好的处理我们的任务，对于我们承担的责任敢于承诺，也直面承诺的责任。
5工作
sprint planningmeeting：冲刺前计划会议，决定并生成sprint Backlog。---类似需求评审
sprint：冲刺，由冲刺会议决定了我们的目标，从而确定了冲刺的阶段，人员及任务安排。---类似于计划
daily standupdomeeting：每日站会，主要用于跟进进度，确定当前任务的情形，同时沟通是否有异常情况。要将异常在开始阶段进行良好控制。
sprint review：冲刺回顾。一个冲刺完成，对冲刺进行回顾，整理有益处，执行良好的部分；规划检查不好的地方，可以做的更好的方面。优化中不断前行。
retrospectivemeeting：回顾会议。完成当前版本，需要对整体进行回顾，对经历经验进行整理归档，形成有效的成长型文档，便于团队更好的成长。
Scrum过程
在我看来Scrum是一种轻量级的软件过程，它是一个项目管理框架。它是由一套关于项目的开发流程，开发维护人员沟通方法，各种最佳实践组成的。 一个完整的Scrum流程包括很多个Sprint（就是迭代），每个sprint在2到4周不等。
在项目开始时，将所有需要完成的工作列在一个Product Backlog中。
每次Sprint时：
1. 召开Sprint计划会议，在会议上产品负责人（Product owner）为Product Backlog中各项功能需求确定优先级。
2. 随后，开发团队“认领任务”，并把这些任务从Product Backlog中挪到Sprint Backlog中去。
3. 每天举行站立会议，参加人员Team Leader和Scrum团队，时间尽量短，15分钟即可。每个人回答3个问题：
a) 你已经做了什么？
b) 你即将做什么？
c) 你遇到了什么困难？
会议完后，相关人员可讨论遇到的问题。
4. 一个Sprint结束之后召开Sprint评审会议。会议主要展示本次迭代完成的原型，主要参与者包括所有对该产品感兴趣的人，可以是产品负责人，开发团队，客户等等，时间控制在两小时以内。
5. 召开Sprint回顾会议。会议由产品负责人、团队开发人员和Team Leader参加，总结本次迭代哪些做得好，哪些做得不好，团队在下一次sprint中要如何改进。