Scrum敏捷开发实战分享（上篇）：方法介绍、敏捷团队和敏捷流程
一、方法介绍
先从一则故事说起：
一天，一头猪和一只鸡在路上散步
鸡对猪说：“嘿，伙计，我们合伙开一家餐馆怎么样？”
猪看了一下鸡说：“好主意，那我们给它取什么名字呢？”
鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”
猪说：“那不行，我要全身投入，而你只是参与而已。”
这是在Scrum推出的系列故事中最有代表性的一个故事，它向我们展示了两种角色：猪和鸡。
在敏捷开发中，Scrum是一种增量迭代式的开发过程，它包含了一系列的实践和角色定义的过程骨架；
主要角色包括产品负责人（Product Owner即PO）、敏捷教练（Scrum Master即SM）、开发团队成员等，他们在项目中承担实际工作，是Scrum团队中的核心成员，扮演着“猪”类的角色，是必须要全身心投入的；而用户、客户、老板们则代表着“鸡”类角色，他们是项目的需求方和参与者，不会为项目跟进的结果负责，但他们对产品的意见至关重要，因此也必须考虑到他们，这就要求PO和SM必须处理好两种角色的关系，这在实际操作中是最难的一个环节。
在正式介绍Scrum之前，我们先说下传统开发和敏捷开发的对比。
1.传统开发
传统的软件开发采用的是瀑布式开发流程，它把整个开发过程分成了需求、设计、编码、测试、发布等阶段，只有前面阶段达成后再进入下一个阶段，整个过程按照事先制定的计划前进。
这种预定计划的方法，带来的问题也是显而易见的，每个阶段之间都有强烈的依赖关系，前一个阶段被视为后一个阶段的输入，如果输入的质量不高则会严重影响后续阶段的输出质量，随即带来后续一些列阶段的停滞，最终导致开发周期拉长项目延期，甚至以失败告终；
我们的市场需求瞬息万变，很难实现产品需求明确完整的收集，项目早期的承诺也导致对后期需求的变化难以调整、代价高昂。
同时，技术的发展也日新月异，对于所定义的功能可能实现也面临着多重不确定性的因素，所以从需求的明确性和功能实现的确定性两个维度出发，当需求的不明确性和功能实现的不确定性均超出一定范围之后，呈现出复杂系统的特征，瀑布式开发这种结构化的方法便不再适用，而敏捷开发方法便是在这样的背景下诞生。
Fix Feature，Flextime（传统开发固定范围，弹性时间）
2. 敏捷开发
敏捷开发的一个核心思想的转换是，从瀑布式开发所代表的“Fix Feature, Flex time”（固定范围，弹性时间）转向“Fixtime, Flex Feature”（固定时间，弹性范围）。
Fixtime，Flex Feature（敏捷开发固定时间，弹性范围）
在市场变化和技术变化的背景下，既然市场需求和产品定义所代表的“范围”无法实现固化，因而无法确定应该投入多少资源来完成，那不妨固定好已有资源的，以资源位约束，实现“范围”的最大实现，从“计划驱动”转向为“价值驱动”。在敏捷开发的思维模式提出后，2001年，敏捷宣言诞生。
个体和交互 胜过 过程和工具
可工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
精益求精 胜过 简单执行
（注意：这里的胜过不是不要做，而是当两者出现冲突的时候，我们进行选择的判断依据）
对比瀑布式开发，敏捷开发更加贴近最终的市场环境，它有着更好的适应性，同时在敏捷宣言的指引下，更强调发挥人的价值，能更好的挖掘出团队的潜能。
敏捷开发充分发挥“人”在软件开发中的价值，强调追求有价值的产品结果，发挥每个人的主动性和创造力。
在敏捷宣言的指引下，产生了很多种敏捷开发方法，而冲刺和迭代式的“Scrum”方法，更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。
3. Scrum介绍
Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。
Sprint则是指竭尽全力的冲刺短跑，为球队争得利益，球队队员为一个整体，按照阵型发挥各自的价值，最终的结果取决于团队的配合和取胜的决心，而不是教练在场下的指挥。
