有声书 | 故事中的Scrum（26）：项目成本预算

故事中的Scrum主播天团带您学习《Scrum实战指南》，声音与文字搭配，带您飞跃敏捷软件开发。

本期领读主播：吴言。

---

故事

◎ 出场人物：

• 项目经理Lindell(琳德尔) 

• 首席开发员Brain(布莱恩) Mike(迈克)

Lindell 是为公司在线服务Web 组件开发新功能的项目经理。她已经在公司工作很多年。就像她的其他团队成员一样，她听说过Scrum 但从来没有使用过。

有一天，公司的首席开发员Brian 找到她，希望能够在她的下一个项目中使用Scrum。他们之间的对话如下。“Lindell，我认为这个项目应该使用Scrum，”Brian 说道。“我也想使用 Scrum，但是Scrum 不适合我们公司。我们必须事先锁定项目的人员、日期以及功能。说到这，理层正在催我马上给他们一些计划，”Lindell 停下来看了看她的手表，接着继续说，“管理层需要一个事先计划，这种计划Scrum 团队是不会做的。”

“我以前也这样认为。但是，我读过一些东西，而且在上周，我在用户组见面会中遇见了Mike。他谈到公司如何做项目成本核算。如果我请他来和我们一起吃午饭，你能听听他是怎么说的吗？”Brian 问道。“当然可以，只要能用上Scrum，任何方式我都赞成，”Lindell 说道。“好的，那我安排在下周早些时候。”Brian 说道。

Lindell 希望这一天早些到来。管理层给她施加越来越多的压力，要求她提供日期、功能集以及项目在硬件和人员方面所需的预算。他们刚坐到一起午餐的时候，Lindell 就转向Mike 解释说：“Mike，我很为难！我一点也不知道该怎么做这个项目的预算。我想用Scrum，但真的不知道该怎么做。我真的是一筹莫展。”

“我觉得我可以帮你，”Mike 说道，“Brian 已经把你遇到的一些挑战告诉我了。我想我们要做的第一件事情是评审要求我们做的功能集。”Lindell 拿出一本有100 页的规格文档。Mike 皱了皱眉。“你还有其他什么文档还是就是这个了？”Mike 问道。“就是这个，不管它价值多少。我的意思是，它已经被签署并批准了。但是我根本无法确定最终是否都同意上面写的东西。”Lindell 承认道。

“嗯，这是一个起点。我们真正需要的是一个产品列表。让我们看看这个需求规范，然后根据它来写用户故事。我把索引卡也带来了。”Mike微笑着说道。Lindell 和Brian 都参加过一个Scrum 课程，他们对用户故事还算是有点儿熟悉。因此，他们还是几乎没有什么困难就一节一节地浏览需求规范，然后把用户故事写在索引片上。

大约15 分钟后，Lindell 注意到有一个潜在的问题。“Mike，就像我所学的那样，我一直在以用户的身份来写用户故事。但我们的系统有很多种用户，我应该像这样‘作为一个会计用户’写用户故事吗？”“对，就是这样。很抱歉我没有早一点告诉你们。”Mike 说。“没问题，我真的很高兴可以做些富有成效的事情。”Lindell 回答道。

几个小时后，他们创建了差不多50 个用户故事。虽然Mike 不得不到他的办公室，但是他答应第二天来帮助他们完成成本核算。第二天 Mike 来的时候，Brian 已经把所有故事卡都贴到会议室的墙上了。

他和Lindell 已经按照功能领域对把用户故事进行了分类，而且把大的、高级别的故事放到上面，而把较小的故事放在其下。为了确定每个故事的大小和级别，他们发挥了他们最好的判断力并对每个故事进行讨论，确定了若干组他们认为可以交付的功能集。

“这很好，”Mike 说，“下一步是搞清楚这些故事有多少点以及它们的优先级。”“优先级很简单，”Lindell 说，“它们都是高优先级的。故事点看上去很抽象。为什么我们不能跳过这一步，直接看看这些故事需要花多少个小时？”Lindell 问道。

Brian 插话说：“用小时数限制太多了。管理层会看到这个真的很粗略的小时数估计并让我们对这个数字负责。故事点可以让我们不需要用特定小时数来沟通工作量。”“在我看来，我们现在浪费了很多本可以用来做真正计划的时间。”Lindell 说道。Mike 点点头：“我知道你的想法，Lindell。我们现在还只做了一部分工作，还很难看出这些东西最终怎么整合在一起。我从做这个中学会的一点是，我们真的都很擅长估计相对大小，比如确定哪一袋杂货更重。但是，如果让我们估计每袋杂货的绝对重量，就不太容易做到了。这就是为什么我会采用故事点数，一个相对的测量，而不是使用小时数这种绝对的测量。”

“好吧，”Lindell 说，“既然都已经做了这么多，那就继续估故事点吧。”“好的，你的团队在哪里呢？我们需要他们来估。”Mike 说道。“我的团队？哈！在经过采购和人力调度的程序之后，才会有团队分配给我。有预算和计划之后，我才可以走那个程序。看，我就知道Scrum不适合我们。”

“我知道这可能不完美，Mike，”Brian 加入进来，“但是现在就只有我们三个人。有没有可能由我们三个人估算这些故事，只为预算流程？一旦有了团队，我们就肯定可以更好地估算这些用户故事。对吧？”“我们当然可以这样做。我只是想让你们明白，让真正做事的人自己来估算工作，效果要更好地多。如果现在这样做不可能，就只能由我们现在几个人来做。你们熟悉使用部分斐波那契数列来做故事点范围吗？1，2，3，5，8，13，如果需要的话还有20 和40？”“我听说过这个。但我没有真正搞明白，这些数字表示小时、星期还是别的什么？”“它们是对相对大小的衡量，”Mike 解释说，“可以把这个问题看成是T 恤衫的尺寸与衬衫的尺寸。T 恤衫的尺寸是相对大小，XS，S，M，L，XL，XXL。衬衫尺寸更绝对，有袖长与领围的具体尺寸。”

在 Lindell 和Brian 都点头表示理解后，Mike 继续说：“所以我们就把用户故事更多当成T 恤衫。找到一个有代表性的最小的用户故事，把它当作XS 或者1 点；再找一个有代表性的最大的用户故事，把它当作XXL 或者13 点；或许再找一个中等大小的故事，作为M 或者L，3 点或者5 点。这些都是参考故事，然后其他所有故事可以与参考故事相比较，以此来确定大小。一个2 点故事大概是1 点故事的两倍大小，一个8 点故事大约是13 点故事一半的大小。明白了吗？”“有几分明白。”

“我们从这一组用户故事开始吧。先找到一个最小的用户故事，它就是我们的1 点。”Lindell 和Brian 在一个很小、很简单的用户故事上达成一致。“现在，请找出一个是这个用户故事两倍大小的用户故事。”再次，Lindell 和Brian 轻松地为Mike 找出这样一个用户故事。很快，他们就开始讨论这些故事并给很容易地给它们分配点数。这一天剩下的时间都花费在这上面了，但Lindell 和Brian 最终对故事墙上所有故事都进行了大小估计。在这个过程中，Mike 忙于记录对这些用户故事的讨论，好让Lindell 和Brian 今后进行回顾。

“我们休息一下吧，”Mike 提议说，“Lindell，你觉得这样做怎么样？”“哇噢！我们发现了很多假设。我的意思是，比如这个需要调用数据集的用户故事，Brian 原本以为由于需求规范没有更新，所以我们只能使用其中一半的数据。通过对这个用户故事的讨论，让我回想起了最近在和某人吃午餐时的不那么重要的讨论，有一个人说API 已经被重写，而这个重写使我们可以使用我们需要的所有数据。我当然很高兴现在能发现这个问题。”Lindell 热切地说。

“这就是使用这种技术的妙处之一。通过讨论与对话，我们真的可以发现这些假设，并且帮助每个人尽早对用户故事达成一致理解，”Mike 说道，“接下来我们要确定团队在每个Sprint 能够完成多少用户故事点。由于还没有团队，所以这可能有点麻烦。你们两个有谁做过公司的Scrum 项目？”Mike 问。“没有，很抱歉，Mike。我们都是小白鼠(实验Scrum 的人)。”Brian说道。“没问题。最开始的时候，我们也是估速率。这不完美，离完美相差十万八千里，但对于我们需要做什么才能完成项目，这可以让我们有一个大致的概念。这给我们提供了一个起点。”Mike 说。“能给我们讲讲这个过程吗？”Lindell 问。“我有一篇关于这个话题的文章，今晚我就发给你，Lindell。”Mike说。

“太好了。那么，一旦有了团队速率，接下来应该做什么？”“对定义的用户故事确定优先级。”Mike 说。“但是 Mike，它们都……”“最高优先级？”Mike 说道，“我知道，听我说。让我们看看墙上的这些分组。哪一组用户故事最重要，绝对不能少？”Mike 问。“这一组，”Lindell 说。“但是还有一组很接近，排名第二。”Lindell 还没有意识到自己其实选择了一个最小可发布的功能集。Mike 对这些故事卡进行排列，最重要的故事卡放到最上面，优先级较低的放在下面。

“很好，我看我们的产品列表中大概有45 个用户故事，一共约200 故事点。早些时候你们说过，项目期限是7 个月，也就是28 周。那么，假设通过估算过程确定团队每个Sprint 能够完成10～14 个故事点。如果经过14 个两周的Sprint(28 周)后，团队能够交付多少个故事点？”“在 140～196 点之间。虽然没有完成所有故事，但已经完成了相当大一部分。”“这就是确定用户故事优先级为什么很重要的原因。这样一来，在有限的时间内，团队可以完成最重要的工作。”Brian 说。“那么我们怎么才能提高，使其接近范围的上限，我指的是速率？”Lindell 问道。“可以增加资源或者提高效率，这就是ScrumMaster 要做的工作。我再建议找一个ScrumMaster。如果想知道原因，可以看我写的一篇文章，用管理层能够理解的术语(即金钱)来给管理层解释清楚。”Mike 说。

“谢谢你，Mike，”Lindell 说道，“这真是给了我们莫大的帮助。现在我们已经确定需求以及基于未来团队来确定速率。但是，项目的成本怎么得到呢？”“你觉得需要多少人做这个项目？”Mike 问。“我争取要 6 个人，但实际一点，我们会得到5 个。”Brian 说。“而且更糟糕的是，我们能得到的这 5 个人都不是全职做这个项目。他们还要分配时间做其他项目。如果我们真的很幸运，会有一个专职人员，但我对此并不抱太大的希望。”Lindell 说。“那么每个项目成员每天会有多少时间做你的项目？”Mike 问。“大概 6 个小时。这可能估计得多了一点，但是这与我过去项目的平均时间相吻合。”Lindell 回答。“很好！那我们就用 6 个小时作为每个人用来做这个项目的时间。怎样计算成本？这是一个内部项目，对吧？”Mike 问。“是的，内部项目。我们员工的成本都不一样，但是我们可以先假设每小时140 美元，”Lindell 说道②。“很好，那么如果用140 美元，而有5 个员工，那么成本是每小时大概700 美元。如果每个人每天有6 个小时做项目，那么这个项目每天的成本就是4,200 美元，或者说两周的Sprint 需要42,000 美元，”Mike 说道，“项目预算是多少？”“我们的项目预算是800,000 美元。”Lindell 说道。“每个 Sprint 需要42,000 美元，那么800,000 美元就可以买18 到19个Sprint。问题是，项目期限只有14 个Sprint。如果团队速率是每个Sprint完成10 个故事点，那么14 个Sprint 可以完成140 个故事点，这会花掉588,000 美元[(42,000 美元/10)*140]。这大大低于之前800,000 美元的预算，但没有交付所有用户故事。你还有钱给团队再加一个人，这样可以提高速率，但可能仍然完不成整个产品列表。不管怎样，我们还是完成了今天打算做的事。”Mike 说道。

然后，他走向白板，写下了他们已经获知的信息。

1. 生成用户模型

2. 确定用户故事的优先级

3. 估算用户故事的大小

4. 确定速率

5. 确定团队的成本

6. 计算项目成本

7. 承诺，是与否

Lindell 心中的疑问一扫而光。现在，她明白各个部分是怎么联系在一起的了。而且更重要的是，相比其他方式，她认为她现在可以给管理层更好的信息与更多的选择。“谢谢你，Mike，”Lindell 说道，“你简直是帮了大忙。你知道吗，现在我觉得Scrum 这东西还真的也适合我们。”

---

故事背后的模型和成功要领，参阅图书《Scrum实战指南》。

别忘了赞赏主播哦~