Scrum 学习笔记
罗朝辉(http://www.cppblog.com/kesalin)
敏捷火了很长一段时间了，但是一直没有机会实践，现在开始组队实践了，哈哈，先好好研习下规则~~
什么是 scrum
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个 Sprint，每个 Sprint 的建议长度2到4周。在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每个 Sprint 中，Scrum 开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint 中挑选的需求经过 Sprint 计划会议上的分析、讨论和估算得到一个 Sprint 的任务列表，我们称它为 Sprint backlog。在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。
敏捷价值观之敏捷四宣言
• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划
敏捷价值观之敏捷十二原则
• 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
• 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
• 项目过程中，业务人员与开发人员必须在一起工作。
• 要善于激励项目人员，给他们以所需要的环境和支持,并相信他们能够完成任务。
• 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
• 可用的软件是衡量进度的主要指标。
• 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
• 对技术的精益求精以及对设计的不断完善将提升敏捷性。
• 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
• 最佳的架构、需求和设计出自于自组织的团队。
• 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
Scrum 的特点
• Scrum 规定了一个非常简单的开发流程。
• Scrum 是现有设计流程的总结。
• Scrum 以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
• Scrum 是一个控制由利益和需求冲突导致的混乱的流程。
• Scrum 是改善交流并最优化合作的方式。
• Scrum 是一种检测产品开发和生产过程中障碍并将其去除的方式。
• Scrum 是最大化生产率的一种方法。
• Scrum 适用于单一的项目到整个企业。Scrum 可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
• Scrum 能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
Sprints
• Scrum的项目过程有一系列的Sprint组成。
• Sprint的长度一般控制在2-4周。
• 通过固定的周期保持良好的节奏。
• 产品的设计、开发、测试都在Sprint期间完成。
• Sprint结束时交付可以工作的软件。
• 在Sprint过程中不允许发生变更。
Scrum 框架
三个角色：产品负责人，Scrum Master，团队
四个仪式：Sprint 计划会议，每日站会，Sprint 评审会议，Sprint 回顾会议
三个物件：产品 Backlog，Sprint Backlog，燃尽图
Scrum 角色之产品负责人
产品负责人(Product Owner)的职责如下:
• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的 profitability of the product (ROI)负责。
• 根据市场价值确定功能优先级。
• 每个 Sprint，根据需要调整功能和优先级(每个 Sprint 开始前调整)。
• 接受或拒绝接受开发团队的工作成果。
Product Owner参与Scrum planning。
Scrum角色之 Scrum Master
作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。 他必须:
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
Scrum角色之团队
• 一般情况人数在5-9个左右
• 团队要跨职能(包括开发人员、测试人员、用户界面设计师等)
• 团队成员需要全职。(有些情况例外，比如数据库管理员)
• 在项目向导范围内有权利做任何事情已确保达到 Sprint 的目标。
• 高度的自我组织能力。
• 向 Product Owner演示产品功能。
• 团队成员构成在 Sprint 内不允许变化。
Scrum 仪式之 Sprint 计划会议
> 排列优先级：
• 分析和评估产品Backlog
• 确定Sprint目标
> Sprint 计划：
• 决定如何达到 Sprint 目标(设计)。
• 根据产品 Backlog 条目(用户故事，功能)创建 Sprint Backlog(任务)。
• 为 Sprint Backlog 中的任务做估算，用小时来计算
Scrum 仪式之 Sprint 评审会议
Sprint评审会用来演示在这个 Sprint 中开发的产品功能给 Product Owner。Produc Owner 会组织这阶段的会议并且邀请相关的干系人参加。
• 团队展示 Sprint 中完成的功能
• 一般是通过现场演示的方式展现功能和架构
• 不要太正式
• 不需要PPT
• 一般控制在2个小时
• 团队成员都要参加
• 可以邀请所有人参加
Scrum 仪式之 Sprint 回顾会议
• 团队的定期自我检视，发现什么是好的，什么是不好的。
• 一般控制在 15 - 30 分钟
• 每个 Sprint 都要做
• 全体参加：Scrum Master，产品负责人，团队，可能的客户或其它干系人
Sprint 回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。
Scrum 物件之产品 Backlog
• 一个需求的列表。
• 一般情况使用用户故事来表示 backlog 条目
• 理想情况每个需求项都对产品的客户或用户有价值
• Backlog 条目按照商业价值排列优先级
• 优先级由产品负责人来排列
• 在每个 Sprint 结束的时候要更新优先级的排列
Scrum 物件之 Sprint Backlog
Sprint backlog 定义了 Sprint 的目标，明确了 Sprint 过程中具体需要完成的任务。
管理 Sprint 的 backlog:
• 团队成员自己挑选任务，而不是指派任务
• 对每一个任务，每天要更新剩余的工作量估算
• 每个团队成员都可以修改 Sprint backlog，增加、删除或者修改任务
Scrum 物件之燃尽图(Burn Down Chart)
燃尽图直观的反映了Sprint过程中剩余的工作量情况，Y轴表示剩余的工作，X轴表示 Sprint 的时间。随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
扩展 Scrum
• 一般情况一个团队的人数控制在5-9人。大型项目可以采用多团队，通过team of teams来扩展Scrum。
• 影响扩展的因素：团队规模，项目类型，项目周期，团队分布。
• Scrum 曾被用于超过 1000 人团队规模的项目。