Scrum敏捷估算

无论是团队研发一款产品或者开发某一个项目，我们都需要回答“我们大概什么时间能够完成？”， 或者到某一个时间点，我们能够做到什么程度， 因此和传统的开发模式一样，我们在工作开始之前需要对我们需要做的事情进行工作量的估算。

相对与传统的工作量估算方式，敏捷估算有如下几个特点：

1. 团队集体估算

在Scrum的开发过程中，团队共担责任，集体承诺每个Sprint的工作，因此对于工作量的估算敏捷团队采用集体估算的方式。集体估算，通常采用估算扑克作为工具，团队通过玩估算游戏进行集体估算。使用估算扑克来做工作量估算是最有效，也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字，可供4个人使用。

估算扑克的使用方法：

• 每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
• 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。
• 团队讨论这个条目。
• 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。
• 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数”1,2,3″,大家同时展示估算结果。
• 团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？讨论之后可以再估算一轮，最终团队需要达成一致。
• 回到第二步，开始估算下一个条目。

关注Scrum中文网微信公众号可以获得微信版估算扑克。

2. 估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算

一瓶矿泉水，让一个3岁的小妹妹把它喝完所花的时间和一个成年人把它喝完所花的时间肯定不一样，因此同一项工作，不同能力的人完成它花费的时间显然是不一样的。如果我们要估算从家到公司的绝对距离时多少公里，您可能不一定知道，但是如果您时做地铁上班，从家里到公司有多少站，你一定很容易知道，当我们知道有多少站之后，我们就可以大概清楚路上需要花多长时间了。敏捷估算时，我们不会估算绝对时间和周期，我们估算大小，和相对值，也就是倍数。敏捷估算时，我们使用故事点作为计量单位，它是一个倍数，我们会先找一个我们认为最小的一个功能的大小作为参考基准，定义为1个故事点，把其它的故事和它做比较，如果是2倍大小，就是2个故事点，如果是5倍大小，就是5个故事点。

3. 记录每个Sprint的团队速度

团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数，通过团队速率可以知道团队做的有多快。新开始的项目或产品开发，或者是新团队，没有初始速度，我们可以做1-2个Sprint测算一个速度，作为初始速度。在Sprint执行过程中，我们要记录每个Sprint的速度，为以后的计划做参考。

我们估算了产品Backlog的故事点总数，然后又知道了每个Sprint团队的平均速度，那么我们就可以推算我们大概需要多少个Sprint可以做完，这样我们就得到了周期。

[/av_tab]
[av_tab title='Sprint' icon_select='yes' icon='ue875′ font='entypo-fontello']
Scrum是一种迭代和增量式的产品开发方法，Scrum通过Sprint来实现迭代。一个Sprint是指一个1周－4周的迭代，它是一个时间盒。Sprint的长度一旦确定，保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品增量。Sprint 在整个开发过程中的周期一致。新的 Sprint 在上一 个 Sprint 完成之后立即开始。 
Sprint 包含并由 Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

Scrum采用迭代增量的方式，是因为需求是涌现的，我们对产品和需求的理解是渐进式的，Sprint长度越长，我们需要预测的越多，复杂度会提升、风险也会增加，所以Sprint的长度最多不超过4周。越来越多的团队使用2周的Sprint，很多市场变化快、竞争激烈的领域，比如互联网和移动互联网产品开发团队也会使用1周的迭代。

在Sprint进行过程中，如下内容不能发生变化：

• Sprint的目标
• Sprint的质量目标和验收标准
• 开发团队的组成

集中优势兵力各个击破

在Sprint执行的过程中，团队要避免一个萝卜一个坑的工作方式，团队要协作，并且要集中优势兵力各个击破。

团队按照蜂拥式（Swarming）的工作方式，团队先集中工作在少数几个需求上面，协作完成它们，然后在开始下一批需求。按照这样的方式一方面可以加强团队协作，另外也有利于及早完成一些需求，让这些需求及早验收。

取消一个 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权 力,但他做这样的决定也可能是受到利益干系人、团队或是 Scrum Master 的影响。

如果某个 Sprint 的目标过时了,那么就需要取消该 Sprint。比如公司的发展方向, 或是市场、技术等情况发生了变化,这些变化都可能导致取消 Sprint。总的来说,如果某 个 Sprint 对于其所在环境来说失去了价值和意义,那么它就应该被取消。然而,因为 Sprint 周期都较短,所以很少发生取消 Sprint 的情况。

当某个 Sprint 被取消时,任何做完和“完成”的产品待办事项列表条目都需要评审。假如有些条目已经潜在可交付,那产品负责人就会采纳它。所有未完成的条目就都要 放回到产品待办事项列表中,并重新估算。花在它们身上的工作会迅速贬值,所以需要频 繁地重估。

取消 Sprint 会消耗资源,因为每个人都需要在新召开的 Sprint 计划会议中重新开始 另一个 Sprint。Sprint 终止通常会对团队造成重创,因此这种情况也非常少见。