Scrum学习笔记

1. 概述

Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。

它把开发组织成被称为Sprint的工做周期。这些迭代每一个都不超过4周（最多见的是两周），而且无间歇地相继进行。Sprint是受时间箱限制的，不管工做完成与否它们都会在特定日期结束，而且从不延长。一般由Scrum团队来选定一个Sprint的时长，而且对于他们全部的Sprint都使用这一时长，直到这个团队能力提升，可使用较短周期。

在每一个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择事项（客户需求）。团队对于在Sprint结尾他们相信本身能够交付哪些目标集合达成一致意见，这些交付应该是有形的而且能被真正“完成”的。

在Sprint过程当中不能够增长新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队天天都进行简短会面来检验工做进程，并调整后续步骤以确保完成剩余工做。

在Sprint结尾，团队与利益关系人一块儿回顾这个Sprint，并演示所构建的产品。团队成员从中获取能够结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工做产品。在软件领域是指已经集成的、彻底测试过的、已经为最终用户生成文档的、潜在可交付的系统。

 

2. 主要角色

2.1 Product Owner

• 肯定产品的功能，负责维护产品Backlog。
• 决定产品的发布日期和发布内容。
• 为产品的投资回报率(ROI)负责。
• 根据市场价值肯定功能优先级。
• 在每一个Sprint开始前调整功能和调整功能优先级。
• 在Sprint结束时接受或拒绝接受开发团队的工做成果。

产品负责人是一我的，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。

实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。

为保证产品负责人的工做取得成功，企业中的全部人员都必须尊重他的决定。任何人都不得要求团队按照另外一套优先级开展工做，团队也不容许遵从任何人带有威胁恐吓性的指令。产品负责人所做的决定须要经过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人尽心尽力，同时也使其成为一个费心费力但又值得去作的角色。

2.2 Scrum Master

• 保证团队资源彻底可被利用而且所有是高产出的。
• 保证各个角色及职责的良好协做。
• 解决团队开发中的障碍。
• 作为团队和外部的接口，屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。

Scrum Master 须要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。

Scrum Master 须要根据以上的状况更新反映天天完成的工做量以及还有多少没有完成的燃尽图（Burndown Chart）。

Scrum Master 还必须仔细考虑同时在进行开发的任务数，同时进行的工做须要作到最小化，以实现精益生产率的收益。

Scrum Master须要找出阻碍团队的障碍和依赖。他们须要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题能够在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。好比：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其余的全是公司的问题须要管理层关注。

最后但并不是最不重要， Scrum Master 可能会注意到，我的问题或冲突在Scrum里是须要解决的。这些都须要被澄清，或经过内部的沟通解决，或向管理层和HR寻求帮助解决。Scrum Master 必须注意去确保团队资源彻底可被利用而且所有是高产出的。

2.3 Team

1. Scrum团队的规模控制在5-9我的

   • 若是成员少于5人，那么相互交流就减小了，团队的生产力也会降低。更重要的是，团队在Sprint中可能会受到技能限制，从而致使没法交付可发布的产品模块。
   • 若是成员多于9人，那么成员之间就须要太多的协调沟通工做。
   • 大型团队会产生太多复杂性，不便于经验过程控制。
   • 对于大型项目来讲，能够采用多个小的Scrum团队，经过Scrum of Scrums解决团队间的沟通协调问题。

2. Scrum团队是跨职能的团队

   • 团队成员必须具有交付产品增量所须要的各类技能。
   • 团队成员经常具有如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。
   • 在Scrum团队中没有头衔的概念，每一个人都必须全力以赴完成Sprint目标。
   • 团队中不容许包括测试或业务分析等在特定领域工做的子团队。

3. Scrum团队是自组织的

   • 任何人，包括Scrum Master都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队本身肯定。
   • 每一个团队成员利用本身的专业技能，解决遇到的问题。这种协同配合提升了团队总体效率。
   • 团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会下降经过自组织而获取的生产力。所以，改变团队构成时务必要谨慎。

2.4 用户和利益相关者（客户，提供商）

3. 工件

3.1 Product Backlog

• 产品待办事项列表存在（并演化）于产品的整个生命周期，它是产品的路线图。
• 任什么时候候，产品待办事项列表都是“团队依照优先排列顺序完成工做”的惟1、最终的归纳。
• 一个产品只有一个产品待办事项列表，这就意味着产品负责人必须纵观全局作出优先级排列的决策，以体现利益相关人（包括团队）的意愿。

 

产品待办事项列表包括不一样种类的事项：

• 全新的客户特性（“使全部用户能够将书籍放入购物车”），
• 也有主要的技术改进目标（如“用Java代替C++重写系统”），
• 还有改进目标（如“加速测试”）、调研工做（“探讨加速信用卡有效验证的解决方法”），
• 还可能会有已知的缺陷（“分析并修复订单处理脚本错误”），
• 若是问题很少的话（若是系统有不少缺陷，一般就会有单独的缺陷跟踪系统）。

一个好的产品待办事项列表要作到：

• 粗细适宜的（Detailed appropriately）

优先级列表顶端的事项比低级别的事项更为精确和详细，由于前者要比后者先被开发。好比，待办事项列表顶端的百分之十可能包含很是小且分析得很详细的事项，而其余的百分之九十则不是那么具体。

• 估算过的（Estimated）

当前发布版本的事项须要有估算，并且随着你们了解得更多和新信息的融入应当在每一个Sprint中从新考虑这些估算。 团队提供给产品负责人产品待办事项列表中每一个事项的工做量估算和技术风险估算。 产品负责人和其余商业利益相关人提供产品需求的价值信息，其中可能会包括得到的收益、减小的成本、商业风险、对不一样利益相关人的重要性等等。

• 涌现式的（Emergent）

为了响应学习和变化，要按期梳理产品待办事项列表。 每一个Sprint，可能要加入、删除、修改、分解或者调整事项的优先级别。所以，产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或看法、竞争而致使的变化、出现的技术障碍等等。

• 排好优先级的（Prioritized）

在产品待办事项列表顶端的事项具备最高优先级，或者是从1开始顺序排列。 通常来讲，最高优先级别的事项应当最物超所值：高收益（商业价值）低花销（成本）。 提升某事项优先级的另外一诱因是在高风险来袭以前及早解决掉它。

3.2 Sprint Backlog

团队为每一个Product Backlog事项创建一个工做列表，有时由产品待办事项列表中的事项分解出的任务组成。或者当产品待办事项列表中的事项很小，只要几个小时就能实现时，就简单的由产品待办事项列表事项组成。

 

4. Scrum开发流程事件

4.1 Sprint计划会议

一般分红两部分：

1. 关于作什么

   • 参与者：产品负责人、团队、ScrumMaster
   • 长度：时间箱的小时数与Sprint的周数相等
   • 产品负责人和团队审视产品待办事项列表中产品负责人有兴趣在这个Sprint中实现的那些高优先级的事项。一般，这些事项应当已经在前一个Sprint中（的产品待办事项列表梳理会议里）被很好地分析过了，所以在这个会上只有较少的须要在最后时刻澄清的问题。在这个会议中，产品负责人和团队讨论产品待办事项列表中这些高优先级事项的目标和上下关联，让团队洞悉产品负责人的思想，关注于理解产品负责人想要什么以及为何须要它。

2. 关于怎么作

   • 参与者：团队、ScrumMaster、产品负责人（不强制参加，可是要能被找到来回答问题）
   • 长度：时间箱的小时数与Sprint的周数相等
   • 关注于如何实现团队决定要开始作的那些事项。团队预期他们在Sprint结尾可以完成多少事项，从产品待办事项列表的顶部开始（换句话说，就是从对于产品负责人来说最高优先级的事项开始），并依次查看事项。如下是Scrum中的关键实践：由团队决定将完成多少工做，而不是由产品负责人分配给他们。由于团队是基于他们本身的分析和计划，这使得预期更可靠。虽然产品负责人对于团队接受多少工做没有控制权，但他明白产品待办事项列表中的事项是从顶部开始拿取的，换句话说，就是先拿那些被他评为重要的事项。团队能够为列表中很后面的事项进行游说，这一般发生在团队和产品负责人发现低优先级的某些东西很容易并能够恰当地与高优先级的事项合并时。

4.2 产品待办事项列表梳理

概述 ： 为了未来的Sprint拆分大事项、分析事项、从新估计并重排优先级。

参与者 ： 团队；若是产品负责人是可以帮助梳理细节的专家，那么他会全程参与整个活动，不然他能够只参与其中一部分来设定方向或者重排优先级；其余理解需求并能给予团队帮助的人；Scrum Master将在会议的开始部分来指导团队如何有效地开这个会，不然的话他没必要参加。

时长 ： 一般来说很少于团队一个Sprint工做容量的10％，但有时对于“有大量分析工做”的事项来说要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。

4.3 Sprint评审会议

概述 ： 演示产品增量，而且在会议上对于功能性的产品增量进行审视并调整。它让产品负责人了解产品和团队的当前情况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前情况。

参与者 ： 团队、产品负责人、ScrumMaster。产品负责人能够邀请其余恰当的利益相关人参加。

时长 ： 时间箱为Sprint中的每一周对应一个小时。

4.4 Sprint回顾会议

概述 ： 针对流程和环境进行审视并调整。

参与者 ： 团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其余利益相关人，不然这些人不许参加。

时长 ： 时间箱为对应Sprint中的每一周为45分钟。

4.5 开始下一个Sprint

Sprint评审以后，产品负责人能够根据任何新的看法来更新产品待办事项列表，如添加新事项、删除过期事项或修改现有事项。产品负责人负责保证这些变化反映在产品待办事项列表中。

5. 其余

5.1 工做量估算

//todo

5.2 “完成”的定义

是全部代码被check-in就算故事作完了，或者是放到测试环境而且被整合测试团队验证过，才算是作完？

这一点是很是重要的，产品负责人和团队必須赞成，要對“作完”有一致的定义。

5.3 每日会议

概述 ： 在团队成员间更新信息和进行协调。

参与者 ： 团队必须参加；产品负责人不是必须的；ScrumMaster一般会在场，但要保证团队本身主持会议。

时长 ： 最长15分钟。

这是一个自组织团队互相分享目前工做状况的时刻，每一个团队成员一个接一个地向团队的其余成员报告三件事：

1. 自上次会议以来完成了哪些工做？
2. 在下次会议前有哪些工做会被作完？
3. 遇到了什么阻碍？

5.4 Sprint过程当中跟踪进度

Scrum中的团队是自管理的，想要作到这一点，团队必需要知道本身作得怎么样。天天，团队成员都会在Sprint Backlog上更新他们对还须要多少工做量来完成他们当前工做的估计。一个也很常见的作法是有人把这些剩余工做量加起来，而后在Sprint燃尽图上画点。这个图显示天天新的对团队完成工做所剩余工做量的估计。理想中，这应该是一条向下的斜线图，其轨迹指向Sprint最后一天没有剩余工做量的那一点。因此它被称为燃尽图。

 

6. 参考

1. Scrum Guide