互联网全民创新的环境下，敏捷开发是大家常常挂在嘴边的一个词。但是，当认真讨论起来，却发现大多数人对敏捷的理解似是而非。尤其是一些关键的概念，大多来自于想当然的推断。点数（Points）大概是其中最容易混淆，最不容易从日常经验中直接推断的概念之一。

传统开发

传统开发中，项目经理用时间（天数或小时数）为单位来预测项目的进度。项目经理询问开发负责人完成项目大概需要的时间；开发负责人直接估算或与相应的开发人员沟通确定单项任务所需时间，并总和出整体项目大致需要的开发时间；项目经理根据开发负责人的估算进行项目进度计划。许多公司包括国外的公司都是按这个流程操作。

这个方法的最危险之处在于它是一个静态的监控方法。在项目开始初期，当一个任务出现正常范围内的调整或质量问题返工时，所多付出的时间被看成是一个个案，项目其它任务的估算时间并不会相应调整。对啊，为什么要调整？它们之间没有直接联系。这个任务需要调整，质量出问题也不代表其它任务会有同样的情况。实践证明，每个任务都会有相应的调整和质量问题。于是，每个任务多出来的时间逐渐累积，突然就发现赶不上进度了；一开始赶进度，就开始顾不上测试、版本管理、代码重组。于是，上线前需要赶未完成的技术点；上线后需要不停为之前忽略的质量管控买单。而且，上线后用户开始回馈，新的调整需求大量涌入，代码质量低下使得即便是看似微小的修改都需要更多的时间，效率极低。在慌乱中，代码质量管控再次被忽略。开发就是在修修补补的状态下跌跌撞撞地进行。一段时间后，代码的混乱积重难返，没有人愿意也没有人有能力继续开发。管理层与开发团队相互失去信任和尊重，只好推倒重来。而在推倒重来的过程中，新的项目经理和新的技术团队重复同样的流程，陷入同样的困境。

敏捷开发

当然，要完善地解决之上描述的问题，敏捷开发中包含的所有步骤：用户故事，行为（测试）驱动，冲刺计划，代码重组…都要到位。但是，点数法至少可以提供一个相对准确的项目规模和时间估量。

每次，当我要求项目经理以及开发团队用点数来估算工作量的时候，大家凭直觉的理解都是：这和时间法区别不大，不过是一个点代表几个小时，几个点就点数乘以小时数。很多团队甚至直接用小时数换算点数。最终的运作方法和陷入的困境与时间法并无区别。

点数法的其中一个最关键概念是基准点用时是可变更的。比如，一个项目的规模是10点，技术团队估算他们1天能完成1个基准任务点（对他们来说最容易完成的任务），也就是说项目需要10天能完成。然而，在运行基准任务时发现，在包括正常的调整和质量控制之后，其实2天才能完成1点，于是项目完成用时变成了20天。如果更进一步，实行更严格的代码及版本质量控制，四天才能完成1点，于是项目完成用时就变成了40天。从另一方面说，当团队合作经过磨合期进入正轨或引入更有效率的技术人员，完成1点的用时减少，总体完成用时也会相应缩短。点数法是一个动态的，要求实时监控的项目进度管理方法。传统的时间法并没有把项目调整的频繁程度，质量监控的要求，技术团队的人员调整和效率变化，沟通效率的变化等可变因素转化成可观测变量；点数法用基准点可变更用时来反应这些因素对完成时间的影响，相比起来，对开发效率的了解以及对工程时间的估算都更为准确。

点数法的另一个关键概念是项目规模的相对稳定。规模是开发团队整体根据一个任务的难度及工作量分析，基于基准点，给出的该任务的估算点数。当任务难度和工作量到了某一个程度，小时数估算会变得非常的不准确，没有人可以知道具体完成任务所需要的时间。但是，对一个有经验的技术团队来说，任务大致的规模还是可以确定的。业内，为了更直观地突出任务规模以及规模越大，任务复杂度和不确定性就越高的普遍特性，通常会使用黄金分割数列，也叫斐波那契数列（Fibonacci sequence）。该数列第0项是0，第1项是1。从第2项开始，每一项都等于前两项之和：0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233，377…也就是说，如果基准点为一，根据技术团队分析，一个任务的难度及工作量大概为基准工作量的4倍，就是5点；5倍，就是8点；6倍，就是13点…以此类推。根据点数法做出的项目规模估算，虽然也无法精确地预估项目实际完成的时间，但可以非常清晰地让项目经理和技术团队负责人看到任务的规模，有助于他们在进行项目计划安排时做出较合理的安排。

小结

没有一个技术团队可以精确地估算一个项目完成的时间，可变因素太多。但是敏捷开发的点数法以规模估算和动态监控的两个特点，比较有效地实现在项目运行期间实时调整项目完成的预期，比传统的时间法要准确，实用性更强。而且，点数法可以更有效地跟踪开发人员的实际工作效率，从另一个角度提高对项目进程的控制。