学习151

Scrum是一种敏捷方法，旨在指导团队进行产品的迭代和增量交付。通常被称为“敏捷项目管理框架”，其重点是使用经验过程，使团队能够快速，有效，有效地做出改变。传统的项目管理方法确定了需求，以控制时间和成本; 另一方面，Scrum修复了控制需求的时间和成本。这是使用时间框，协作仪式，优先产品积压和频繁的反馈周期来完成的。整个项目中业务的参与至关重要，因为Scrum在很大程度上依赖于团队与客户或客户代表之间的协作，以精益 (Lean) 方式创建合适的产品。

什么是Scrum？
我们首先应该清楚Scrum不是什么。有一种常见的误解，认为敏捷就是 Scrum。虽然Scrum确实很敏捷，但它并不是实现敏捷原则的唯一方法。Scrum只是产品开发的众多敏捷方法之一。其他方法包括极限编程（XP），晶体，特征驱动开发，DSDM Atern等。所有这些方法都遵循敏捷宣言及其相关原则。一个有用的比喻是认为敏捷是冰淇淋 (ice Cream)，而Scrum，XP，水晶 (Crystal) 等，都是不同的口味，如巧克力，草莓，香草。它们都很敏捷，它们都很好，很多都可以组合使用。

Scrum中只有三个角色：ScrumMaster，产品负责人 (Prodcut Owner) 和开发团队 (Development Team)。

ScrumMaster是流程的守护者，团队的倡导者和团队的保护者。他们消除障碍，促进团队沟通，调解团队内部的讨论，并与团队外部人员进行协商。最重要的是，它们存在于团队服务中。

产品负责人 (Prodcut Owner) 代表客户的声音，并有权决定产品。此人拥有产品待办事项，负责将愿景传达给团队，并定义积压项目并确定其优先级。产品负责人每天与团队合作，回答问题并提供产品指导。

该开发团 (Development Team)队由七个正负两个人组成，他们共同负责产品的交付。他们拥有估算，做出任务承诺，并在每日Scrum中相互报告每日状态。它们是自组织的，意味着结构在没有外界明确干预的情况下出现。换句话说，团队拥有如何选择构建产​​品功能 - 团队拥有“如何”，而产品所有者拥有“什么”。

Scrum通过一系列仪式 (Scrum Ceremonies) 或会议 (Meetings) 来应用。必要的Scrum仪式包括sprint计划会议 (Sprint Planning)，每日scrum (Daily Standup)，sprint审查 (Sprint Review) 和sprint回顾 (Sprint Retrospective)。还需要使用称为冲刺的时间框。发布计划会议是可选的，允许规划和预测冲刺组。

Sprint计划会议

冲刺计划会议在每个冲刺的第一天举行。ScrumMaster，产品负责人和团队都出席了会议。产品负责人提供他或她希望在sprint中完成的功能集（“什么”），然后团队确定实现这些功能所需的任务（“如何”）。将审核工作估算，以确定团队是否有时间完成sprint中请求的所有功能。如果是这样，团队承诺冲刺。如果没有，优先级较低的功能将返回到产品待办事项中，直到sprint的工作负载小到足以获得团队的承诺。

跟踪进度

一旦冲刺计划 (Sprint Planning) 会议完成并且团队做出了承诺，团队就会开始使用高度可见的信息辐射器跟踪其进度。这些散热器包括燃尽图和任务板。

团队使用任务板跟踪每个功能的任务进度。使用的最小列是“待办事宜”，“执行”和“完成”。团队将在任务委员会举行每日Scrum会议，并在陈述他们昨天做了什么，他们打算今天做什么以及他们正在努力解决的障碍时，全面移动项目。有关软件开发项目的示例任务板

燃尽图显示了冲刺中剩余工作量的趋势线。x轴是sprint中的天数，y轴是sprint规划会议中定义的所有任务的小时数。在冲刺期间，指示剩余工作量的线应该在冲刺的最后一天趋势下降到零。有关sprint burndown图表示例

使用燃尽图表，任务板和每日Scrum跟踪Sprint进度。结合起来，这三件事可以清楚地描述正在进行的工作，已完成的工作，仍有待完成的工作，是否能够及时完成，以及可能阻止团队满足其冲刺和/或发布目标。

Sprint评论 (Sprint Review)

在sprint结束时，团队邀请利益相关者参加sprint评审会议，在会议中演示sprint中完成的功能并请求反馈。产品负责人会跟踪反馈并根据需要将其合并到产品待办事项中。

一旦审查完成，团队（没有利益相关者）进行回顾，以确定他们希望继续做什么，他们挣扎的是什么，以及他们对未来的改变有什么建议。创建一个行动计划，这些项目将在下一个sprint的过程中实施，并在下一个sprint回顾中进行审查。

发布计划 (Release Plan)

发布计划也是Scrum的一部分，是一种对包含多个sprint的时间框进行长期规划的方法。这通常是按季度完成的，本季度的结果不一定是向客户发布的，但可能只是内部版本以确认系统集成和验证。图表4显示了发布计划如何适应Scrum框架的其余部分。

整个团队参加发布计划会议，产品负责人在会议中展示他/她希望在本季度完成的功能。然而，该团队并未对这些功能进行任务，而是提供总体水平估算，以确定在什么样的冲刺中可以完成哪些功能，以及在本季度末可以完成多少这些功能。发布计划可以是功能驱动的（完成这组功能需要多少冲刺？），时间驱动（我们期望在截止日期前完成多少功能？）或成本驱动（考虑到这个预算，我们的日程安排是什么样的，我们在没钱之前会做些什么？）