策略清晰的快速开发

Mickey准备领导他在Square-Tech公司的第2个项目（Square-Tech是报表的巨头）。他的前一个项目进行得不好。原计划要求项目小组12个月内交付Square-Cal 2.0版，但实际上花了18个月。项目组在开始的时候就已经认识到项目计划日期的紧迫性，因而项目一开始就处于“死亡行军”（Death March）的状态。经过整整18个月每天12小时、每周6～7天的艰苦挣扎，到项目结束时，6个小组成员中有2个退出，小组中最有实力的开发人员Bob从西雅图骑自行车出走，目的地不明。他从南达科塔的奥塔姆瓦发给Mickey一封明信片，一张他骑着一辆大轮自行车的照片，Bob说他不是退出，但没人知道他什么时间能回来。

Square-Cal 3.0版要在Square-Cal 2.0版上市的12个月后发布，项目收尾、总结、休假已经2个月了，Mickey准备开始新的尝试。离交付Square-Cal 3.0版还有10个月的时间。他约了上司Kim与他讨论项目计划，Kim可以帮助他为开发人员提供足够充分的工作条件。编写用户文档的John和负责质量保障（QA）的Helen也一同参加了讨论。

Kim说：“3.0版必须超过竞争对手，所以我们在这个项目上需要投入更大的力量。我想你们项目组可能还没有意识到，从上个版本开始我们公司已经落后了，这次公司准备全力以赴支持这个项目。我已经批准为项目组每个成员提供私人办公室、最新型的计算机以及免费的碳酸饮料，你觉得怎样？”

Mickey回答：“听起来很有吸引力，不过除此之外，由于所有开发人员都是有经验的，我想主要应该多提供一些激励和支持措施，让他们多些好处。我不想对他们进行微观管理，我想让每个开发人员参与负责系统的某一部分。上次，我们已经碰到许多接口问题，所以，这次我想花一些时间设计不同模块之间的接口，然后放手让他们各自去干。”

“如果这是一个10个月的项目，我们需要在第8个月的时候锁定软件，及时准备用户文档。”John说，“上次，直到项目结束，开发人员还在进行修改，令人尴尬的是，README文件有20页。用户手册在审查的时候总是被枪毙，如果能做到可视化锁定，你的开发方法听起来就很有道理了。”

Helen补充说：“我们也需要在可视化锁定的同时写出自动测试脚本。”

Mickey赞同可视化锁定方法。Kim随即批准了Mickey的总体步骤，并告诉他要保持大家步调一致。

项目开始后，开发人员对他们的私人办公室、新的计算机及碳酸饮料很满意，他们干劲十足地开始了工作，并主动干到深夜。

时间一个月一个月地过去，项目进展平稳，他们已经完成了早期的软件原型，继续进行编码设计。管理层面也一直在监督项目的进展，John几次提醒Mickey注意第8个月的可视化锁定承诺，搞得Mickey都有些恼火了。每件事情似乎都在顺利进行。

项目进行到第4个月的时候，Bob结束了他的自行车旅行，重新回到项目组，并带回了骑车旅行时产生的一些新想法。Mickey担心Bob能否在允许的时间内完成那么多的功能，但Bob承诺，无论有多大的工作量，一定按时完成任务。

项目组成员各自独立做着自己的工作，而随着可视化锁定日期的来临，他们开始进行代码集成。他们在可视化锁定最终截止日期前一天的下午2点开始工作，但很快发现程序不能编译，更不用说运行了。代码在编译时有几十个语法错误，而似乎每处理一个错误就会产生10个以上的新错误。他们直干到午夜也没结果，只好决定第二天再说。

第二天早晨，Kim约见项目组成员：“程序可以移交给文档和测试人员了吗？”

Mickey说：“还不行，我们还有些集成问题，可能今天下午就可以移交了。”项目组又工作了整个下午和晚上，但还是没能解决已经发现的所有问题，最后，他们只得承认无法预知集成需要多长时间。

他们整整花了2周时间处理这些语法错误，才得以使系统能够运行。当项目组比计划推迟了2周将阶段性定版的系统移交时，测试和文档人员迅速做出反应，拒绝接收这样的版本。“系统太不稳定了，不能编写文档。”John说，“系统每隔几分钟就会崩溃，同时，有太多的系统漏洞。”

Helen赞同：“系统太不稳定，你每选择一次菜单，系统就会瘫痪，测试人员根本无法完成测试报告。”

Mickey同意他们的说法，并表示他的项目组会全力解决这些问题。Kim提醒他们注意10个月的最后截止日期，并说这个产品不能再像上个产品那样延期了。

他们又花了1个月的时间解决产品稳定性问题，以使文档和测试工作能够进行。这时，距离10个月的最后截止日期只有2周时间了，他们只能更加拼命地工作。

但测试发现问题的速度远比开发人员解决问题的速度快，处理系统这部分的错误经常会导致系统其他部分的问题。已经无法按预计的10个月交付产品了。Kim召开了一个紧急会议，她说：“我看各位工作都很辛苦，但结果不够好，我已经为你们提供了各种尽可能的支持，但我并没有看到任何软件，如果你们不能迅速完成产品，公司将会倒闭。”

伴随着巨大的压力，士气逐渐低落。数月过去，产品开始稳定了，但Kim仍对项目组施加压力。有些接口的效率极其低下，要完成这些工作还需要几周的时间。

尽管Bob也在忙着工作，但他还是比项目组中其他人交付软件的时间晚。他的代码没有错误，但他对用户界面组件做了些修改，导致测试脚本和用户文档与之不匹配。

Mickey约见了John和Helen：“你们可能不高兴，但我们只能有两种选择，要么保持Bob的代码不变，重新进行测试并重新写用户文档；要么扔掉Bob的代码，彻底重写。Bob不愿重写他的代码，这个项目组也没人能做这件事。这样看来只能请你们修改用户文档和测试用例了。”经过一番争执，John和Helen勉强同意了Mickey的要求。

到项目结束时，开发这个软件整整花了15个月的时间。由于这些变数，用户文档的印刷错过了计划中安排的最佳时间点，Square-Tech在开发人员刻完盘工作后，又等了2周时间印刷用户文档才将产品交出公司，投向市场。产品发布后，用户对Square-Cal 3.0版反应冷淡，几个月的时间，市场份额就从第2位下降到了第4位。Mickey意识到他的第2个项目像第1个项目一样，超出项目计划时间50%。