《scrum要素》读书笔记

[TOC]

一、关于scrum团队

  Scrum团队由一名产品负责人、一名Scrum Master和开发团队组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。

产品负责人

  产品负责人的职责是将开发团队开发的产品价值最大化。产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：

• 清晰地表述产品待办列表项；
• 对产品待办列表项进行排序，使其最好地实现目标和使命；
• 优化开发团队所执行工作的价值；
• 确保产品待办列表对所有人是可见、透明、清晰的，同时显示scrum团队下一步要做的工作；
• 确保开发团队对产品待办列表项有足够深的了解。

Scrum Master

  Scrum Master负责根据Scrum指南中的定义来促进和支持Scrum。Scrum Master通过帮助每个人理解Scrum理论、实践、规则和价值来做到这一切。
  Scrum Master对Scrum团队而言，是一位服务型领导。Scrum Master通过改变每个人于Scrum团队的互动方式来最大化Scrum团队所创造的价值。

开发团队

  开发团队包含各种专业人员，负责在每个sprint结束时交付潜在可发布并且“完成”的产品增量。在sprint评审会议上，一个“完成”增量是必须的。只有开发团队成员才能创造增量。
  开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。

二、定义product backlog（产品列表）

  产品列表是产品预期交付物的累计清单，包括了特性、缺陷修复、文档变更和任何值得创建的东西。通常列表中的每一项都是用户故事。产品列表是经过排序的，越往上，定义越完善，优先级越高；越往下，用户故事的体量越大，定义越模糊。产品列表排序的顺序通常就是团队要实现的故事的顺序。随着开发的进行，特性（故事）在列表中不断上移，越来越接近它被实现的时刻，团队对它的审查也更为仔细，估值和接收标准也更精确，大故事也会被拆分成小故事。这样，产品列表就更关注当前需要实现的特性，而不浪费时间给那些大概率不会实现的特性写详细规格书。
  产品负责人拥有产品列表。只有产品负责人可以增加、减少列表中的条目，或是进行优先级排序。

三、sprint（冲刺）

1.举行sprint planning（冲刺规划）会议

  冲刺规划会议标志着冲刺的开始。会议内容分为两个部分：

  第一个部分的目标在于，团队要找出他们有信心在冲刺结束时交付的一组“已承诺”故事。产品负责人引导这一部分的会议，按照产品列表的优先顺序，逐个介绍他希望团队在当前冲刺完成的故事。团队成员要和产品负责人探讨所有故事，审查其验收标准，确保大家对预期结果有一致的理解。团队成员协商解决依赖性问题，讨论实现故事要做哪些事情，并决定他们是否承诺这个故事。

  第二个部分的目标在于，团队要把选定的故事分解成任务。故事是交付物，是干系人、用户和客户想要的东西。任务面向实现，团部i需要完成这些任务才能交付故事。团队承诺会在本次冲刺结束时交付的所有故事以及相关联的任务，构成了sprint backlog（冲刺待办列表）。

2.开发活动

  确定了本次冲刺的任务，就可以进行分析、设计、编码、测试等开发活动了。scrum只是提供了大体的框架，至于某一次冲刺内具体的、实践性的软件过程可以自行决定，比如传统瀑布模型、极限编程等。

3.进行scrum日会

  scrum日会也被称为每日站立会议。每日Scrum站会是开发团队的一个时间盒限定为15分钟的事件。每日Scrum站会在Sprint的每一天都举行。在每日Scrum站会上，开发团队为接下来的24小时的工作制定计划。通过检视上次每日Scrum站会以来的工作和预测即将到来的Sprint工作来优化团队协作和效能。每日Scrum站会在同一时间同一地点举行，以便降低复杂性。
  开发团队籍由每日Scrum站会来检视完成Sprint目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日Scrum站会优化了开发团队达成Sprint目标的可能性。每天，开发团队应该知道如何以自组织团队来协同工作以达成Sprint目标，并在Sprint结束时开发出预期中的增量。
  会议的结构由团队设定。常用的范例如下：

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

  每日Scrum站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

4.scrum评审会议

  Sprint评审会议在Sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
  Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

5.Sprint回顾会议

  Sprint 回顾会议的目的在于：

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

  在Sprint回顾会议结束时，Scrum团队应该明确接下来的Sprint中需要实施的改进。在下一个Sprint中实施这些改进是基于Scrum团队对自身的检视而做出的适当调整。