故事中的Scrum主播天团带您学习《Scrum实战指南》，声音与文字搭配，带您飞跃敏捷软件开发。
本期领读主播：吴言。
故事
◎ 出场人物：
产品负责人Rachel(瑞秋)
ScrumMaster Jackson(杰克逊)
“我还并不能完全接受故事点，”Rachel 说。“它看起来太弱。我喜欢按小时估算所带给我们的确定感。”Jackson 有点不知所措。在过去的五年里，他在这家公司经历过几个按小时估算工作的团队。那些团队的项目无一例外地都没能按时结束，并且超出预算和最终未能完全满足客户的要求。
“Rachel，”Jackson 礼貌地说。“小时估算可能看似给了我们确定感，但我可以向你保证，它没有。我的意思是，你能不能告诉我哪怕一个差不多按估算完成的项目？” “好吧，没有，”Rachel 回答说。“但至少当你以小时告诉我估算时，我知道那意味着什么。我认为故事点应该更准确。而事实上，它感觉就像模糊数学。”
“我明白了。我过去也认为按小时思考更容易。起初我对于故事点的整个概念也很挣扎，但之后有一天，当我和一个朋友山地骑行时，我一下子就想通了。你看，我的朋友是一个相当好的自行车手—而我只是还过得去。在那特定的一天，他接上我并且告诉我，他将带我到他喜欢的小路，而那将是一段充满挑战但又快速的骑行，耗时大约是30 分钟。当我们到达时，我意识到我以前曾多次骑过这条小路。我转向他说，‘30 分钟?这至少是一个小时的路程。’”“对。你是在用时间描述。大家通常都这样做。”Rachel 说。“但这是如何帮你想通故事点的？”
“容我说下去—我就要说到这其中的关系了，”Jackson 解释说。“所以我们就站在小路的起点那里，争论着这段骑行要花多长时间。他解释说，这是一段艰难的六英里骑行，但他总是会花大约30 分钟。我向他解释说，这段特定的六英里的骑行几乎是直着上坡的，并且有大量的之字形拐弯，那将让我用上我所有的体力和技巧。我补充说，上一次我在这条小路上骑行的时候，它花了我足足一个小时，只少不多。在我们的争论中的某一刻，我突然意识到这就是为什么团队需要故事点的原因—故事点捕获的是一个故事所需要的工作量，而不是一个团队能够完成故事的速度。我们都认为这是一段相对艰难的六英里旅程—我们不能达成一致的是某些更绝对的东西—即这六英里到底需要多长时间。”
“为什么不把它平均下来呢？为什么不折衷一下，并称之为45 分钟的小路？”Rachel 问道。“因为时间是可变的。根据天气、骑手的健康水平、道路的拥挤程度以及更多的情况，骑手每天骑行所需的时间长短不一。然而，大多数时候所要付出的努力将保持不变。一旦我们同意了对这条路线的工作量估算，假设我们称它为2，我们就可以很快对比出来该区域的其他路线的估算。类似的六英里路线将会是2，但15 英里但更平坦的路线也可能是2，对吧？一旦我们有了一个通用的计量尺，我们就比较容易开始比较这个区域的各种不同的路线。”
“这是有道理的—我有点能看到度量工作量的争议性没有那么大，而且最终比确定小时数的连贯性更强。另外，我认识到，故事点估算对哪个团队成员将会执行实际工作及其他变量的依赖程度较低。但是如果所有这些都是真的，那么为什么团队会在一个Sprint 中成功完成45 个点，而在下个Sprint 中完成20 个点都吃力？”Rachel 问道。
“我认为这是我们目前面临的最大问题—也是我们所有人都认为需要改进的问题。因为这个团队刚接触故事点，所以我们的估算还是很不连贯的。我们的一些1 个点的故事，所花的时间跟3 个点的故事一样长。与此同时，我们完成8 个点的故事所花的时间跟完成3 个点的故事是一样的。”
“我认为我们不应该担心一个故事要花多长时间，”Rachel 插话道。“只要它能帮我们作出更准确的估算，我们的担心就止于此。让我给你展示一些我一直在研究的东西，”Jackson 补充道，并在屏幕上放出一张图表。
“几个 Sprint 之前你问我故事点与小时数之间的关系是什么，”Jackson 继续说。“我认为这是一个很好的问题，所以从那以后我就一直在用图表记录团队实际完成一个故事的小时数和这个故事的估算之间的关系。我想通过这样做，我就可以给你一个明确的答案。不过，你看到了什么？”
“好的，”Rachel 说，“看来团队在一个点的故事上花的时间散布在1～50 小时之间。但奇怪的是，两个点的故事花的时间似乎在20 到40 个小时之间。所以有很多重叠的地方。然而，与此同时，更大的故事总体上来说却总是需要更多的时间来完成。”
“完全正确，”Jackson 说。“我看到两件事：首先，一个故事点暗示了一个范围—在这个例子中是一个小时数的范围—这和我读过的所有东西都是完全一致的。而且，我现在看到了，这些范围有很多重叠，这让我们了解了为什么有些Sprint 我们似乎完成了很多东西而有些Sprint 我们很难完成任何事情。”“所以，我听到的是这个团队在评估方面很糟糕，而故事点没有帮上忙。这就回到了我最初的问题：为什么我们不能就用小时？”
“我听到你的问题了，”Jackson 说。“但我要说的是，我们在估算故事点时，并不比我们估算小时数更糟。事实上，我想我们可能会做得更好一些。而让事情保持在抽象的层面帮助消除了令其他团队陷入困境的恐惧—害怕被锁定到某一时间估算，或者害怕在一个故事上用的时间比专家长。使用故事点也可以使评估会议，像我们将要讨论的那样，进行得更快，这是因为我们不会陷入关于多长时间的无意义的争论中，而更多是投入关于工作量的相对讨论中。那些对话几乎总是会引发帮助我们揭示假设和细节的提问，而这些假设和细节在我们只是问需要多长时间时通常会被隐藏起来。”
“你说的挺有道理的，”Rachel 同意道。Jackson 点点头继续说。“基本上，故事点让我们能往前走，让我们得到一个准确的估计，而不是过于精确。然而，追踪每个故事所花的时间，正如我所做的那样，也给了能使我们在未来能更准确的机会—这对我们大家都有好处。有了这些数据，我们可以问三个关键的问题：到目前为止，哪些我们已经完成的故事似乎超出了范围，也就是故事点估计的不准确？还留在产品列表中的故事有没有与那些估算错误的故事类似的？如果是这样，我们是否应该改变对这些故事的估算？”
“我想我明白了，”Rachel 兴奋地说。“回到你的自行车类比，比方说你给了一段路5 点，因为它真的很长，并且你感觉它有很多上坡。然后当你实际骑行时，发现上山的时候是比你想的更平缓，大部分的小道也都是铺平的。在骑行之后，你决定你应该把这条路估算为3。然后你再看一下你所做的其他的估算，并修改其中的一些，估算时记着斜坡和路面情况会影响到这条路线所需要的工作量。在评估任何新的路线时，你也要记住这些因素。”
“是这样的。因为故事点暗示了一个范围，因此给了我们准确性。然后，随着项目进展和时间推移，我们把我们学到的东西和我们的历史数据结合起来来提高准确性，而范围也变得越来越小。每个Sprint 之后，我们都需要回答前面提到的三个问题，然后相应地调整计划。一旦我们有了节奏，我想你会发现我们的预测要比那些预先以天或小时估计所有事情的团队要准确得多。”
他们也确实那么做了。一个一个 Sprint 之后，团队能够在故事点估算上收紧准确度，让团队成员对Sprint 的承诺更加有信心，并且以更稳定的步伐在每个Sprint 中工作。
故事背后的模型和成功要领，敬请关注图书《Scrum实战指南》，图书业已上市。
别忘了赞赏主播哦~
4389
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
