敏捷软件开发，需求、估算和规划工作步骤

经理们常常根据时间来确定团队成员的工作量。也就是说，经理们估计他们认为某些任务需要多长时间，然后根据该团队成员的总可用时间分配工作。这是有问题的，因为它没有区分一个故事是很难完成的还是一个故事并不费力；它只考虑了工作需要多长时间！

如何估算？

在Sprint Planning Meeting（冲刺计划会议）中，团队坐下来估算backlog（待办事项）中故事的工作量。Product Owner（产品负责人）需要这些估算，以便能够有效地对backlog中的项目进行优先级排序，从而根据velocity（速度）预测发布。这意味着Product Owner需要对工作难度有一个诚实的评估。即使团队自己进行估算，也应采取措施减少对团队估算方式的影响。因此，建议所有团队成员同时披露他们的估算。由于个人同时“亮出底牌”，这个过程与玩扑克牌游戏无异。不出所料，团队经常将估算称为“planning poker”（规划扑克）。有些团队甚至为此过程专门开发了自己的扑克牌。

我想提醒大家，坏习惯不能仅靠工具就能克服。你仍然可以将愚蠢的估算（在这里是范围）放入工具中。导致你养成坏习惯的相同压力，即使面对最新的工具，也会产生同样的影响，无论其底层方法论有多好。

McConnell 的《软件估算：揭开玄学的面纱》。这是该主题的权威著作。任何运行软件项目的人都应该拥有一本。

以下是一些估算软件的良好实践

1. 用户故事
2. 规划扑克
3. 故事点
4. 产品待办事项
5. 速度
6. 重新估算

什么是用户故事？

用户故事从客户（用户）的角度描述所需的功能。用户故事的描述传统上写在便笺卡片上，Ron Jeffries 用“卡片、对话和确认”这一绝妙的押韵来命名这三个方面。卡片可能是用户故事最显眼的体现，但它并非最重要。虽然卡片可能包含故事的文本，但细节是在对话中敲定的，然后通过确认来记录和验证。一个好的用户故事描述了所需的功能、谁需要它，以及功能将如何以及为何被使用。- 维基定义。

Bill Wake 为我们提供了 INVEST 首字母缩略词，表示各项应是独立的、可协商的、有价值的、可估算的、小的和可测试的。

为什么需要用户故事？

用户故事强调口头沟通。书面语言通常非常不精确，而且不能保证客户和开发人员对陈述的理解相同。例如，最近午餐时我在菜单上读到：“主菜可选汤或沙拉配面包。”这句话本不难理解，但却不然。我能从中选择哪一项？

1. 汤或（沙拉配面包）
2. （汤或沙拉）配面包

用于规划

用户故事的第二个优点是它们可以方便地用于项目规划。用户故事的编写方式是，每一项都可以估算出开发难度或耗时；而用例通常太大，无法给出有用的估算。此外，一个故事是在一个敏捷项目的单一迭代中实现的，而将一个用例拆分到多个迭代中（即使这些迭代通常比基于故事的项目要长）是很常见的。

谁来编写用户故事？

任何人都可以写用户故事。产品负责人负责确保存在一个敏捷用户故事的产品待办事项，但这并不意味着产品负责人是唯一编写它们的人。在一个良好的敏捷项目中，你应该期望每个团队成员都能写出用户故事示例。另外，请注意，谁写用户故事远不如谁参与讨论它来得重要。

规划扑克

真正有效的软件估算！！

如果你可以通过玩纸牌游戏来回答“我的软件需要多长时间才能构建完成，什么时候能完成？”这个问题，会怎么样？

不，我没有……让我们看看怎么做

1. 规划扑克归功于 Grenning，是一个相当新的发展（2002 年）
2. 规划扑克将专家意见、类比和分解相结合，形成一种令人愉快的估算方法，可以快速但可靠地进行估算。
3. 规划扑克参与者包括团队中的所有开发人员。
4. 产品负责人/业务负责人/业务分析师参与规划扑克，但不进行估算。
5. 有人（通常是项目经理）担任主持人。
6. 对于要估算的每个用户故事或主题，主持人会阅读描述。
7. 产品负责人会回答估算师提出的任何问题。
8. 所有问题回答完毕后，每位估算师会私下选择一张代表其估算的卡片。
9. 在每位估算师做出选择之前，卡片不会显示。
10. 届时，所有卡片将同时翻开并展示，以便所有参与者都能看到每个估算。
11. 此时估算很可能存在显著差异。
12. 如果估算存在差异，估算最高者和最低者解释其估算。
13. 重复此过程，直到估算者达成松散共识。
14. 共识数字是规模估算。
15. 团队将根据估算决定在给定迭代中可以完成多少工作，例如，根据上述估算，团队决定他们可以在为期一周的迭代中完成故事“X”。
16. 迭代完成后，如果团队成功交付了故事“X”
17. 我们可以假设团队每周可以交付 5 个规模等同的工作量，这被称为团队的“速度”（velocity）。
18. 换句话说，“速度”是团队在一段时间内交付的工作量。
19. 一旦知道了速度，就可以扮演预言家，回答“我的软件需要多长时间才能完成，什么时候能完成？”这个问题。
20. 在上述情况下，如果团队的速度是每周 5 个规模，那么可以预测团队应该能够在 3 周内完成工作。
21. 3 周的时间估算通过将项目总规模除以速度得出，即（5+8+2）= 15 / 5 = 3 周。

为什么它有效？

• 从事这项工作的人对其进行估算。
• 强调相对估算。
• 估算在一个数量级内。
• 减少锚定——每个人的意见都能被听到。
• 为开放讨论而建模——迫使思考。
• 它汇集了多位专家的意见来进行估算。
• 有点像“众包的智慧”。
• 非常 Web 2.0。
• 提高估算的质量。
• 估算师被同行要求解释其估算。
• 平均个体估算会带来更好的结果。
• 斐波那契数列——“黄金比例”。
• 无法解释，有点像“X 文件”。
• 它之所以有效，是因为它很有趣。
• 当你玩得开心时，事情总会顺利进行，不是吗？

副作用

• 对要完成的工作有更深入的理解。
• 设定期望。
• 实现提示。
• 高级架构和设计讨论。
• 估算的所有权。

故事点

• 估算工作的非常常见方式。
• 用于表示估算单位的名称。
• 源自将工作单位称为用户故事。
• 产生无单位但数值相关的数字。
• 一个 10 点的故事大约需要一个 5 点的故事两倍的时间。 

• 有三个主要好处 
• 强制使用相对估算。
• 让我们专注于估算规模，而不是持续时间。
• 将估算以我们可以相加的单位来表示。 
• 基于历史现实。
• 使用斐波那契数列——1, 2, 3, 5, 8, 13, 21, …  
• 易于使用和理解。

 

重要说明（作者：Martin Fowler）

• “故事点”是我现在听到的最常见的名称，但多年来使用过各种术语，通常带有强调其随意性的异想天开的名称。我特别喜欢 Joseph Pelrine 的“gummy bears”（软糖熊）和 Josh Kerievsky 的：“NUTs”（Nebulous Units of Time，模糊时间单位）。
• 这是一个斐波那契数列。
• 使用最高数字作为“太大”的意思是，一个大小为“8”的故事实际上意味着“8 或更多”。如果你这样做，在使用这个最高数字来预测完成时间等时要小心，因为“8”在最终被细分时可能会变成各种数字。明确说明它太大而无法估算，通常比使用一个虚假的标记数字要好。 

副作用 

• 如果你使用斐波那契数列（或类似的东西），它会限制估算故事的选项数量。
• 我认识一个只使用小数字的团队：1, 2, 3, 5 和 8。他们有一个参考故事，是 5。这使他们在进行规划扑克时能够轻松地快速决定故事的复杂性。
• 另一个副作用是，任何被评为 8 的东西可能信息不足，需要进一步细分。我严重怀疑如果他们使用的是原始小时数，是否会如此简单明了。

计划

给我六小时砍倒一棵树，我会花前四个小时磨斧子。——亚伯拉罕·林肯 

一个好的计划是

1. 清晰 
2. 可靠 
3. 使用过
4. 可用

为什么传统规划会失败？

• 计划不是适应性的。
• 关注活动——而不是特性。
• 从不提前完成。
• 迟到会传承下去。
• 依赖性。
• 计划不是优先驱动的。
• 风险更高。
• 投资回报率较低。
• 相信客户不会改变。
• 估算变成承诺。

是什么让规划变得敏捷？

• 规划不被视为项目的一个阶段。
• 关注业务优先级。
• 每个迭代都交付一些东西。
• 预期会发生变化，拥抱变化。
• 计划易于更正。
• 按功能而非按活动规划。
• 清晰的进度定义。
• 50% = 50% 的功能已完成。

首先，我们需要一个待办事项

为该列表添加价值。

估算和评估风险

优先级排序

现在已排序——我们准备好了！

冲刺

冲刺前

• 团队承诺以下内容
• 作为一个用户，我想看到我的余额。
• 作为一个用户，我想看到最近的交易。
• 创建冲刺待办事项。
• 他们将其分解为任务。
• 他们估算每个任务的时间。

跟踪进度

初始阶段

下一阶段

End

冲刺已完成。

速度

• 团队（或团队）在一个迭代中可以完成多少点？
• 易于衡量。
• 修复估算错误。
• 轻松反映项目状态。
• 规划中的主要参数。 

关于速度的警告。

• 不要为速度目标设定激励措施。
• 不要设定挑战性目标。
• 不要衡量个人速度。
• 不要将一个团队的速度与其他团队进行比较。 

软件估算的“罪恶”（参考 Fred Brooks 和 Steve McConnell）

常见错误

#1：在知道“它”是什么之前，就估算“它”需要多长时间才能构建。

 

#2：假设最可靠的估算来自声音最大的人……
假设销售部门比程序员更擅长估算软件项目……

#3：通过与过去的某个项目进行比较来创建新项目的估算……该项目超出了其估算（进行了大量加班……），并最终意识到你基于过去项目估算的结果而不是其实际结果来制定新项目的计划。

#4：创建假设没有人需要初步培训的估算……
或者参加会议……
或者被调去参与其他项目……
或者需要支持关键客户……
或者去度假……
或者生病……

#5：以很高的精度（例如，67.4 天）呈现估算，但这些估算仅以很低的准确度（±2 个月）为支撑。

混淆估算和目标。

• 设定目标是估算艺术的关键组成部分。
• 当你被要求提供估算时，确定你实际上是应该在估算还是在弄清楚如何达到目标。
• 这最好被视为一个使估算和目标协调一致的迭代过程。

说“是”，当你真正意思是“否”时。

开发者为什么会说“是”？

Fred Brooks 说得最好：“很难为一项没有量化方法、数据支持很少且主要由经理的直觉认证的估算进行有力、合理且可能冒着丢掉工作的风险的辩护。”

• 进度“谈判”。
• 软件开发者往往是内向且相对年轻的。
• 市场营销和销售人员往往比他们谈判的开发人员更外向，并且在组织中级别更高。

在不确定性之锥（Cone of Uncertainty）的早期阶段就做出承诺。

假设低估对项目结果没有中性影响。

帕金森定律。

“工作会膨胀到填满可用于完成它的时间。”作者：Cyril Northcote Parkinson

• 过度估算会让帕金森定律生效，即：帕金森定律会生效——即工作会膨胀以填补可用时间。
• 低估会造成许多问题，例如：
• 项目计划的有效性降低。
• 按时完成的统计几率降低。
• 糟糕的技术基础导致比名义结果更差。
• 破坏性的后期项目动态使项目比名义情况更糟。

估算准确性的影响。

固守估算科学，而你真正需要的是估算艺术。

• 科学已经得到很好的发展，并有软件工具的有力支持。
• 估算艺术更多地依赖于经验法则，仍需一些工作。

提供随口估算。

• 项目团队有时会被随口估算所困扰。
• 虽然这是一个简单的观点，但随口估算是项目团队最常见的错误之一。因此，为了成为一名更好的软件工程师，我们需要停止提供随口估算！

调查

这项调查于 2012 年 1 月的最后两周进行，有 149 名受访者。调查在 LinkedIn 的敏捷和精益讨论组、Yahoo Groups 的敏捷项目管理组，以及我通过 Twitter 发布。目的是了解敏捷人士如何在他们的项目上处理规划活动。

1. 常见的敏捷规划实践的价值是什么？

2. 前瞻性规划的采用率。

3. 协调会议的频率。

结论 

 

我想重复我之前文章中的几句话： 

一个好的敏捷团队会选择最适合他们的方法和技术实践。在尝试采用敏捷实践时，总会有很多借口说明为什么它行不通。那些理解该方法真正益处——并且真心希望进行转型的人——很可能会成功。那些寻找它为何会失败的原因的人——嗯，他们很可能会找到原因，并要么完全放弃努力，要么最终实践 Elisabeth Hendrickson 所说的“假敏捷”。

最好不要固守任何特定的方法论，因为公司和项目的需求/条件很可能会经常变化，如果你想让项目成功，就需要灵活地管理项目。没有单一的方法论是万能药，所以诀窍在于确定哪些方法适合你，并调整你的方法论以适应你的个人需求。这才是“敏捷”的根本所在。

• 获取《敏捷软件开发方法论》第一部分。.

参考文献

• 软件估算：揭开玄学的面纱（最佳实践（Microsoft））
• http://agile.dzone.com/users/drianmitchell (敏捷估算实践)
• http://agile.dzone.com/articles/agile-estimation-practice
• http://www.mountaingoatsoftware.com
• http://www.construx.com/
• http://en.wikipedia.org/wiki/Brooks%27s_law
• http://www.stevemcconnell.com/
• https://martinfowler.com.cn/
• http://www.wikipedia.org/