估算完成百分比是很难的。好的敏捷团队通常会问另一个问题：我们完成了吗？
为什么敏捷团队每一个迭代都会非常重视事情是否完成？
敏捷过程会非常重视事情是否完成，这一点也不奇怪。因为敏捷宣言中有这么两点：
1. 经常交付可工作的软件
2. 可工作的软件是进度的首要度量标准
而且，敏捷团队每一个Sprint都试图完成一个可能的发布。并且在敏捷过程中，正因为完成工作是如此的重要，所以会促使团队去建立完成的定义，来明确怎么样才算完成。
一些敏捷团会每个迭代都会花一些时间用于将用户故事分割到足够小，小到刚好可以在一个迭代内完成。
那么为什么敏捷团队要如此重视工作是否完成呢？
很难估算进展
敏捷团队重视工作是否完成是因为软件开发团队那有名的很难估算进展。例如：现在我正在写一个博客，我估计我已经完成了2%，但有可能是3%，亦或是4%，谁知道呢？
90% 综合症
估算软件开发项目的进展实际上是很困难的，这也导致软件项目总是受90%综合症的苦。意思是说，软件项目已经完成了90%待办事项的90%的工作。
当你问一个开发人员完成了多少时，他们会告诉你：“90%”。一个星期后，你再一次问他们进度，你期望听到他们说工作已完成了，但是这个开发人员仍然告诉你的是：“90%”。
为什么会这样呢，是因为这个开发人员意识到项目范围变大了，不仅仅是因为干系人追加了工作，也因为研发人员并没有预料到所有的需求点
项目早期，开会人员会认为工作任务的大小是固定的。但随着项目逐渐深入，开发人员会意识到任务的大小比预期的要大。并且会越来越大。
虽然开发人员苦于90%综合症，但实际上却是有进展的，只不过因为问题的范围不断在扩大，导致他们总是维持在90%的进度。就如下图所示：
因为他们往往不能预料到到底有多少的工作量要作，直到他们正真开始做这些工作。
一个典型的例子：开发Windows系统下的Word应用。
作为一个例子，我们细想一下微软为Windows系统开发Word应用。这个项目启动时间是1984年9月，并且预估在12个月内完成。项目开始9个月后，研发团队又预估还需要13个月才能完成。又过了一年，研发团队又预估还需要11个月。项目开始差不多三年后，Word应用依然预估还需要1年的时间才能完成。最后Word应用总共花费了5年零3个月才最终发布。
那么敏捷团队又是怎样做的呢？
一个好的敏捷团队知道估算完成百分比其实是很困难的，所以他们将问题简化，与其问“我们完成这个特性的百分之多少了？”不如仅仅问他们“我们完成这个特性了吗？”
所有的工作将被分成两类：已完成，或者未开始。
那些被认为是完成的工作，都必须完成团队约定的“完成的定义”。就跟踪进度而言，那些未完成的任务不妨认为它还没有开始。
三个好处
单纯的将工作分为两类（完成和未开始）可以让敏捷团队有如下三点好处：
1. 团队成员不需要回答到底完成了多少工作，从而节省了时间。
2. 它提供了一种悲观的进度估算。因为部分完成的工作是不计算功劳的（意思是如果没完成，进度条就没有变化），所以我们的工作速率就会显得稍为低调一点。这样一来就不会再出现上面微软开发Windows的Word应用一样的高估进度的事情。
3. 它鼓励研发团队选择小的，容易完成的，产品待办事项。因为小的事项更容易在一个迭代内完成，并且当他们没有完成时也只等于少部分不算数的工作，团队会直观的倾向于更小的事项。
依照敏捷宣言所提到的，敏捷团队强调经常交付可工作的软件并且使用可工作软件作为进度的首要度量标准。专注于快速的将未完成的工作完成可以帮助团队按照敏捷宣言所说的那样子去开展项目。
相关文章
