SCRUM的基础知识Scrum 是迭代的，增量型的流程。

Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。

Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。

在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。

每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。

在Sprint 的末期，团队将对这一阶段工作结果作——展示并取得相关的反馈，为下一Sprint 做好准备。

Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。

Scrum 中的角色在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。

产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。

在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。

产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。

开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。

Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。

团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。

开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。

开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。

团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。

团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。

ScrumMaster 的任务是以任何方式帮助整个团队取得成功。

ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。

协助团队会议，并支持Scrum 的实践。

在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。

一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。

ScrumMaster 和产品所有者不应是同一人；有时， ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。

不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。

除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经理。

他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum，他们为整个项目的开发提供知识，技术和各种必要的协助。

在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。

为了能更好地实现这一变化，经理们需要改进他们的管理方式方法。

SCRUM方法SCRUM方法的开发过程(1)计划和体系结构设计（确定性过程）将Backlog（急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等）按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。

建立系统体系结构（如为已有系统改进，则只作有限分析、调整），将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组（SCRUM 小组）,分配各小组合适的Backlog项或问题包。

建立开发运行环境。

(2)Sprint（经验性过程）该过程由若干个迭代的冲刺(Sprint) 活动组成，直至风险评估认为产品可交付为止。

一个Sprint是在限定时间段内（Sprint周期，通常为1~6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出）。

每个Sprint包含以下活动：*开发。

对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。

*打包(Wrap)。

封装packets,产生一个满足Backlog需求的可执行版本。

*评审（Review）。

所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue)及难点（problem）,增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。

*调整（Adjust）。

根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。

(3) 交付和巩固（确定性过程）一旦根据风险评估结果认为可交付产品时，即进入该阶段。

该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。

SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。

产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。

SCRUM对过程的管理：SCRUM的控制手段。

SCRUM提出了八个控制项（Controls）用于开发过程的调控，其中风险控制是首要的手段。

*Backlog。

*对象/构件。

*Packets。

* 变动（Changes）。

实施一个Backlog项时，对相应Packet的改动。

* 难点（Problems）。

实施一个变动时所必须解决的技术难点。

* 问题（Issues）。

涉及到整个项目或在Backlog项分解到Packet之前须解决的问题。

* 措施（Solutions）。

对问题或难点的解决，通常会导致变动。

* 风险（Risks）。

影响项目成功的风险，应持续跟踪评估并相应做出调整。

风险评估的结果将影响其他所有控制项。

SCRUM定义了六个概念性变量来用于风险评估：用户需求，时间压力，竞争，质量，远见（vision）和可用资源。

在SCRUM的各个阶段都使用这些控制项来评估和权衡，管理人员侧重于以此管理Backlog，开发组用以处理变动和难点。

所有人员一起来管理问题、风险和措施。

根据对控制项特别是风险的不断度量评估和权衡，一方面，计划和进度（在每个Sprint结束时）不断相应调整，保证实现产品的商务目标；另一方面，对开发中的工作任务Backlog动态地进行优先级排序，开发组总是先开发优先级最高的Backlog项，这样就保证了资源的最合理使用。

另外，SCRUM强调度量（采用标准功能点度量方法）的重要性，通过对每个Sprint中生产率等的度量，计划和进度将越来越趋于准确。

(1)项目组织。

项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。

设以下小组：* 项目管理组。

由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。

* 若干个SCRUM小组。

各小组由组长（SCRUM Master）领衔。

每个小组都是跨专业的（通常包括开发人员，文档人员，质量控制人员或用户代表等），通常为3~7人，以使小组内有充分的交流。

小组的划分最好是功能导向的（按所分配的问题包或Backlog），也可是系统层次导向（按体系结构中的分层）。

.在项目组人数增大时，可在管理组之上再设管理组（SCRUM of SCRUM）,从而使SCRUM 方法的应用到大项目中。

(2)Sprint期间的调控。

在Sprint期间，应使各SCRUM小组尽量避免外界的干扰（不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决），使小组成员专心于目前的工作，使他们工作在混沌的边沿。

为避免项目组在Sprint期间不陷入混乱，SCRUM采取两个措施:l SCRUM会议（SCRUM Meeting）。

对小组行为进行监控和刺激。

会议在Sprint期间每天在同一地点举行，由SCRUM Master主持。

会议上，SCRUM Master对每个小组成员提三个问题：1）昨天的工作进展如何。

2）有否遇到困难和障碍。

3）今天的工作打算。

会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。

*Sprint评审会议。

评审后根据对每人的工作成绩，进行相应的激励。

Scrum 启始Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision）。

这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。

这就是Product Backlog,它存在（并发展）于产品的整个生命周期。

Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs（“判断并修复定单流程中的错误”）。

Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。

在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。

只可以存在唯一一个Product Backlog；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。

Product Backlog 中的项目在规模上会相差甚远；有些大的项目通常在Sprint 计划会议上被划分为许多较小的项目，而小的项目有些会被合并为一。

关于Scrum 的误解之一是它会阻止你记录详细的规范说明；而现实中，这是由产品所有者和开发团队共同决定详细资料的多少，这些从其中一个Product Backlog 到另一个有可能存在不同。