导入
估算的时机
了解在敏捷开发中进行项目估算的过程。
何时进行估算？
估算对项目至关重要。在项目初期，需要制定项目计划，包括根据合理的估算确定团队人数。估算用于判断客户期望的交付时间是否可行。在项目执行过程中，估算用于评估新增或变更工作项的影响，以监控范围的增长并进行重新规划。
因此，估算在敏捷开发中是一个持续的过程，通常应用于以下步骤：
项目启动阶段
需要进行初步估算，以提供项目的报价。在轻量级敏捷方法中，这一步并不总是被明确描述，例如Scrum或极限编程（XP）项目，它们从第一个迭代开始就直接实现工作项。而其他敏捷方法，如Smart、DSDM和特性驱动开发（FDD），则包含初始迭代，在此阶段确定待办事项列表中的工作项，完成估算，并生成报价和项目计划。
迭代过程中
在迭代期间，选定的工作项会进一步细化。用户故事被拆分为任务，Smart用例被详细展开。基于这些新获得的信息，进行估算以判断工作量是否适合当前迭代。由于信息的完善，总估算值也常常发生变化，进而影响预期工期。
遗憾的是，并非所有敏捷项目都会建立初始估算、报价和项目计划。
我们希望没有太多组织会在没有计划的情况下启动敏捷项目，尽管这个计划不像瀑布模型那样一成不变。
为什么估算如此困难？
尽管估算非常重要，但很少有项目能够成功交付可靠的估算结果，无论是传统项目还是敏捷项目。造成这一现象的原因有很多：
- 反向规划：许多估算并非基于实际可行性，而是基于期望的生产率。这种目标被用来倒推团队应交付的内容，往往导致不切实际甚至有害的结果。
...
项目的反向规划
- 需求变更：在进行初始估算时，很难预见到项目过程中逐渐变化或新增的需求。
- 自我高估：在为新项目提供估算时，我们倾向于认为这次会比以往表现更好。这种自信是否成立值得怀疑。
- 不测量，就不了解：估算生产力时，参考过往项目的经验非常有帮助。然而，现实中我们往往缺乏这些数据。很少有组织真正衡量自身的生产力。
- 优化过的经验数据：即使组织积累了历史数据，其价值仍存疑。这些数据常被人为调整以迎合最终结果。有多少工时被错误地记在培训和入职上？
- 瀑布模型的复杂性：在瀑布项目中，估算更加困难，因为每个阶段涉及不同类型的工作。
- 乐观的开发者：开发人员尤其倾向于过于乐观地估算。他们的估算可能比实际情况低20%。
- 新技术：许多项目采用创新技术，而根据定义，这类环境缺乏可借鉴的经验基础。
- 技术类比的局限性：当缺乏相关技术经验时，人们常通过对比已有技术来估算。但这并不总是合理。
注意：如果我们正在开发一个Android移动应用，能否像开发ASP.NET应用一样快速完成？
总而言之，做出可靠的估算并不容易。这自然引出一个问题：我们究竟该如何进行估算？大致有两种方式：
- 以小时（或天）为单位：将项目工作量按所需工时进行估算，通常结合工作分解结构。这种估算方式是绝对的。
- 以点数为单位：将项目的工作项相互比较，用“点数”表示相对大小或复杂度。这是一种相对估算，可以反映项目的总体规模。然后通过团队的速度（或称吞吐量）来判断完成这些点数需要多长时间，以及需要多少个迭代周期。