Scrum学习总结

 

Scrum理念 - 透明/检视/适应

• 80%的价值来源于20%的功能；
  
• 快速迭代，增量渐近式开发；
  
• 早沟通，早反馈，早改进；
  
• 拒绝过度设计，过早细化；
  
• 适当设计和规划；
  
• 一次做一件事；
  
• 一次做完一件事；
  
• 共识重于管理和监督；
  
• 自组织，自适应；
  
• 计划-执行-检查/反馈-行动；
  
• 聚焦团队而非个人；
  

 

Scrum 价值观

• 承诺 - Commitment
  
• 勇气 - Courage
  
• 专注 - Focus
  
• 开放 - Openness
  
• 尊重 - Respect
  

Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于Sprint 工作和 Scrum 团队的目标。Scrum 团队及其利益攸关者同意将所有工作和执行工作上的挑战进行公开。Scrum 团队成员相互尊重，彼此是有能力和独立的人。

 

Scrum团队

Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。

Scrum 团队是跨职 能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。

 

团队的特性：

• 目标一致
  
• 信任；
  
• 自主，独立
  
• 追求卓越，拒绝平庸
  
• 多功能，跨职能，扁平化
  
• 激情，高效
  

 

产品负责人(Product Owner)：做什么，价值和目标

产品负责人的职责是将开发团队开发的产品价值最大化。

产品负责人负责与客户沟通，确定产品需求，制定/评估/更新产品待办列表。产品负责人是负责管理产品待办列表的唯一负责人。负责向团队解释/澄清所有的功能和价值，确保团队对产品的一致认识和目标。负责确定产品待办列表优先级和价值。

产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。

 

开发团队：怎么做

开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和效用。

开发团队规模一般控制在3-9人。

 

Scrum Master：跟踪过程，清除障碍

Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。

他服务与开发团队和产品负责人。负责跟踪整个阶段，发现困难并清除，解答团队的疑惑并指导。

把控开发节奏，保证开发效率。

 

Scrum Master 服务于组织

Scrum Master 以各种方式服务于组织，包括：

• 带领并作为教练指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
• 引发能够提升 Scrum 团队生产率的改变；以及，
• 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

Scrum事件

所有事件都是为了完成一个Sprint - 冲刺。

Sprint规划会议

• 本次Sprint需要做什么？
• 怎么完成？
• 本次Sprint的目标是什么？

每日站会

15分钟。全员。回顾/检视/改进，发现问题并解决。

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

Sprint评审会议

Sprint 评审会议在 Sprint 快结束时举行。检查sprint完成情况，展示成果，获得反馈。

• 参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者；
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
• 开发团队演示“完成”的工作并解答关于所交付增量的问题； 
• 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）；
• 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息； 
• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变； 
• 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

Sprint回顾会议

Sprint 回顾会议的目的在于：

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
• 找出并加以排序做得好的和潜在需要改进的主要方面；
• 制定改进 Scrum 团队工作方式的计划。

 

Scrum工件

产品待办列表 (product backlog)

产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。
产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新。产品待办列表项具有这些属性：描述、次序、估算和价值。产品待办列表项通常包括测试描述，将在“完成”时证明其完整性。
随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形势或者技术的变化都会引起产品待办列表的改变。

 

Sprint待办列表 (sprint backlog)

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。
Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中清晰地看到。

• 80%的价值来源于20%的功能。
• 达成共识。

工具

User Story - 用户故事

以用户故事的形式从用户/客户的视角描述需求待办事项。开发完成后由此扩充整理成需求清单。

 

燃尽图

以图的形式展示进展和开发效率。每个待办事项都有一个准确的工作量评估。

 

看板 - KanBan

 

实施步骤

1. 挑选产品负责人
2. 挑选团队
3. 挑选Scrum Master
4. 拟定待办事项，定优先级
5. 改进和评估待办事项
6. 冲刺规划会议
7. 每日站会
8. 冲刺评估/展示成果
9. 冲刺回顾
10. 下一个冲刺

 

Scrum的问题

• 跨职能，冲击传统的管理模式和组织结构；
• 高频度的沟通，难以适应；
• 聚焦团队的效率，特别看中个人发展的职员难以适应。
• 高频度的优化/重构/调整，对整个团队的整体能力和素质要求较高。
• 要求透明，难以控制公司核心技术和机密。