敏捷的底线

过去的四年以来，软件业一直在努力的追赶着像是极限编程这样的敏捷方法的步伐。它们有什么好处呢？能奏效么？我们是不是应该去相信这些关于它们的传言呢？我们是不是也应该在项目中进行尝试？这些结论值得信赖么？

刊物、文章都在对应用敏捷方法所带来的难以置信的效果大肆的进行渲染，也有一些文章把敏捷方法贬损为使得软件开发倒退回石器时代的方法。我们听说过人们为此而取得的了不起的成就，也听说过其他一些人告诉说敏捷让他们的项目走近灾难。

唉！

底线其实是这样的。敏捷方法是关于如何去管理好软件项目的，仅此而已。敏捷方法是用来提供给管理者们所需数据，以至于做出管理上的决策。

你该如何管理一个软件项目？大多数的项目管理者都清楚去管理一个软件项目更多的时候不是在用科学的方法，而是随性。为什么会这样？因为获取能切实反映项目的数据非常困难。

在我们为一个项目取好名字之前，在我们为项目收集需求之前，在我们挑选出适合的团队之前，我们需要清楚的第一件事情就是最终期限。最终期限的定夺很大程度上是出于业务上的考虑：或许股东大会正好要在那时候召开；或许在那天会有个内部展示；或许我们的资金只够用到那个时候。不管原因是什么，时间的确定是出于业务原因，并非技术因素。

此外，一旦期限被采纳，就不能再变动了。唯一能改变此期限的方法就是延迟。简而言之，最终期限是不能动了。团队可能会做出一些估算来说明最终期限是无法达成的。但估算是个说不清道不明的东西，几十年年来的数据告诉我们，我们在估算上做的有多么糟糕；几十年来数据也在告诉我们，我们一直都还对它抱有幻想。大多数的开发团队都会用某种方法进行估算，并令其符合最终期限。

管理者们已经知道了最终期限，也掌握了达成它所需的估算，下一步就是做计划了。他们可能会绘制一个PERT图（译注1）或是GHANT图（译注2），这些图表向他们展示出了所有估算出的任务，以及它们的开发者是谁。这些图表清晰地向他们展示出他们是能够按时达成最终期限的，大家都很高兴。

我其实不说你们也知道接下来发生了什么：任务比预算要花更多的时间来完成；他们发现了之前没考虑到的一些额外任务；几周之内图表就成了废物。它可能还会呆在墙上一段时间，一天比一天的更加与事实脱离。

更糟糕的是需求发生了变化。我们丢掉了客户X，于是我们也不再需要功能F了。我们可能赢得了客户K，但随之需要新添上功能G。

管理者们可能会要求绘制一个新版本的图表挂在墙上，但他们依然坚持原先的最终期限不变。他们知道业务上需要这个项目于最终期限前达成。新计划当然会展示出项目会延迟，或许还是不要制定这个新计划的为妙。

管理者们经常会把施加压力或是使用某种激励办法作为他们的法宝。他们会警告开发人员如果错过最终期限会有什么恐怖的事情发生，然后他们就找出一些有诸如攀岩之类的鼓舞士气的图画挂在墙上，用来激励他们完成项目。他们会在开发人员之中走动，并且询问他们事情完成的怎么样了，于是开发人员回应说：“很好！”，再然后，管理者们就回到了他们自己的办公室去祈祷顺利。

没错，我是在夸大事实，不过我相信你们中的大多数都曾经在做项目的时候见到过上述的某些情形。当然，我本人也曾遇到。

运用数据进行项目管理

如果管理者们拥有真实的数据并用来管理项目会怎样？如果挂在墙上的是它呢？

这个图表展示出每周有多少任务做完了。任何人都能从中看出这个团队大概平均每周做完45点工作。这是很有力的数据，但还不够。如果我们还在墙上挂上了如下的图片会怎样？

这张图表展示出，每周还剩下多少任务待完成。你可以看出这条线是怎么样下滑的，还能看到曲线中的反复。这可能是因为增加了新功能，或是开发人员重新估算的某些任务。

如果我们在墙上挂上了这两幅图，那么任何人都能观察它，并且看出这个项目大概还需要八、九周才能完成。

有了这样的数据，你就可以管理项目了。你能看出团队工作的有多快，可能发布的日期到底会在什么时候。并且，你可以在项目一开始就看到这些，使用这些数据你可以做决策来扩充编制，减少功能，或是甚至改变最后期限。

没有这些数据，你就只能祈祷，况且必然会在很晚的时候才发现问题，然后高呼补救晚矣。但如果你拥有这个项目的真实数据，就能及时地做出复杂的决策来进行补救，就可以管理项目产生良好结果。

采集数据

我们该如何采集这些数据？这就是敏捷方法所谈论的内容，敏捷方法教会我们一些采集数据的方法，然后我们就可以把它们挂在墙上了。

经由敏捷方法中的极限编程方法所指导的项目能把项目分拆成很多非常小的可发布件，我们称之为“用户素材”。每个素材可能需要一个人大约一周的开发时间。我们清楚的知道我们的估算能力都很糟糕，也明白需求将会改变，但又不得不去估算，那就让我们从这些小剂量的用户素材开始吧。

我们通常会随意的选取某些用户素材，然后尽可能准确地去估算。有的人喜欢用确切的开发天数来衡量，有的则喜欢用点数。比如说，我们可能会估算开发一个关于用户登陆的素材耗时3点，而用户注销的素材耗时2点。或许保存功能的素材是5点，而撤销的是6点。我们不在乎具体这些的“点”代表多少真实的时间，关心的是一个3点的素材所消耗的时间是6点的一半。

接下来，管理者和开发人员们对下周的目标达成了共识。打个比方说这个目标需要66点，团队就会努力在下周完成这66点的工作。管理者以及客户们（译注3）选出了工作量为66点的用户素材，然后由开发人员去实现。

我们当然不擅长估算，所以周末的时候我们会发现只完成了40点的工作，剩下的26点会被重新加入到待完成素材中。的确有些失望，但现在我们知晓了先前所不知道的东西，现在我们明白了我们一周只能完成40点左右的工作。于是从下周开始，管理者以及客户们就会选出40点的用户素材。

这回事情有所好转，到星期三的时候我们就已经完成了38点工作，而且某些开发人员已经做完了他那部分。于是我们又选出了另外的一些用户素材让他们去做。到周末的时候我们总共做完了45点的工作。于是下周我们就会选出45点的素材，以此类推。

从墙上挂着的图表中很容易看出当前的工作状况。每周我们都会在图上绘制一个条目来表示出上周我们完成了多少点，每周我们都会算出还剩下的用户素材数量，并且也会在相应的图表中绘制出来。基于我们最近的经验，我们也会重新来评估剩下的这些用户素材。因此，我们就能保证墙上的图表尽可能准确、及时地反映情况。

通常在项目过程中会碰到这样的情形：我们发现一些工作任务无法被拆分成小剂量的用户素材；也还有这样的说法：诸如那些基础架构的事情要先做，而且要花上一周以上的时间来完成。这些说法都有失偏颇。一个又一个团队告诉我们整个复杂的项目都可以被拆分成很多微小剂量的用户素材；一个又一个团队也告诉我们基础架构不是在开始一下子搭建起来的，而应是一周周的逐渐增长起来的。

测试驱动开发

还有一种谬论是：数据是很容易掺水的。开发人员很容易告诉说他所负责的用户素材已经“做完了”，但实际上还没有。这是一种惯用招数，他们会把空函数或是只实现了很少的函数提交上去，用来骗过开发进度的检查。而实际上，不能工作的函数会被汇报成是个bug，因而并没有拖延开发进度。（相信我，维基尼亚（Virginia），真的有这么干的团队！）

测试驱动开发，特别是极限编程实践中的验收测试，给出了这个问题的解决之道。当管理者和客户们挑选待开发的用户素材的时候，他们也必须同时与QA一同合作，并且构建出自动化验收测试。除非是通过了验收测试，否则就不能说此用户素材已经做完了。（可以访问一个免费的验收测试工具http://fitnesse.org）这种实践方法让管理者和客户们能够控制“做完了”的定义。

控制“做完了”的定义意味着管理者们也控制了图表上所展现数据的有效性。当图表上展示出上周有45点工作做完了，这就是说这45点工作被证明是做完了，因为这些用户素材通过了管理者和客户们所定义的验收测试。因此，管理者们能够信任这些图表上的数据，并且可以依靠这些数据来帮助他们做出管理上的相关决策。

起初，要为所有的用户素材都编写出验收测试确实有些困难，这些难处主要是围绕者如何测试GUI、设备驱动，还有编写这些测试所要额外花费的时间上。可是，获悉到这些图表数据的有效性以及它所带来的效益，通常这种动机就足以刺激他们去解决这些问题了。管理者们通常为了追求达到这种可预知度而甘愿付出高昂的代价，况且，回报也是很可观的。一旦测试实现了自动化，它们就再也不用通过人工方式来运行了。人工的测试成本可是相当昂贵的。

结论

诸如极限编程这样的敏捷方法每一、两周就能提供出可靠的数据，而管理者们就可以运用这些数据来为此项目的做出管理上的决策。他们可以运用数据来预测项目何时能完工，或是下个发布会在什么时候；他们可以运用数据来做出扩充编制或裁减人员的抉择；他们可以运用它们来达成最终期限并让成就客户的预期。

产品研发中的这些数据才是敏捷方法的最终底限。这些数据是敏捷存活的基石，如果你正在使用敏捷方法，却没能用到过这些数据，那你所做得就不是真正意义上的敏捷。

译注：

1，PERT，计划评审法，全称为Program Evaluation andReview Techniques。PERT诞生于20世纪50年代，主要用于简化大型和复杂项目的时间管理。项目中的每项活动都被赋予最好、最坏和最有可能三项的时间估算。通过这些估算可以计算出平均的完成时间。而平均完成时间用来计算出关键路径时间和整个项目的期望完成时间。关于PERT的详细内容可参见http://en.wikipedia.org/wiki/PERT。

2，GHANT，甘特图，原词应为Gantt，或许是Bob大叔打错了这个词：）。甘特图是一种用柱形或是条形统计图来展示项目进度的常用方法。甘特图展示了项目中活动的起始和终结时间。关于甘特图的详细内容可参见http://en.wikipedia.org/wiki/Gantt_chart。

3，客户，XP强调客户和开发人员在一起紧密地工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或是团体。有时，客户是和开发人员同属一家公司的一组业务分析师或是市场专家。有时，客户是用户团体委派的用户代表。有时，客户事实上是支付开发费用的人。但是在XP项目中，无论谁是客户，他们都是能够和团队一起工作的团队成员。

本文是Uncle bob发表于2003年5月的文章，作者已授权翻译。

（原文链接网址:http://www.objectmentor.com/resources/publishedArticles.html; Robert C. Martin的英文blog网址：http://www.butunclebob.com/ArticleS.UncleBob）

Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。