- 快速开发（纪念版）
- (美)史蒂夫·麦康奈尔
- 4110字
- 2025-04-12 22:17:00
2.5 快速开发的权衡策略
相关主题
有关基于承诺方式的更多内容，请参考第8.5.1节和第34章。
本书中所列的快速开发方法不是唯一可用于现实工作的方法，一些项目也以其他不同的途径成功地进行了运作。这个途径就是聘请可能的最佳人选、要求一个对项目的总体承诺、授予更多的自主权、激励项目人员拼命工作，然后看着他们每周工作60、80甚至100小时，直到最后他们完（累垮）了或项目完（完成）了。基于承诺的这种快速开发方式一般是通过磨练、汗水和决心来实现的。
这种方式产生了有目共睹的成功，包括Microsoft NT 3.0和Data General Eagle计算机，毫无疑问，它是今天广泛采用的快速开发方法。对现金流敏感的新公司，用1个月的工资榨取人员2个月的工作是非常有利的。即使都使用以上方式，在为满足市场需求及时推出能为公司创造财富的产品，和在耗尽资金之前推出产品之间是有差别的。通过缩小项目组规模，可以减少沟通、协同和管理的负荷。如果实践中能够敏锐知晓涉及的风险和障碍，这种开发实践就是可以成功的。
不幸的是，这种方式很难仔细探询，通常会演变成“噩梦式编码”（code-like-hell），导致项目延长，而且似乎永远完成不了。这种方式是一种实现快速纠错的方式，同时也和其他纠错方法一样还有许多问题。贯穿本书，我对这种方式持批评态度，原因如下。
1．无法保证项目完成
有时它可以完成项目，有时完不成。导致完成或完不成的因素大多数是不可控的。当你负责完成一个项目时，有时可以获得计划的功能，有时不能，有时可以达到你的质量目标，有时达不到，而且这种方式很难控制特定产品的特性。
2．将导致长期激励问题
对基于承诺的项目，开发人员一开始就完全认识到怎样做才能满足项目承诺，他们会狂热地开始工作，加班加点。但是，当长时间的工作仍无法满足项目计划承诺要求时，他们被迫承认失败，变得士气低落。
一旦开发人员将全部身心投入到满足计划承诺之中并面临失败时，他们对进一步的承诺变得很勉强，他们会怨恨超时工作，再以后，他们只会用口头承诺而不会用心去承诺。项目将失去计划与控制。对于一个预计还需3周就可完成的项目，又做了6个月或更长的时间并不是件很罕见的事情。
3．不可重复
噩梦式编码方法即便成功一次，也不能为下次项目的成功打下基础。因为它将耗尽人力资源，所以更像是为以后项目的失败打下了基础。公司很难恢复由这样的项目造成的人员士气损失，而且这种项目通常伴随着大量的人员调整（见Kidder 1981，Carroll 1990，Zachary 1994）。
4．对非软件组织工作造成困难
由于是基于个人英雄，而非团队合作、协同和计划，噩梦式编码方法对于项目中的其他项目干系人无法提供有效的监控手段，所以即便你以很快的速度成功地开发出所负责的软件部分，你同样无法知道整个项目要花多长时间，也无法知道项目确切的完成时间。
由于与开发人员配合的其他部门，如测试、用户文档和市场部门等，做不出计划，所以有些来自于承诺方式的速度优点是很难界定的。在有噩梦式编码的项目中，由于不能从开发人员那里获得可靠的进度信息，会导致项目参与者脾气暴涨，项目组内人员与项目组外人员对立。对项目软件局部有利并不一定对项目整体有利。
5．人力资源浪费无度
参与项目的开发人员忘记了家庭、朋友、爱好，甚至是他们的健康，去促使项目成功。严重的个性冲突是普遍存在的现象，无一例外。勇于献身可以赢得战争或帮助人类登上月球，但无助于开发商用软件。极少例外，这种献身不是必须的：通过周密、理性、知识化的管理和技术计划，可以用少许的努力获得同样的结果。
表2-2总结了噩梦式编码方法与本书所倡导方法之间的某些不同。
表2-2 噩梦式编码方法与本书中方法的比较
数据来源：Rewards of Taking the Path Less Traveled（Davis 1994）
本书描述的方法是通过周密计划、有效利用时间并采用面向进度的实践来实现快速开发。使用这种开发方法，加班并不常见。当采用噩梦式编码方法时，项目还没有开始，通常就发现有堆积如山的工作，需要加班。有效开发通常会缩短平均计划进度时间。当它失败时，通常是由于人们放弃继续使用它造成的，而不是由于这种实践本身的失败。
简而言之，噩梦式编码方法要求有超常的献身精神保证，但得不到超常结果。如果项目目的是最快的开发速度而不是繁忙的加班，那么任何人都会更喜欢有效开发。
如果你精心阅读本书，将找到成功指导一个噩梦式编码项目所需的所有信息。人们的确可以将信奉本书的Dr Jekyll变成熟悉噩梦式编码的Mr Hyde。但就我个人而言，我不喜欢那种开发，因此不打算在此详述具体做法。
案例2-2
出场人物
Sarah（项目经理）
Eddie（老板）
Jose（新手开发）
George（资深开发）
策略清晰的快速开发
仍然是在完成Square-Cal 3.0项目的公司，Sarah承接了Square-Plan 2.0项目。Square-Plan是Square Tech的项目管理软件包，Sarah是技术主管。
在项目组的第一次会议上，她介绍了项目组成员，而后切入主题:“我在整个公司范围内收集了其他项目的总结报告。”她说，“我已经列出了足有一英里长的公司其他项目在运作中发生的所有错误。我将把这个单子贴到会议室里。我想在我们开始犯其中某个错误时，就在上面画一个标记。如果你们还知道上面没列出的其他错误或我们可能会犯的任何潜在的错误，请加在上面。我们不想重蹈覆辙。”
“选择你们参与本项目是因为你们每位都有开发技术基础。我想你们一定知道做好需求分析和设计以使我们能够不必返工而浪费时间意味着什么，所以，我要求项目组的每位人员都要用心工作，而不是辛苦工作。工作太辛苦会导致出现更多的错误，我们没有时间处理这些错误。”
“我也同时制定了配套的风险管理计划，我们面对的是一个具有挑战性的进度计划，所以我们不能让能够防止的风险发生。我们现在面临的最大的风险是计划的进度无法实现。我想我们应该在本周末再对进度计划进行一次评估，如果认为进度计划还是无法实现，我们将讨论提出一份更现实的计划。”
每位项目组成员都点头，对经历过“死亡行军”项目的人员来说，Sarah的话让他们长长地舒出了一口气。
一周后，Sarah约见她的老板Eddie：“项目组已经很仔细地审视了项目进度计划，Eddie，我们得出的结论是，我们只有5%的机会在项目截止日完成当前定义的功能。这是假设没有任何改变的情况，当然，有些事情总是要改变的。”
“真是糟透了。”Eddie说。Eddie在承诺按时交付产品方面有较好的声誉。“我们至少需要有50%的机会按时交付软件，并且我们还要能够针对今后12个月内市场的变化随时修正项目要求，对此，你有什么建议？”
“我们还没有完全对产品定型，所以，我们还是有一定灵活度的。”Sarah说，“但我认为即使根据目前的需求分析，我们也需要花10～30个月时间。我知道这个时间跨度是比较大，但这也对我们在产品完全定型之前的工作很有利。我们需要12个月后提供产品，对吗？我认为，可以考虑再加入一些开发人员，然后建立一个渐进交付计划，今后我们每2个月推出一个交付版本，而第1个交付版本定在第8个月末完成。”
“听起来不错。”Eddie说，“除此之外，我想对这个项目而言，功能比进度更重要。我会再找一些人员谈谈，然后我们再定。”
当Eddie再找到Sarah时，他告诉她公司愿意将软件计划时间延长到14个月，但还是希望实现所要求的功能。另外，为安全起见，可以采用软件渐进交付计划。Sarah感到轻松了许多，并说她认为这是一个很现实的目标。
项目经过初期的几周后，她的项目组已经建立了详细的用户界面原型。“错误列表”警告用户界面原型有时会影响项目自身的推进，所以，他们为原型工作设定了严格的时间点以避免原型拖延。随后，他们就原型所确定的候选功能与潜在的客户进行交流，并根据客户回馈对原型进行了几次修正。
Sarah继续维护她的风险列表，并确定了这个项目的3个主要风险，它们是：（1）可能导致大量重复工作和进度延期的质量低下风险；（2）具有挑战性的进度计划本身的风险；（3）因市场竞争，要求软件功能不断增加而导致的竞争功能风险。Sarah觉得质量低下风险可以通过渐进交付计划来消除。他们将在第8个月时将第1个交付版本送交到质量检测部门，他们会对软件按用例进行测试。
进度计划风险可以通过建立产品功能的优先级次序由项目组自己来消除。他们在14个月内会尽可能开发更多的功能，而通过每2个月交付1个版本，他们可以确保在需要的时候有东西可以交付。他们也对特别需要节省实现时间的几个功能进行了设计方面的决策，花较少的时间来实现这些功能不能认为是偷奸耍滑，它们应该被接受，因为这对降低进度计划风险具有重要意义。
项目组采用两种方式来消除竞争功能风险。他们花了大约5个月的时间开发项目设计方案，该方案包含了所有已定义原型的功能和其他一些他们认为应该包含在3.0版中的功能的框架。这种设计使系统更容易适应可能产生的各种改变，同时他们还分配出时间在第12个月时分析竞争对手的产品，修改原型，并在最后的2个月中实现必要的竞争功能。
在第6个月时，随着设计方案的完成，项目组制定了一组细化的里程碑标志，制定了到第8个月时，发布第1个可交付测试版本所遵循的原则与途径。第8个月交付的版本并不完善，但应该保证质量，这可以为下一步的工作打下坚实的基础。在项目组顺利交付第8个月的版本后，项目组又为第10个月交付的版本制定细化的里程碑标志，并使用同样的方法到达了第12个月的里程碑标志处。
在第12个月结束时，项目组按计划对竞争产品进行研究。竞争对手已经在第10个月时发布了一个好产品，它已经包含了一些Square-Plan 2.0出于竞争目的而需要包含的功能。项目组立刻将这些新功能加入到优先队列中，重新分配优先次序，并制定最后2个月的细化的里程碑标志。
几乎同时，Jose，一位新手开发人员发现了一种可以对产品对话框进行更优组织的方法，并将建议提交到项目组成员碰头会上。会上，资深开发人员George对此的反应是“这是一个非常好的想法，我认为我们应该采用这一方法修改我们的设计，但不是现在。Jose，对你来讲，进行这样的改变只是1天的工作量，但它会影响文档编制进度达1周或更多的时间，将其放到3.0版本中如何？”
Jose说：“我没想到对文档进度有这么大的影响。这是一个好的方法，我想请求在未来修改设计时采用。”
在到达第14个月的里程碑标志时，项目组按计划交付了终版软件。由于从第8个月开始测试时Square-Plan的质量就是优秀的，所以，文档在等待正式版软件交付期间，已经可以基于详细的用户界面进行编写了。文档与软件同步准备就绪。开发人员没有实现一些低优先级的功能，但他们实现了所有重要的功能。Square-Plan 2.0是成功的。