使用 scrum 进行敏捷项目管理

摘要

scrum 是一种敏捷方法, 旨在指导团队实现产品的迭代和增量交付。通常被称为 “敏捷项目管理框架”, 其重点是使用经验过程, 使团队能够快速、高效和有效地响应更改。传统的项目管理方法解决需求, 努力控制时间和成本;另一方面, scrum 可以解决时间和成本问题, 以控制需求。这是使用时间框、协作仪式、优先的产品积压和频繁的反馈周期来完成的。企业在整个项目中的参与至关重要, 因为 scrum 在很大程度上依赖于团队与客户或客户代表之间的协作, 以精益的方式创建正确的产品。本文概述了 scrum 及其在项目管理中的应用。

什么是 scrum？

我们首先应该清楚什么不是 scrum。有一个常见的误解, 即敏捷就是scrum。虽然 scrum 确实是敏捷的, 但它并不是实现敏捷原则的唯一方法。scrum 只是许多敏捷产品开发方法中的一种。其他方法包括极限编程 (xp)、晶体、功能驱动开发、dsdm 投递等。所有这些方法都遵循敏捷宣言及其相关原则。一个有用的比喻是认为敏捷是冰淇淋, 而 scrum、XP、crystal 等都是不同的口味, 比如巧克力、草莓、香草。它们都是敏捷的, 都是好的, 很多都可以结合使用。

简单地说, scrum 是一种使用频繁反馈和协作决策的迭代和增量产品交付的敏捷方法。

历史

scrum 是基于 1986年 hirotaka takeuchi 和 ikujiro nonaka 为《哈佛商业评论》撰写的一篇题为 “新产品开发游戏” 的论文。本文以橄榄球运动为隐喻, 描述了自组织团队在创新产品开发和交付中的好处。Jeff Sutherland，Ken Schwaber和Mike Beedle从本文中吸取了包括隐喻在内的想法, 并将其应用于他们的软件开发领域。他们称自己的新方法 scrum, 在橄榄球术语之后, 描述了球队如何形成一个圆圈, 并去争取球重新投入比赛。他们于1993年首次在 Easel 公司采用了这种方法。Schwaber和Beedle在 2002年的《 scrum 敏捷软件开发》一书中讲述了他们的经历, 随后, 施瓦伯的书《敏捷项目管理与 scrum 》在 2004年, 其中包括Schwaber 对Primavera所做的工作。

scrum 框架

schwaber 将 scrum 称为框架, 而不是一种方法。这主要是由于 “方法论” 一词的内涵, 许多人推断它在本质上是规定性的。相比之下, scrum 只是提供了一个交付结构, 但没有告诉你如何执行特定的实践, 而是由团队来确定。图1显示了基本的 scrum 框架。

该项目从企业提供的明确愿景开始, 以及按重要性排序的一套产品功能。这些功能是产品积压工作的一部分, 由称为 “产品所有者” 的客户或客户代表维护。时间框通常称为迭代或冲刺, 是团队完成所选功能所需的固定时间。冲刺的长度一般为 1至4周, 在整个项目期间都保持了这一长度, 以建立节奏。团队从它认为可以在冲刺中完成的产品积压工作中选择项目, 并创建由功能和任务组成的冲刺积压工作, 作为冲刺计划会议的一部分。

一旦团队承诺完成冲刺积压工作, 任务工作就开始了。在冲刺的这段时间里, 团队受到保护, 不受干扰, 并被允许专注于实现冲刺目标。不允许对冲刺积压工作进行任何更改;但是, 可以更改产品积压工作, 为下一次冲刺做准备。

在冲刺过程中, 团队每天都以被称为擦边球的 1 5分钟会议的形式相互检查。球队围成一圈, 每个成员国都说了他们昨天做了什么, 今天打算做什么, 阻碍了他们的前进。

在冲刺结束时, 团队向利益干系人演示他们完成的工作, 并收集反馈意见, 这些反馈将影响他们在下一个冲刺中的工作。他们还举行回顾会学习如何改进。这次会议至关重要, 因为它的重点是 scrum 的三大支柱: 透明度、检查和适应。

角色和职责

scrum 中只有三个角色: scrum master、产品所有者 (Product Owner) 和团队 (Development Team)。

产品所有者代表客户的声音, 并有权对产品做出决策。此人拥有产品积压工作, 并负责向团队传达愿景, 并定义积压工作项并确定其优先级。产品负责人每天都与团队合作, 回答问题并提供产品指导。

该小组由7+/- 2 的人组成, 他们共同负责产品的交付。他们拥有估计, 做出任务承诺, 并在日常擦边球中相互报告日常状态。它们是自组织的, 这意味着结构在没有外部明确干预的情况下出现。换句话说, 团队拥有它选择构建产品功能的方式-团队拥有 “方式”, 而产品所有者拥有 “什么”。

scrum 的应用

scrum 是通过遵循一组仪式或会议来应用的。需要举行的 scrum 仪式包括冲刺计划会议、日常 scrum、冲刺回顾和冲刺回顾。在称为冲刺的时间箱中工作也是必需的。发布计划会议是可选的, 允许对冲刺群进行规划和预测。

冲刺计划会议 (Sprint Planning)

冲刺策划会议在每个冲刺的第一天举行。scrum master、产品负责人和团队都出席了会议。产品所有者提供了他或她希望在冲刺中看到完成的一组功能 (“什么”), 然后团队确定实现这些功能所需的任务 (“如何”)。将对工作估计进行审查, 以查看团队是否有时间完成冲刺中请求的所有功能。如果是这样, 球队将致力于冲刺。否则, 优先级较低的功能将返回到产品积压工作中, 直到冲刺的工作负载足够小, 可以获得团队的承诺。

跟踪进度 (Progress Tracking)

一旦冲刺规划会议完成, 团队做出承诺, 团队就开始使用高度可见的信息散热器跟踪其进展情况。这些散热器包括燃尽图和任务板。

工作组使用任务板跟踪每个功能的任务进度。使用的最小列是 “待办事项”、”执行” 和 “完成”。团队将在任务板上举行日常擦边球会议, 并在说明昨天的工作、今天的计划以及正在努力解决的障碍时, 全面移动项目。有关软件开发项目的示例任务板, 请参见图2。

燃尽图表显示了冲刺中剩余工作量的趋势线。x 轴是冲刺中的天数, y 轴是在冲刺计划会议中定义的所有任务的小时数。在冲刺的日子里, 指示剩下的工作量的线应该在冲刺的最后一天下降到零。有关冲刺燃尽图的示例, 请参见图3。

使用燃尽图表、任务板和每日 scrum 跟踪冲刺进度。结合起来, 这三样东西可以清楚地了解正在进行的工作、完成的内容、仍需完成的工作内容、是否会及时完成的内容, 以及可能阻止团队满足其冲刺和发布目标的原因。

冲刺评论 (Sprint Review)

在冲刺结束时, 团队邀请利益干系人参加冲刺评审会议, 在其中, 在冲刺中完成的功能是演示, 并请求反馈。产品所有者跟踪反馈, 并根据需要将其合并到产品积压工作中。

一旦审查完成, 团队 (没有利益攸关方) 进行回顾, 以确定他们希望继续做什么, 他们在哪些工作中挣扎, 以及他们对未来的变革有什么建议。创建了一个行动计划, 并在下一个冲刺过程中实施了这些项目, 并在下一个冲刺回顾中审查了效果。

发布计划 (Release Planning)

发布规划也是 scrum 的一部分, 是对由多个冲刺组成的时间框进行长期规划的一种方式。这通常是每季度完成, 本季度的结果不必是对客户的发布, 而只是确认系统集成和验证的内部发布。表4显示了发布计划如何与 scrum 框架的其他部分相适应。

整个团队都参加了发布计划会议, 产品负责人在会上展示了他希望在本季度完成的功能。但是, 团队并不对这些功能进行任务, 而是提供总级别估计, 以确定在什么冲刺中可以完成哪些功能, 以及在季度末完成这些功能的数量。发布计划可以是功能驱动的 (完成这一组功能需要多少冲刺？)、时间驱动 (我们可以期望在此截止日期前完成多少个功能？) 或成本驱动 (考虑到此预算, 我们的计划是什么样子的, 是什么样子功能, 我们会做之前, 我们用完了的钱？)。

一些 scrum 示例

scrum 在软件开发项目中很常见, 通过简单的谷歌研究可以找到无数的例子。不太明显的是 scrum 在非软件项目中的使用, 因此下面引用了其中的几个示例。

使用 scrum 书写书籍

我和我的同事斯塔契·维斯卡迪用 scrum 来管理我们的图书项目。我们的产品积压工作包括我们要为软件项目经理的敏捷之桥编写的章节, 根据客户查询的优先顺序。例如, 由于我们似乎得到了很多关于范围管理的问题, 而关于采购的问题很少, 关于范围的一章在积压的基础上, 而采购一章则接近底部。

我们召开了一次发布计划会议, 并将积压项目移动到翻转图表页面上, 这些页面代表了我们的冲刺, 长度为一个月。在每个冲刺开始的时候, 我们都发出了一个号召, 谈论我们将要写作的章节, 设定目标和期望, 并做出承诺。在冲刺过程中, 我们每周互相入住几次。当我们完成冲刺中的章节时, 我们会交换它们以获得反馈, 然后将反馈纳入最终副本。我们的冲刺评审包括对章节的最终评审, 任何其他的变化最终都会导致产品积压工作, 以便在下一个冲刺中计划。

由于只是我们两个人, 我们轮换角色和责任。在这本书的一部分, 我被称为 “产品所有者”, 我拥有最终的功能授权。对于其他部分, 斯塔西娅也有这个角色。我们的斯克拉姆大师是我们的编辑, 尽管他没有意识到这一点。他仍然履行着斯姆弗拉姆的职责, 然而, 他提醒我们我们的最后期限, 为我们消除障碍, 并为我们提供了完成工作所需的援助和工具。

而且不仅仅是我们用 scrum 来写书。孤独星球在他们的旅游指南开发中使用 scrum, “在 scrum 之前, 一本书的开发是非常连续的, 需要大量的手工, 需要很长时间才能把一本书从构思到出版。现在, 他们涉及到所有的球员需要把一本书放在一起 (作家, 平面艺术家, 桌面出版, 营销, 编辑等), 并逐步开发的一章后 scrum 框架的书籍 “(scrum 为非软件项目,2010年)。

风险投资公司中的 scrum 使用

杰夫·萨瑟兰是位于马萨诸塞州波士顿的一家风险投资公司 opentview venture partners 的高级顾问。2010年, 他为夏威夷系统科学国际会议撰写了一篇论文, 题为“组织转型与 scrum: 风险资本集团如何获得一半工作的两倍, 描述 openview 如何在其投资组合的管理。

开放视图团队在项目中使用 scrum “在管理、销售、营销、财务和客户支持的投资组合公司, 以及推动 scrum 到他们的投资组合公司 (sutherland, 2010, 第1页)。在 scrum 使用的一个示例中, 实验室团队使用一周的冲刺来为其投资组合公司执行运营增值项目, 进行尽职调查, 并将其增值能力制度化。

当实验室团队最初实施 scrum 时, 对正在进行的项目的可见性的提高使他们意识到, 其中几个项目实际上是低价值的。因此, 他们削减了 3 0% 的项目, 为更多的高价值项目腾出了空间, 让他们专注于并完成了这些项目。事实上, 这种清晰的重点和冲刺中正在进行的工作量的限制帮助团队提高了工作效率, 因为项目不再因为同时工作的太多而拖得很长时间。随着他们的不断适应, 他们的生产力已经翻番, 并 “正在实现生产力第二次翻番的道路上” (萨瑟兰, 2010年, 第8页)。

在Scrum我们会怎么做…?

因为这只是 scrum 的简短概述, 因此预计读者可能会留下几个未回答的问题。在本节中, 我们将介绍敏捷和 scrum 最常用的三个问题, 然后留给您一些关于在哪里可以找到更多信息的最后一句话。

在Scrum甘特图 (Gantt Charts) 和其他文档发生将变成什么?

甘特图通常不用于 scrum 项目。燃尽图表 (冲刺燃尽和发布燃尽)、任务板、积压工作、冲刺计划、发布计划和其他指标图表用于传达进度、状态和预测。有各种敏捷的项目管理工具可以提供这种类型的仪表板报告, 包括 Microsoft project 的插件。

scrum 所需要的唯一项目是产品积压、冲刺积压、发布燃尽和冲刺燃尽。所有其他形式的文档由团队决定。敏捷的经验法则是, 如果工件增加了价值, 而客户愿意为此买单, 那么就应该创建工件。因为 “它在清单上” 或 “我们一直都在这样做” 而创建的项目是应该考虑消除的项目。治理问题 (审计、会计等) 所需的文件仍需创建, 但往往可以精简。

项目经理将变成什么?

项目经理通常成为 scrum master。情况并非总是如此, 有许多不同的转换排列。例如, 一直担任域或主题专家的项目经理可能更适合担任产品所有者。或者, 领导一个由50多人组成的团队的项目经理可能会继续担任这一职务, 并专注于整个项目任务, 如采购和合同谈判, 而 scrum 团队在项目上 (记住, scrum 团队是 7 +/2 人, 所以一个50人的项目将被制作成 6-10 scrum 团队), 每个团队都有自己的 scrum master。在这种情况下, 项目经理协助 scrum master 协调、制定战略和消除障碍。

使用详细任务和任务估计生成预测将变成什么?？

传统的估计和规划使用自下而上的方法, 其中必须完全定义所有需求, 然后根据这一固定范围创建和估计任务。敏捷估计和规划则使用自上而下的方法进行预测。特征级别的总级别估计通常使用一种称为规划扑克的技术来完成, 估计以使用斐波那契序列的点为单位。团队以积分为目标确定自己的速度, 即团队在冲刺中平均能完成多少点。每点成本是通过计算 x 期间团队的加载工资, 然后除以期间 x 中完成的点数来确定的。一旦您拥有团队的平均速度和大量估计的产品积压工作, 您就可以预测项目里程碑和完成日期, 以及每个点的成本, 从而预测项目成本。