Scrum 敏捷软件开发模型（不断完善中）

下面是我对于 Scrum 的学习、理解及总结，参考了 Scrum 指南和一些书籍，并加入了自己的一些理解，希望对自己有用。

Scrum 是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum 的三大支柱支撑起每个经验过程控制的实现。
第一大支柱是高透明度
高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明，而且那些被观察到的方面也必须被充分了解。这就是说，当某人检验某个过程并认为完成了某些任务时，这个完成必须等同于他们的完成定义。
第二大支柱是检验
开发过程中的各方面必须做到经常性的检验，以确保及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能允许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和勤勉程度。
第三大支柱是适应
如果检验员经检验发现过程中的一个或多个方面不满足可接受标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。
Scrum 中有三个进行检验和适应的时刻： 每日例会是用来检验朝向 Sprint 目标的工作进程，调整以优化次日的工作价值。另外，Sprint 评审和计划会议是用来检验朝向发布目标的工作进程，调整以优化下一个Sprint 的价值。最后，Sprint 回顾会议是用来评审完成的 Sprint，并确定什么样的调整可以使下一 Sprint 的效率更高、结果更令人满意和更易于工作。

Scrum 团队的目标是提高灵活性和生产能力。

敏捷价值观：

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

“敏捷开发”一词源自《敏捷宣言》。

Scrum 角色(Scrum Roles)：

流程经理(Scrum Master)：ScrumMaster 负责确保 Scrum 团队遵守 Scrum 价值、实践和规则；帮助 Scrum 团队和整个组织采用 Scrum；通过指导和引导，教授 Scrum 团队更高效工作、生产出高质量的产品；帮助 Scrum 团队理解并采用自组织和跨职能。

产品负责人(Product Owner)：产品负责人是管理产品待办事项列表、确保团队工作价值的唯一责任人。

团队(Scrum Team)：开发人员组成的团队负责在每个 Sprint 将产品待办事项列表转化成为潜在可交付的功能增量。

团队的 Team Leader 就是 ScrumMaster。团队的理想规模是7(±2)人。产品负责人和 ScrumMaster 这两个角色不计入成员人数，除非他们也是“猪”。Scrum 团队成员被称为“猪”。产品负责人是产品待办事项列表的“猪”。团队是 Sprint 任务的“猪”。ScrumMaster 是 Scrum 过程的“猪”。其他人被称为“鸡”。“鸡”没有权利要求“猪”如何去开展工作。

“鸡”和“猪”的比喻来自于以下的故事：
一只鸡对一头猪说：“我们合伙开家饭店吧！”猪想了想，说：“那我们给这个饭店起什么名字呢？”鸡说：“鸡蛋和火腿！”猪回答到：“那还是算了吧，你要做的只是下几只鸡蛋，我把命都搭上了！”

时间盒(Time-Box)：

发布计划会议(Release Planning Meeting)
目标	发布计划会议的目的是建立 Scrum 团队与组织内的其他部门能够理解和沟通的计划和目标。
主持人	产品负责人
参与者	ScrumMaster、团队全体成员
时间	通常不超过组织构建传统发布计划的15-20%时间
地点	会议室
准备	与 Sprint 计划会议相同
成果	发布目标 具有最高优先级的产品待办事项列表 重大风险 发布所包含的全部特性和功能 确立大致交付日期和费用
主要内容	发布计划会议需要回答以下两个问题：“我们如何以最佳方式将愿景转化为成功的产品？我们怎样才能达到或甚至超越客户的满意度和投资回报？” 与 Sprint 计划会议基本类似，只是范围不同，而估算也会比较粗略。
日程安排	没有既定日程安排，主要看产品的实际情况而定。
其他	定义验收标准时，可以根据重要性区分“必须发布”、“应该发布”和“可缓发布”等不同等级。 关于时间估算，应该对最重要的条目进行时间估算，应该由团队来做估算，估算只是粗略估算不是承诺，不要花太多时间。单位为故事点，具体可以参看 Sprint 计划会议部分说明。 关于生产率估算，可以参看 Sprint 计划会议部分说明。确定重要性、发布等级、时间估算、生产率估算后就可以排定发布计划，类似如下图所示： 其中生产率估算为 45 个故事点，每个 Sprint 的时间估算合计不超过该生产率估算。最后可以增加一些时间缓冲，以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。 关于调整发布计划，每个 Sprint 之后，我们都要看一下这个 Sprint 的实际生产率。如果实际生产率跟估算生产率差距很大，我们就会给下面的 Sprint 调整生产率，更新发布计划。如果这会给我们带来麻烦，产品负责人就会跟客户进行谈判；或者检查一下是否能够在不违反合同的情况下调整范围；或者他跟团队一起找出一些方法，通过消除某些在 Sprint 中发现的严重障碍，提高生产率或是投入程度。 组合使用 Scrum 和极限编程(XP)会有显著收获，Scrum 注重的是管理和组织实践，而 XP 关注的是实际的编程实践，它们解决的是不同领域的问题，可以