Scrum 学习笔记

Scrum 学习笔记

敏捷火了非常长一段时间了，可是一直没有机会实践，如今開始组队实践了，哈哈，先好好研习下规则~~

什么是 scrum
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包含若干个小的跌代周期，每一个小的的跌代周期称为一个 Sprint，每一个 Sprint 的建议长度2到4周。在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个依照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每一个 Sprint 中，Scrum 开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint 中挑选的需求经过 Sprint 计划会议上的分析、讨论和估算得到一个 Sprint 的任务列表，我们称它为 Sprint backlog。在每一个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。

敏捷价值观之敏捷四宣言
• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划


敏捷价值观之敏捷十二原则
• 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
• 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
• 项目过程中，业务人员与开发者必须在一起工作。
• 要善于激励项目人员，给他们以所须要的环境和支持,并相信他们可以完毕任务。
• 不管是团队内还是团队间，最有效的沟通方法是面对面的交谈。
• 可用的软件是衡量进度的主要指标。
• 敏捷过程提倡可持续的开发。项目方、开发者和用户应该可以保持恒久稳定的进展速度。
• 对技术的精益求精以及对设计的不断完好将提升敏捷性。
• 要做到简洁，即尽最大可能降低不必要的工作。这是一门艺术。
• 最佳的架构、需求和设计出自于自组织的团队。
• 团队要定期反省怎样可以做到更有效，并对应地调整团队的行为。

Scrum 的特点
• Scrum 规定了一个很easy的开发流程。
• 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 人团队规模的项目。