【转帖】Rupert工业公司:“朝晖”项目

你叫Robert，日期是2001年1月3日。在假期中，你和家人所度过的轻松时光使你恢复了精神，准备投入工作。你和你的开发团队坐在会议室中。部门的管理者召集了这次会议。
“我们有一些关于一个新项目的想法。”部门管理者（称他为Russ）说。他是一个容易激动的英国人，他的精力比聚变反应器还要旺盛。他雄心勃勃并具有紧迫感，但是他了解团队的价值所在。
Russ描述了公司了解的新市场机遇的基本情况，并把你介绍给Jane，负责定义用来抓住这个机遇的产品的市场管理者。
和你打过招呼后，Jane说，“我们希望尽快开始定义我们首要提供的产品。你和你的团队什么时候能和我谈谈？”
你回答到：“本周五我们会完成项目的当前一次迭代，在这之间，我们可以抽出几个小时和你谈谈。迭代完成后，我们会从团队中抽出一些人专门投入到你的项目。我们会立即开始招聘一些人来接替他们并为你的团队招聘新人。”
“好极了！”Russ说，“但是我希望你明白，7月份我们要在产品展览会上拿出一些东西展示，这很重要。如果我们到时不能拿出一些有意义的东西，我们就会失去机会。”
“我明白，”你回答道，“虽然我还不知道你打算做的是什么，但是到7月时肯定可以拿出一些东西来。我还不能马上告诉你那些东西是什么。无论如何，你和Jane将完全控制着开发人员的开发方向，所以你可以放心，到7月要去展示时，你会拿到可以完成的最重要的东西。”
Russ很满意地点点头。他知道这种工作方式。你的团队总是能让他了解并把握开发情况。对于你的团队会首先着手于最重要的工作并产生出高质量的产品这一点，他极有信心。
***
“那么Robert，”Jane在第一次会面时说到，“你的团队对被分开是怎么看的？”
“我们会怀念在一起工作的日子，”你回答道，“但是，我们中的一些人对于最近的一个项目相当厌倦了，并且期望有一些变化。你那边在做些什么呢？”
Jane微笑着说：“你知道我们的客户当前遇到了很大的麻烦……”接着她用了大约半个小时来描述问题以及可能的解决方案。
“好，请稍等一会儿。”你说道，“我需要把这搞清楚。”因此，你和Jane谈论了系统可能的工作方式。Jane的一些想法并没有完全成形。你提出了一些可能的方案。她对其中的一些表示赞同。你们继续讨论。
在讨论期间，对于所提出的每个新主题，Jane都编写了相应的用户故事卡。每张卡片都描述了新系统必须要做的事情。卡片堆积在桌子上，展开在你们的面前。当你们讨论这些故事时，你和Jane都会指着它们，把它们拿起来，并在上面做一些记录。这些卡片是有效的助记工具，你们使用它来描述一些刚刚成形的复杂想法。
在会谈结束时，你说：“好，我对你想要什么已经有了一个大体的认识。我和我的团队会对它进行讨论。我想他们会对各种不同的数据库结构以及表示格式进行一些实验。下次我们会面时，就会有一个团队，并且我们会开始确定系统最重要的特性。”
一周后，你新建的团队和Jane会面。他们把现在的用户故事卡铺开在桌子上并开始研究系统的某些细节。
会议非常有生气。Jane把故事卡按照它们的重要性排好。对于每一个故事都进行了大量的讨论。开发人员关心的是要保持故事足够地小，这样便于估计和测算。所以他们不断地要求Jane把一个故事分成几个小一些的故事。Jane关心的是每个故事都要有一个清晰的商业价值和优先级，倘若她对故事进行了分割，她就会保证这一点。
故事堆积在桌子上。Jane在编写它们，不过，在需要时开发人员会在上面写上注释。没有人试图去捕获所谈论的每一件事情。故事卡不必捕获所有的东西；它们只不过在会议中起到提示作用。
当开发人员对故事较满意时，他们就开始编写对它们的估算。这些估算很粗糙并且只是一种预算，但是它们却使Jane对故事的代价有一个概念。
会谈结束时，明显还有许多故事可以讨论。同样，你们也清楚地知道已经明确了最重要的故事，实现这些故事需要几个月。Jane结束了会议，她带走了故事卡并承诺明天上午会拿来一份关于第一次发布的方案。
***
第二天早上，你又召集了会议。Jane挑选了5个故事卡，把它们摆放在桌子上。
“根据你们的估算，这些故事卡代表着理想情况下一周的工作量。上一个项目的最后一次迭代在3周内完成了这些工作。如果可以在3周内完成这5个故事，我们就能够把它们演示给Russ看。这样，他就会对我嗯的进度感到非常满意。”
Jane 在催促着。你从她脸上腼腆的表情可以看出她也知道这一点。你回答道：“Jane，这是一个新团队，从事的是一个新项目。期望我们和前一个团队具有同样的开发速度有点专横了。不过昨天中午我和团队谈过，事实上，我们都同意把最初的速度设定为每3周完成这么多工作。所以在这个事情上你非常幸运。”
“还请记住，”你继续说，“现在，有关故事的估算以及设定的速度都是推测出来的。在做计划时我们了解得会多一些，在实现时了解得还要再多一些。”
Jane透过她的眼镜看着你，好像要说，“在这里到底谁是上司？”接着她笑着说，“好的，不必担心，现在我已经知道了规则。”
Jane接着把另外15张故事卡放在桌子上。她说，“如果我们到3月底能够完成所有的这些故事卡，我们就可以把系统移交给我们的beta版测试客户。那么我们会从他们那里得到很好的反馈。”
你回答说：“好，我们已经定义了首次迭代，并且具有了以后3次迭代的故事。这4次迭代可以完成我们的首次发布。”
“那么，”Jane说，“你们真的能够在接下来的3周内完成这5个故事吗？”
“我确实不知道，Jane。”你回答道，“我们来把它们分解成任务，看看能得到些什么。”
于是，在接下来的几个小时中，Jane、你和你的团队把Jane为首次迭代挑选的5个故事中的每一个都分解成小任务。开发人员很快就认识到某些任务可以在故事间共享，并且其他一些任务具有一些可以加以利用的公共点。很明显，开发人员的头脑中已经出现了一些可能的设计。他们不时地结成讨论小组并在一些卡片上勾勒出UML图。
很快，白板就被任务充满了，一旦实现了这些任务，就完成了本次迭代中的5个故事。你开始了签订过程，说道：“好，我们来签订这些任务吧。”
“我做初始的数据库生成，”Pete说，“在最近的一个项目我做的就是这个，这看起来并不困难。我估计它需要两天时间。”
“好，那么我做登录屏幕。”Joe说。
“噢，该死！”Elaine，团队的一个新成员，说道，“我从来没有做过GUI，我有点想做这一个。”
“哦，年轻人真急躁。”Joe贤明地说，并朝你使了个眼色，“你可以来协助我，年轻人”，她对Jane说，“我认为我需要大约3天完成它。”
开发人员一个接一个地签订了任务并对它们进行了估算。你和Joe都知道让开发人员自愿选择任务要比任务分配给他们好。你也充分地了解你不敢质疑任何一个开发人员的估算。你了解这些人，并且信任他们。你知道他们会尽最大努力的。
开发人员知道，他们签订的任务不能超过在他们参与的最近的一次迭代中所完成的任务。一旦开发人员关于本次迭代的时间表安排满了，他就不再签订任务。
最后，所有的开发人员都停止签订任务。但是，当然，白板上仍剩有任务。
“我就担心这会发生，”你说：“好，现在只有一件事情要做，Jane。我们在这次迭代中做的过多了。我们可以去掉哪个故事或者任务呢？”
Jane叹了口气。她知道这是唯一的选择。在项目一开始就加班工作是非常愚蠢的，并且出现这种情况的项目也不会成功。
于是，Jane开始去掉最不重要的功能。“嗯，此时，我们还不是真正的需求要登录界面。我们完全可以在登录后的状态中启动系统。”
“胡说！”Elaine叫道，“我实在是想做这个。”
“耐心点，急性子，”Joe说道，“只有等密封离开蜂箱后，享受蜂蜜时才不会蛰肿嘴唇（欲速则不达）。”
Elaine显得很困惑。
每个人都显得很困惑。
“那么……”Jane继续说道，“我觉得我们也可以去掉……”
于是，任务列表渐渐地变少。失去任务的开发人员在剩余的任务中又签订了一个。
商谈的过程不是没有痛苦的。其中有几次，Jane显示出了沮丧和急躁。有一次，当局势特别紧张时，Elaine自愿要求“超时工作来弥补时间的不足。”当你正打算纠正她时，还好，这时Joe看着她说：“一旦你走上了错误的道路，它就会永远控制你的命运。”
最后，终于确定下来了一个Jane可接受的迭代。这不是Jane想要的。事实上，它比Jane想要的要少得多。但是这是团队觉得他们可以在接下来的3周中可以完成的东西。并且，毕竟仍然在迭代中完成了Jane想要的最重要的事情。
“那么，Jane，”你在会谈接近尾声时说，“你何时能够提供验收测试呢？”
Jane叹了口气。这是事情的另一个方面。对于开发团队实现每个故事，Jane必须提供一组验收测试来证明它们可以使用。并且团队远在迭代结束前就需要这些验收测试，因为它们会明确地指出Jane和开发人员对系统行为认识上的差异。
“今天我会提供给你一些测试脚本的例子，”Jane许诺道，“此后的每一天，我都会增加一些。到迭代的中期，你就会拥有完整的测试集。”
***
迭代在周一早晨开始了，我们开了一个急速的类—职责—协作者（CRC）会议。到上午10点左右时，所有的开发人员都已经组合成对，并在快速地编码。
“现在，年轻的学徒，”Joe对Elaine说，“你该学习一下测试优先设计的技术！”
“哇，这听起来相当不错。”Elaine回答道，“你是如何做到的？”
Joe微笑了一下。显然，他已经预见到了这一刻。“年轻人，现在代码做了些什么呢？”
“嘿？”Elaine回答道，“它根本什么都没有做，还没有代码呢。”
“好，考虑一下我们的任务。你能想起一些代码应该做的事情吗？”
“当然可以。”Elaine带着年轻人的自信说道，“首先，它应该链接到数据库。”
“那么，要链接数据库，必须的东西是什么呢？”
“你说话真是古怪，”Elaine笑着说，“我认为我们必须要从某个注册表（registry）得到数据库对象，并调用其Connect（）方法。”
“哈！敏锐的年轻奇才。你正确地察觉到了我们需要一个对象，在该对象中我们可以缓存（cacheth）数据库对象。”
“‘cacheth’是一个真实的单词吗？”
“在我说出它时，它是的！那么，我们可以编写哪些我们认为数据库注册表应该通过的测试呢？”
Elaine叹了口气。她知道她必须合作下去。“我们应该创建一个数据库对象并用Store（）方法把它传递给注册表。然后，我们应该能够使用Get（）方法把它从注册表中取出来并证实它就是上一个对象。”
“哦，说得对，我的年轻捣蛋鬼！”
“嗨！”
“那么，现在，我们来编写一个测试函数来检测你所说的情形。”
“但是，我们不应该先编写数据库对象和注册表对象吗？”
“啊，你还有许多东西需要学习，没有耐心的年轻人，先编写测试。”
“但是这甚至无法编译！”
“你肯定？如果可以编译怎么办呢？”
“嗯……”
“先编写测试，Elaine。相信我。”
于是，Joe，Elaine以及所有其他开发人员都开始编写他们的任务，每次一个测试用例。他们工作的房间中充满了结对人员之间交谈的嗡嗡声。嗡嗡声不时被告呼声中打断，这些高呼声就是某一对人员完成了一个任务或者通过了一个困难的测试用例时所发出来的。
在开发的过程中，开发人员每1～2天就更换结对伙伴。每个开发人员都会了解所有其他人做的东西，因此关于代码的知识就广泛地在整个团队中传播。
每当一对人员完成某个重要的东西，不管是一个完整的任务或者仅仅是任务的一个重要部分，他们都会把完成的东西和系统的其余部分集成起来。这样，代码基每天都在增长，并且集成的难度被减少至最小。
开发人员每天都和Jane进行交流。每当他们对系统的功能或者验收测试用例的解释有疑问时，都会找Jane。
Jane很好履行了她的诺言，平稳持续地给团队提供验收测试脚本。团队用心地理解这些脚本，从而对Jane期望系统做的东西有了更好的理解。
到第二周初时，所完成的功能已经足以演示给Jane。Jane热切地观看着，演示通过了一个接一个的测试用例。
“这真是太棒了，”当演示最后结束时，Jane说道，“但是这看起来好像不到1/3的任务。你们的速度比预期的慢吗？”
你皱起眉头。你本来想等待一个合适的时机把这告诉Jane，但是现在她却提前提出了一个问题。
“是的，很遗憾，我们比期望的要慢一些。我们使用的新应用服务器配置起来很费劲。并且，还得常常重新启动它。每次即使我们对它的配置做了最微小的更改，都必须重新启动它。”
Jane用怀疑的眼光看着你。上周一商谈中的紧张状态还没有完全消散。她说：“那么，这对我们的进度意味着什么呢？我们不能再落后进度了，绝对不能。Russ会很生气的！他会惩罚我们所有人，并为我们增加一些新人手。”
你一直看着Jane。这样的消息是没有办法以令人愉快的方法说出来的。于是你完全不假思索的说道：“看，如果事情还像这样进行下去，那么到下周五时，我们将不能完成所有东西！现在我们是有可能找出一条可以快一些的方法的。但是，坦白地说，我不会依赖于它的。你应该考虑一下从迭代中去掉1个或者2个任务，而又不破坏给Russ的演示。无论如何，我们都会在周五进行演示的，并且我认为你不会想让我们来挑选去掉哪些任务。”
“啊，看在上帝的面上！”当Jane摇着头大步离开时，几乎无法抑制住喊出最后一句话。
不止一次，你对自己说，“从来没有人敢向我保证项目管理会是容易的。”你非常肯定这也不会是最后一次。
***
实际的情况要比你期望的稍好一些。事实上，团队确实从迭代中去掉了一个任务，但是Jane做了明智地选择，所以给Russ的演示很顺利。
Russ对进度没有太深的印象，但是他也没有感到沮丧，他只是说：“相当好。但是记住，我们必须能够在7月的展览会上进行演示，如果以这样的速度的话，看起来你们不能完成所有的要展示的东西。”
Jane的态度在迭代完成后有了很大的改善，她回答Russ说：“Russ，这个团队工作得很努力，也很好。到7月时，我确信我们会演示一些最重要的东西。它不是所有的东西，并且其中的一些可能没有真正的实现，但是我们会有一些东西的。”
虽然刚刚结束的迭代很费劲，但是它却校准了你们的开发进度。接下来的迭代好了许多。这并不是因为你的团队完成了比上一次更多的任务，而只是因为不必在迭代的中期去掉任何的任务或者故事。
到第四次迭代开始时，一个自然的开发节奏建立起来哦。Jane、你以及开发团队都可以准确地知道彼此期望的是什么。虽然团队工作得很艰苦，但是开发速度却是可持续的。你确信团队能够在一年或者更长的时间内保持这个速度。
在进度方面几乎没有出现什么问题；但是在需求方面却非如此。Jane和Russ常常检查逐渐增长的系统并对现有的功能提出一些建议和更改。但是任何一方都知道这些更改是花费时间的并且必须要列入计划。因此，更改没有导致对任何人期望的违背。
在3月，你们给董事会做出了一个该系统的较大型的演示。系统功能非常有限，还不足以拿到展览会上去演示，但是进展却非常稳定，给董事会留下了相当深刻的印象。
第二次发布甚至比第一次还要顺利。现在，团队已经找到了一个可以自己执行Jane的验收测试脚本的方法。他们同样也对系统进行重构，直到确实可以容易地向某个增加新特性以及更改原有的特性。
6 月底完成了第二次发布，并拿到展览会行。系统的功能要比Jane和Russ原本想要的少一些，但是它确实演示了系统最重要的特性。虽然展示会上的客户注意到了某些功能还没有实现，但是在总体上却给他们留下了深刻的印象。你、Russ以及Jane在从展示会上返回时都面带笑容。你们都仿佛觉得这个项目是一个胜利者。
事实上，许多月以后，Rufus公司和你们进行了联系。他们曾经为了他们的内部业务开发过一个类似的系统。经历过一个死亡的项目后，他们取消了这个系统的开发，并和你们商谈有关在他们的环境中使用你们的技术的授权许可事宜。
情况确实在不断变好！