项目管理案例库.doc

附件软件项目管理课程教学案例库的构建项目案例1 软件开发过程定义出现的问题-组织内没有定义和文档化且易于理解的软件开发过程许多软件开发组织，没有完全包含一个已定义的、可重复的、可预测的软件开发过程。这样的结果通常极大地增加了项目在预测和控制进度、成本、功能与质量等主要因素上的风险。一项目案例 在软件开发项目中富有经验的大多数人都对遵循定义完善的、文档化的软件开发过程的重要性有良好的意识。他们能回想起所经历问题的许多例子，这些例子都是第一手材料，是由于项目所遵循的过程定义很差，或者忽视了以前项目中得到的教训而导致的。 下面关于软件项目的小案例中具有全部“正当”的意图，但在定义和文档化软件开发过程时都忽视了某些重要的问题。当你读完这个案例时，问问自己是否在你过去的项目中预见到这些问题了？而且，这些问题中的许多部分，你在当前从事的项目中是否已经把它们作为与过程相关的问题沉痛警示了呢？ 开发组织已运作7年了，在7年中，开发了大量的产品，并交付给用户使用。在组织内洞察力敏锐的人认识到所有的项目都超期并超出了预算，一些项目只是超出了一点，但大多数项目都严重超支或超期。而且，所有的项目都经历了数量级比必要或预想都大得多的质量问题。然而，尽管进度、预算和质量问题经常困扰着项目，但整个组织仍继续发展壮大，即使产品不像期望的那样好，但产品仍继续销售。 在给定时间内，几个项目都在开发中。应注意到组织内没有定义和文档化易于理解的软件开发过程。每个项目或者从零开始定义自己的软件过程，或者部分遵循最近开发的软件项目所使用的过程。让我们仔细研究其中的一个项目，看看它能揭示出什么问题。让我们随意选出一个项目TKO来进行研究。例1Mark Tyson被选去领导项目TKO。由于没有易于理解的软件开发过程作为制定项目软件过程的参照点，他花费了比预想更多的时间去定义项目的软件过程。之后他立即忙于反复修改几个活动的性能，时间很紧迫，只能定义一个项目过程框架。他定义的软件开发过程列出了所有在项目中必须执行的活动。遗憾的是，Tyson没有时间文档化所有活动的含义。例如，只有他知道他实际期望的产品规格包含哪些内容，或者在高层和低层设计间有哪些差别，或单元测试意味着什么等等。Tyson没有太考虑缺乏文档化过程的结果，他觉得自己能在恰当的时间通过口头或简单的注释把这些信息传递给他的小组。 如预想的一样，Tyson在让项目组成员接受他定义的过程时没有遇到任何麻烦。为什么？因为没有人真正理解每个活动所意味的范围。因此，每个人都感到与其说凭借他们个人想法来理解这些活动，还不如说被授权以一种方式解释这些活动。当制定估算进度表和成本预算时，这种自我解释导致的冲突第一次发生了。为了执行这个计划，所有项目成员必须解释他们认为的Tyson定义的每个活动和计划的范围含义，而不是真正的含义。坦率地说，许多成员对Tyson意图上指示的每个活动的范围意义不太感兴趣，他们对自己认为的每个活动范围应该是什么更感兴趣。因此，造成了在解释每个活动范围上的不一致。 当Tyson定义过程时，他注重于列出所有要执行的活动，但没有对每个活动代表的所有范围文档化，并且他忽略了对活动开始或者完成前所要满足的入口和出口条件进行文档化。因此，在TKO项目进展过程中，Tyson开始看到活动在它们预定的时间段前“完成”了。 例如，与过程相关的重大问题在产品规格说明书被批准时就变成了轻微的问题。Tyson本想如果适当的话，完成所有的高层设计，并且在检查高层设计时发现所有的问题，纠正它们并将它们反映到规格说明书中。遗憾的是，规格说明书的负责人认为即使是高层设计没有完成或说明书已经做了适当修改，这些规格说明书也可以被认为是完成了的。而且，Tyson本来期望所有的用户界面，例如屏幕界面、提示信息都在规格说明书中有所反映，然而实际却没有。产品功能只以叙述的方式描述，而不是以用户期望的方式描述。当Tyson发现产品说明书中的这些问题时，他命令要修改规格说明书并且重新审批。作为项目领导，他可以强制这样做，但付出了进度延期、增加项目成本以及使一些项目成员不高兴的代价。与过程相关的问题不断发生。例如，许多项目成员没有计划要检查他们负责的高层或低层设计及代码。因此，当Tyson意识到人们没有执行相应的检查就宣称他们的设计和编码已经完成时，他坚持让这些人回去执行相应的检查。由于许多项目成员最初没有为检查做计划，因此，他们随后的活动就落后于计划。最终，Tyson取消了他的命令，允许一些设计和代码没有检查就进入测试。这个决定导致了低质量的代码进入测试阶段。例2 出现许多与过程相关的问题的另一个例子是：Tyson本期望功能测试、构件测试和系统测试的计划能包含一个详细的所有被测试的功能矩阵，而不是只写出测试脚本。现实却是，测试计划根本就没有包括这些测试信息，它们只定义了在运行测试和报告所发现问题的状态中所用到的管理过程。虽然这些信息是重要的，但Tyson的真正意图是测试计划要包括测试脚本范围以确保要执行的测试能被认真分析并被几个人批准。他相信检查-平衡方法能确保不忽略任何执行过程的测试。然而，由于不断增加的进度和成本问题，Tyson接受了不完整的测试计划，并寄希望于系统能工作正常，而不是依靠仔细的计划和按计划执行各项工作。 当与过程相关的问题不断困扰项目时，Tyson由于项目成员没有与他核实他们所解释的过程活动是否准确而变得越来越沮丧。而且，许多项目成员在理解Tyson所想表示的活动范围后，即使他们不赞同他的意图时，也不能正常提出更改的请求。毕竟，Tyson大多数口头上描述的活动范围许多是合理的。没有活动范围的书面描述，许多可允许的误差和解释留给了执行活动的人。结果，项目成员经常背离活动要求且事先没有通知任何人。这使得Tyson感觉到他好像没有办法控制整个项目了。的确，他真的不能控制了。 在许多情况下，项目成员告诉Tyson，既然他们完成了一个活动，他们能为将来这个过程潜在的用户提供些有用的技巧，这些技巧大多是通过试验和失败所获得的。实际上，项目成员认为如果有人早点告诉他们这些技巧，那么他们将提高活动执行的效率和质量。遗憾的是，Tyson没有花时间去记录这些技巧，因为他认为他的“过程”只是一次性的，而且他认为不会从这些过程中得到对将来项目有用的东西。 与过程相关的问题不断地出现，Tyson没有时间从这些问题中解脱出来，而且仍然要紧跟最初的进度、预算和质量计划。他开始希望能缩短还没有开始的许多活动的周期和范围。当然，这不是期望中的。实际上，许多下游的活动需要更多的时间从所产生的低产品质量中得到恢复。 大部分的项目成员感到只有Tyson掌握项目软件开发过程，自己在项目中没有一点儿过程的自主权。实际上，Tyson休假或出差，是项目执行最差的阶段。 当这个项目完成后，进度超期了50，成本超出了70，支持低质量产品的影响是维护代价增加了100，这主要是由于低的客户满意度以及失掉的产品销售量导致的。 回顾这个项目，可以看到它所遇到了与过程相关的问题，而这样的问题在以前的项目中都曾经出现过。而且，来源于过去项目的评审报告表明与过程相关的建议在开发组织内仍然没有被采纳。“难道我们没有得到教训吗?”一些人嘟囔着说。“如果我们想要合理地预测应用软件开发过程的进度、成本和质量结果，那么我们需要从开始就定义完整的软件开发过程，并随着时间的推移，不断地修改完善它。”另一个人嘲弄地说：“你不需要一个已定义的且文档化的软件开发过程去预测项目结果，我在开发组织内已经有足够的经验去较早地预测一个没有过程的项目结果，那就是：更长的进度、更高的成本和更低的产品质量。”结论如果你还没有一个 定义完善的 软件开发过程，那么在创建最适合你所在组织的软件开发过程时，就让每一步的运用形象化。为组织定义一个合适的软件开发过程是组织所要承担的最重要的任务之一。为什么？因为恰当的软件开发过程对控制一个项目的进度、成本和质量有深刻的影响 。二 定义软件开发过程应吸取的经验教训：l 软件开发过程应该由一个可理解的活动集构成，新项目的成员可以从该活动集中选择合适的子集作为新的过程。l 为了改善软件开发过程，必须例行公事地检查软件开发过程。l 软件开发过程必须从不需要用户执行对产品或项目无用的任务。l 软件开发过程必须有一个简单而有力的方法允许过程的使用者提出改善意见或背离的意见。l 为你的组织定义恰当的软件开发过程将对控制项目的进度、成本和质量有深刻的影响。l 组织应该努力具备尽可能少的软件过程模型。l 剪裁软件开发过程的规则必须文档化并且利于理解。l 至少需要提供两个显示如何剪裁软件开发过程的完整例子。l 用一个更合适的软件过程模型来创建软件开发过程，比试图迫使项目使用一个不太适合的软件开发过程要更好。l 对于软件开发过程的全部职责需要尽可能平均和公正的分派给软件开发小组中的各代表。l 大多数非管理人员应该负责和操作软件开发过程。l 在组织中的每一个人包括所有管理层的人员，要被传授软件开发过程的描述和使用方法。l 管理层最后要负责坚持让每个新项目完全遵守所批准的软件开发过程。l 每个组织都需要一个唯一定义的软件开发过程。三定义软件开发过程的步骤步骤1：确定软件模型步骤2：确定活动步骤3：确定活动间的关系步骤4：将每个活动的有用信息文档化步骤5：剪裁过程文档化步骤6：改善过程文档化步骤7：过程获得认可并培训员工步骤8：不断地使用和改善过程2沟通问题人与人之间无法高效地进行交流是在软件开发项目中需要克服的常见障碍之一。因此，必须提高与他人之间交流效率的方法。一. 项目案例 对他人表示尊重是改善人们之间沟通的基础。下面的案例将显示缺乏沟通的现象是如何在实际中被培养和容忍的。这些案例中所描绘的多少情况你遇到过吗?你能发现这些问题吗?当你阅读这些案例时，请记住英国政治家和作家Harold Nicho1son所说的话：“我们倾向于通过理想而鉴定我们自身，而有些人通过行为鉴定自身。”例1 Sophie Berger，一个从事测试领域工作的编程人员，被指派评审可以使用的产品出版物草案。Berger同意评审由出版物草案书写者Mark Hood写完的每一章。这个评审过程是由Hood的管理者提出的，并且由Berger的管理者批准。其目的是尽早地评估出版物的进展。评审过程也给Hood提供了能与编程人员(在此案例中，是Berger)在Hood所需要帮助的领域中更紧密工作的机会。 Berger在软件开发中有五年多的工作经验，而Hood仅工作了一年。Hood主要从 “最终的”产品规格说明书中获得他所需的信息，顺便要说一下，碰巧这份产品规格说明书是不完整的。Hood也利用许多机会尽可能地从写产品规格的编程人员处获得额外的信息。这些编程人员多数表明他们没有时间向他讲解规格说明。然而不幸的是，由Berger评审的几章在一些小节上需要做很大的修订，因为Hood尽管本意很好，但却做出了无效的假定。Berger很快告诉他的同伴：“这个酒囊饭袋之徒根本不了解这个产品。比起要教这个人所要了解的东西，不如我来写这几章，因为这将更节省时间。”Berger的同伴完全同意他的做法。 没有人看来能了解这个项目中正在发生的事情，除了几个领导开发的人员。这些编程人员看起来让任何与他们没有直接责任和承诺的人员都难以与之接近。这些领导开发的人员定期地会见他们的小组。会见的目的是交换情况、引导设计评审，并且一般为下星期一到四做计划。外围小组(文档书写人员、测试人员和质量保证人员、日程安排人员和工具提供人员等)已经询问是否他们可以参加或派代表参加日常的进度安排会议。而他们的回复总是：“不，我们没有什么要共同商议的事情。”当没有其他小组参加会议时，开发者就开始聊天，说“其他组的工作一定比较容易，你从看不到他们加班。他们只会坐在一起抱怨事情不是他们所想的那样。”来自开发组和其他组的管理人员没有采取任何措施去讨论和改变这种情况。 这个公司的管理层认识到为所开发产品的进程做独立评估的重要性。管理者也认识到由与产品开发小组紧密工作的独立小组来帮助尽可能高效地指导开发者的工作的好处。由于这些原因，管理层宣布创建质量保证小组。而且，为了有助于保持客观性，质量保证人员不必向项目领导层直接报告他们保证哪个产品。 更高的管理层知道质量保证的任务，并欢迎质量保证。但是，项目组成员却认为质量保证没有任何价值。一个开发人员对另一个人讥讽质量保证时说：“不同意!我花了几个星期才写完所负责的产品规格说明书部分，而一个质量保证员仅仅因为我写的文档中有几个TBD(to be determineds，有待解决的问题)就不同意!我说了我一有时间就尽快完成这几部分。现在我却必须在下星期完成。我其实是希望首先做一些编码工作。当我一直受限制时我又怎能履行我的承诺呢?我原以为质量保证是帮助我们的，想不到却是使工作进程慢下来。”例2 Bill Foley，一个管理者，刚刚召集他的部门成员一起开会。而他总是开这样的会。要讨论几个主题，一些主题讨论得比较及时，而一些讨论得很不及时。大家公认Foley说话坦率，他经常直率地说出自己的想法。一些部门的成员苦恼于该项目中广泛存在的缺乏沟通以及恶劣的工作关系。Foley所在部门的任务是为产品升级进行设计和编写相应的代码。部门成员目前工作很紧张，并且平均要多加班30的时间。有人问Foley：“是否该部门会雇人来帮助完成这个工作量?”Foley回答说：“预算不允许本项目中增加任何雇员，我们应该做的是降低或裁减某些测试、出版物以及支持部门，我从来没有看到其他部门的人员在周末或下班的时候在这儿加班，我根本看不到他们加入到项目中的作用，看起来他们所做的工作只会减慢我们的工作进程。” 几乎有200个人被指派到这个软件开发项目。为了更好地控制项目中的关键活动， 已经定义和实现了许多过程。一个很关键的活动是库的控制与建立过程。这些过程用于确保所有被开发和测试的模块都能被合适地标识、添加到驻留在计算机磁盘上的模块库中，并且通过一个检验方案进行存取控制，该检验方案允许对库模块按顺序进行修改。构造小组负责确保这个活动的平滑操作。构造小组也要负责为开发和测试组织构造驱动模块(驱动模块是一个模块集合，集合中的模块被链接在一起形成一个可工作的、并能被测试和评估的“产品”)。 被开发的产品被认为是复杂的，并且驻留在几个不同类型的计算机系统上。当准备将新模块添加到系统中时，关于每个模块的信息列表必须从开发组内收集起来。这些数据是把这些模块和其他模块编译和链接起来的基础。无论何时开发组传递模块，好像关于模块的一些有用信息经常被忽视。这些遗失了的数据将导致构造组浪费很多个人去调试包含这些模块的新的驱动模块。为了改正这对生产率造成的损失，构造组发起了有开发人员参加的会议去创建一个容易理解的检查表，当每次要加入新模块到库中的时候可以使用这些列表。构造组必须依赖于开发者所负责的相关模块及模块运行环境的专业知识和技能。 检查列表第一次达到了真正使用的目的，并且构造组这次感到开发者传递给他们数据的重要性。不幸的是，构造组没有预料到会花两整天的时间，并且需要几个人去构造一个带有新模块的驱动模块。失败后，他们请求开发者参与调试。开发人员迅速找到了问题，并且责备构造组没有按检查列表提出恰当的问题。一个构造组成员突然说：“但是我们已经让你确认了所有需要的数据是经过请求的。” 一个开发人员反驳道：“我们必须为你们做所有的工作吗？我们的主要工作是开发产品，而你能做的至少是要处理库控制系统的操作！” 稍后，一个开发人员对另一个人说：“我比构造组的所有人对构造库更了解10倍。我看问题在于他们根本没有意识到过程的存在。何时他们才能进行合作呢?” 这个项目制定并发布了一个质量计划。质量计划被所有人批准，并在代码的设计、编码、单元、功能测试、检查和常规测试中被定义。那么开发者发布他们的单元与功能测试计划，这些计划也应该得到所有人的批准，并形成书面的文档。然后，开发者向进行附加测试的独立测试小组按期交付他们的代码。 现在处于测试位置的许多编程人员为开发编程人员提交的代码的“低质量”而感到苦恼。因为测试者比预计要花费更长的时间才能成功地运行这些测试代码。这些测试者以及受到影响的后来测试者都感到，开发人员不可能为他们的工作感到骄傲，开发人员好像缺乏任何真正的主见，显得不太知道他们在做什么。虽然测试人员经常有怨言，但是在这个问题上没有跟开发人员有正式的沟通。开发人员不知道测试人员发现的质量问题的严重性。测试人员也不知道开发人员还为在批准的步骤和严格的进度下提交了“高质量”的复杂代码而感到自豪。结论 在软件开发项目中，人们相互间无力进行有效沟通是人们取得高生产率和生产质量的重大障碍之一。这个障碍可以表现在雇员间、在管理层和雇员间以及管理层内部。二.有效沟通的经验教训l 被每个人给予和感受到的尊敬和重视是企业整体成功的关键。l 与他人一起工作的最好建议是相对待自己一样对待别人。l 知道改善沟通的方法是第一步；“实践实践再实践”的黄金规则是最重要的。l 当你犯错误时勇于承认，这会使对抗的一面转变为合作的一面。l 你对他人的宽容也会让其他人宽容你的行为。l 交互式的沟通仍是最好的沟通方式。l 当项目中的成员愿意共享知识和经验时，这个项目的团队精神就大大被提高了。l 与另外一人沟通，会使你们都从中受益。l 人们更多关注的是你所发信息的方式而不是内容。l 尽力让其他人不对坏消息感到惊讶。l 坏消息就好比垃圾，你越延迟遵照此消息行事，那么它就越容易变臭。l 把问题搁置在人们和小组之间会对沟通产生消极影响。l 你能说得最重要的一句话是：“谢谢你！”l 聆听对双方都有很大好处。l 答谢别人，尤其通过名字，是一种感受到尊重与被尊重的有力方式。l 一个折衷的解决方案通常是最好的解决方案。l 不要让过去的习惯阻止积极的进步。l 如果形成一个有效的小组，那么项目小组必须理解其他人的任务。l 在最后的分析中，管理层有权负责确保项目中具有所需要的沟通。 3软件项目进度计划中的问题不现实的项目进度计划创建一个不可完成的项目进度计划会发生多米诺效应，当一个接一个的进度活动没有像计划那样的完成时，最终会使整个项目垮掉。一个项目的最重要计划项目的心脏，是项目进度计划。一 项目案例 下面举例说明了一个不现实的项目进度计划是怎样滚动成个大问题的。制定一个糟糕的项目进度计划类似于制定项目失败的时间表。 在项目开始的第一个月，一个非正式的、粗糙的进度计划估计产品开发周期为12到18个月。一个月以后，产品需求已经写完和批准，并制定了一个12个月期限的初步进度表。每一个与项目有关的人都知道，12个月的进度是相当乐观的，然而，没有一个人去重视这个进度表，因为进度表是初步的。一个包含必需细节的最终进度表即将产生。 在其间，产品目标已经确定，并且所有参与的小组都同意了产品的开发方向。开始书写产品规格说明书，高层设计也已经开始了。对项目有了很好的感觉。具有必需技能的成员都在进行开发。为了开发和测试产品，编程人员、出版物编写者和支持人员都参加了进来。 大家都知道这个项目对公司来说是很重要的，也知道应该把产品尽快地交付到客户手中。尽早交付客户产品的两个主要理由是：一是为下一个财政年度(开始于1月，结束于12月)获得收入；二是有利于确保让主要客户选择这个产品而不是竞争者的产品。没有人对尽快交付产品产生怀疑。 项目计划者致力于在接下来的两周内制定出恰当的详细项目进度表。一个计划者评论道：“详细的进度表一个月之内就可以完成。这个项目与我以前做过的很相似，真的不用太花时间去制定这个进度表。”计划者决定在项目进度表中不包括技术人员，理由是“尽可能让技术人员去做一些真正的工作”。 详细进度表的草稿在三天之内就准备好了。当许多管理层的成员在浏览这个草稿时，所有人都觉得这个进度表是很紧张的，但是也都认为，如果产品要按时冲入市场的话，这是一个“正确”的进度计划。做了一些小的改动，并形成了最终的草稿。计划者对此进度表在大部分技术主管中做了调查。一些技术主管认为进度太紧张了，同时项目人员太少了以至无法完成。或者，假如项目人员补充到足够，但是这些新成员的技术水平会低于所要求的水平。如果项目补充了比已有成员技术水平低的新人，那么需要花更多的时间去培训新人让他们达到相当的技术水平。计划部门的回答是：“不要去考虑人员问题。这是一个赛马场，我们就工作在里面。” 特别是自从许多人在前面的项目中有过超量的假期时间之后，许多技术主管感到被提议的进度表没有充分地考虑休假和节日时间。得到的回答是：“没有计划安排加班。因此，加班是必须的调节方法。而且，当主要节日和假期到来的时候，距离年底还有好几个月的时间。我们还有很充裕的时间。” 另一个涉及的问题是所期望的编程人员应有最高的生产效率，而不是中等或低的。计划者的回答是大多数的技术主管是经验丰富的老手，他们的高水平技术会有更高的生产效率。计划者附加道：“如果这个项目获得成功，我们将会达到较高的生产效率。”也提出了另一些关心的事情，却没有得到基本的重视。然而，为了缓解技术人员的抱怨，进度表被延长了两星期。虽然这不能完全满足他们，但是真的能帮助减小他们正在承受的压力。技术主管推理说：“产品总是到非做不可时才做，所以才会有现在这样一大堆事情要做。总之，几乎每一个项目好像都是采用这种开发模式。有没有什么新的方式吗？”计划者嘟囔地说：“坏的情况是技术主管人员没有更多的商业头脑，也不会意识到为了把业务做大，你不得不承担大的风险。这就是为什么技术人员不懂得做生意。我们不得不促使整个组织去完成这个进度。” 在项目内部好像存在着一种事情没有决定的感觉，只是一种平衡。从没有开过一方与另一方相互之间能够达成一致意见的碰头会。（实际上，应该没有所谓的“一方”的区分。相反，应该共享商业与技术目标。）总的结论是像这样已经认识到的平衡一直存在。这就是通常的“商业事情”。 产品规格说明书已经写完，并被看过了，得到的意见比期望的多。原因是规格说明书还没有完全完成(也不是高层设计)，但是为了继续项目进度，准时分发了这些规格说明书。计划者为此很高兴。技术人员却没有感到高兴，但是认识到符合进度表的重要性。产品规格说明书针对评议意见进行了修改，并重新发给每一个人使用。对修改过的产品规格书仍有许多意见，但是现在的大部分意见都被忽视了。也许进度不允许对产品规格说明书再进行第二次修改。所期望的是只有一次三周的评审周期，而不是两次两周的评审周期。 比计划的只需一次修改产品规格说明书多了许多遍修改，这样高层设计远落后于进度表。开发者加班工作试图尽快完成高层设计。而且，每两个设计检查就有一个是失败的。进度表允许设计检查，但是没有给失败的检查留出修改的时间。即使人们加班工作，进度也是进展缓慢和受挫的。高层设计最后终于完成了，但是却比进度表延期了两星期。感觉是“不太坏”，特别是项目增加的两星期也被计算在内。 当低层的设计、编码、测试计划和出版物内容计划在开发过程中，碰到了一个令人烦恼的现实产品规格说明书仍然没有完全写完。流行的想法是如果产品规格说明书通过两遍的评审周期并在文档修改周期之间就应该完成。不幸的是，太晚了以至不可能挽回了。所有的开发人员尽他们的努力去修改个人的规格说明书的副本，以继续他们的低层设计和编码。然而，他们已经没有时间像通常那样修改产品规格说明书并重新分发给项目内部的其他小组。现在测试人员和出版物编写人员开始落后于进度表了。有许多选择，但是只有一个能真正解决这些问题的办法：开发人员必须修改和重新发布产品规格说明书。他们也这样做了。 几个星期过去了，产品规格说明书已经被修改并在整个项目内部重新发布。低层设计已经完成。但是，编码、单元测试和功能测试远落后于进度表。而且，测试人员和编写人员发现他们已经不可能赶上所落后的时间了。他们感到真正的项目危急路线不在于他们，而在于开发人员为了让代码进入正式测试周期的第一个阶段。感觉是， 当进度表最初进行制定时，没有人想到要包括编写单元测试和功能测试计划。为了保护进度表的要求，放弃了单元测试，现在集中在功能测试。 现在项目比计划的进度落后六周。如果任何额外的事故发生，那么项目将不可能像计划的那样为下一个财政年度带来收入。（有两周的缓冲，加上财政年度开始前的一个月，有六周的回旋余地。）为此，宣称代码已经准备好了进行首次独立测试阶段构件测试。计划功能测试与构件测试并行完成。 一个中等的灾难逐步显示出来。开发人员和测试人员这两个组同时对相同的代码进行测试，两组成员都发现了相同的缺陷。更糟糕的是，修改测试人员发现的缺陷的响应时间比要求的时间长。原因是：开发人员正忙于完成自己的功能测试。为了“解决”这个问题，命令开发人员依照测试人员设定的优先级别改正缺陷。项目领导层强调按最初计划包含构件测试持续时间的重要性。然而，尽管有这种领导的要求，构件测试还是比原计划多花了四周的时间。开发人员递交的代码还是有很多缺陷。 现在进度比最初的计划延长了10周的时间。开发人员已经有几个月连续超负荷加班工作了。人们都感到很疲惫、灰心和急躁。重要的节日和假期已经到了，但是没有人能够休息。最常被重复的话是“我再也不想有这种经历了！”第二句话是“但是还是会再发生。总是相同的方式。我们好像从来没有吸取经验教训！”结论 项目进度计划设软件开发过程的心脏，它定义了实质上影响所有项目成员活动的路标，也是在项目组之间沟通的基石。如果项目进度计划定义的不合理，那么预期的项目进展就会很快停滞。二 制定项目进度计划中的经验教训l 最重要的项目计划是项目进度计划。l 项目进度计划都处在控制之中。l 在等待制定完整项目进度计划所需的信号时，必须建立一个近期的进度计划。l 项目取得进展不可能进行测量，除非已经首先建立了可以测量进展的计划。l 自顶向下的计划实在没有任何项目成员参与的情况下制定的，因此不能解释为被提交的计划。l 只有已经被很好确定的事情，才能提交以用于制定详细的进度表。l 为了达到最大的生产效率，项目成员需要遵循计划。l 每延迟一天完成最终进度计划，实际的项目将延期半天，而这些损失对项目来说是无法挽回的。l 项目进度计划通常必须包含一页项目主要里程碑的总体图。l 与文档相关的活动必须扩展到一系列更小的活动中。l 必须完成达到评审水平的文档。l 在修改文档时必须修改的地方用强调的形式指出。l 当文档项目文档进入更新阶段时，要加强项目内部的沟通。l 重要的或复杂的文档必须要执行这五个阶段。/ 准备、评审、修改、批准、更新l 文档的负责人必须坚持有一个完整的评审阶段。l 如果活动互相之间是相互依赖的，不管是直接的还是间接的，都因该尽量避免产生交迭。l 当活动交迭数量增加时，管理项目的复杂程度会增加。l 当估计活动周期时，把活动分为更小的工作块，并计算每个工作块的周期。l 为了得到最好的估计结果，把一个活动分为一些大约需要一周时间去完成的工作块。l 一个项目必须有一套每个人制定进度计划时使用的共同程序。l 为了缩短项目周期，将工作重点集中在组成关键路径的那些活动。l 首先建立一个受进度约束的计划，然后再过渡到受资源约束的计划。l 人员排辈布置靠路牌被“管理者”，而且要考虑配备有合理技能的管理者。l 每个项目进度计划都要包括意外事故缓冲时间。l 分布意外事故缓冲时间到项目的所有活动中。l 保持周末作为一种意外事故缓冲时间的形式。l 不要在计划中计划出加班时间，无论如何它是会发生的。l 当临时人员离开项目时，要准备应付知识和技能的流失。l 当开发一个项目进度计划是，要确信考虑节日和假期的因素。l 在项目进度计划中包含第二方观点可能是没有什么价值的，但是相应也是廉价和可行的。l 活动责任矩阵是阐明项目责任的区域和帮助项目成员预计工作量的强有力的工具。l 定制项目检查表只显示一个特定项目成员或特定小组负责的那些活动。l 在大多数项目，PSC是一个全日制的职位，而且，建议管理层授权一个非管理者去履行这个职责。l 新项目必须把制定羡慕计划作为最优先活动。l 当计划日期改变时，应该保存原始日期。l 如果你相信项目成员有改正的机会，即决不改变项目进度计划。l 应该限制修改项目进度计划的时间。例如，修改一个项目计划的周期应该在12个月或更短的时间之内进行。l 最佳的项目进度计划是富有挑战性的而且是可达到的。l 虽然每个项目成员对他或她自己的工作负责，但是一个项目领导有保证良好计划项目的最大责任。l 记住，一旦承诺了一个项目进度计划，你将会与它共同度过其中每一天日复日，年复年。三创建项目进度计划的步骤1. 指定项目进度协调者2. 确定要使用的工具3. 为项目进度计划会议做准备4. 开始项目进度计划会议5. 完成任务6. 从每个提交中提取数据7. 使用工具创建项目进度计划8. 评审每个提交的结果9. 实施项目进度计划的完全评审10. 用工具更改项目进度计划11. 批准项目进度计划12. 分发所批准的项目进度计划给项目成员。4项目跟踪的问题项目跟踪会议的焦点问题是什么从真正的效率要求上看，我们经常是对项目跟踪得太少太迟。项目跟踪的主要理由是，在问题发生之前，就找出潜在的问题。一项目案例下面是一个其他方面都计划得不错的项目，是如何在某一天陷入困境的。项目的开端看来不错：已经记录并审批通过了产品需求、目标；正在撰写产品说明书；已经开始了高层设计；对项目开发计划也已经给予了特别关注；已经定义了项目的所有活动及其相关活动，并确认了活动的持续时间。既然这个通过审批的项目进度计划已就绪，剩下的就是管理问题了。 项目负责人，Ralph Macho，认为应该保持控制。他的格言是：“让我们实干，别空谈！”可以说，就是这个武断的言论引发了这次项目。很多从事该项目的人并不真正清楚可以期望从Ralph Macho那儿得到什么。因为在这个组织中，相对来说，他是个新人。然而，总体上看来，前景是乐观的。 上级有令，说该项目非常重要，因此只能成功不许失败。（听来耳熟吗？）Macho宣布该项目必须被紧密跟踪，并要求召开第一阶段的会议，所有的项目负责人都被叫了来。他们每个人都将该阶段活动的幻灯片展示给其他人看。按原计划，早上的会议将召开三个小时，然而四小时过去了，只有不到一半的人进行了陈述。在最初的四个小时里，发现了横跨各个部门的一些问题，问题负责人被告知：“回去解决。”长达八个小时的冗长会议终于结束了，仍有三分之一的人未能报告他们的情况，但鉴于原先的承诺，Macho只能结束这次会议。他声明他将在明天安排一个时间阅读并观看未能陈述的报告。 参加这次“三小时”却实际上进行了一天的会议后，项目负责人们有种说不清的感受。他们只是觉得自己了解了其他部门的许多情况。有时他们自己所负责的领域也会显出一些问题。但普遍认为，花上八个小时而仅仅只得到这些是不值得的。很多人不得不因此错过当天计划的其他会议。 次日早上，项目负责人们又得到通知：他们必须向Macho陈述情况报告。新的会议安排在当天下午举行，为期两小时。然而就在会议将要开始的前几分钟，Macho的秘书宣布他会迟到，会议可能要推迟30分钟举行。会议延续了90分钟，同以前一样，在所有人都完成报告陈述之前，Macho很快说道：“我们将安排其他时间来进行未完的陈述。”这令那些还未做陈述的项目负责人们很不舒服，但他们也明白事已至此，无可挽回了。 下次的项目情况会议安排在下个星期，为期四小时。会议刚要开始，又临时决定推迟两天举行。Macho的秘书宣称，鉴于Macho的行动日程，不得不做出变更。当会议终于举行时，可以看到，这一次的参会人已不完全是上次的参会人了。60的项目负责人参加了，还有30则派了代表参加，而余下的10根本没有参加。代表们并不完全了解前次会议所陈述的问题， 因而也就未能讨论。在会议中也曾尝试解决一部分问题，但绝大多数代表在没得到他们头儿的许可之前，不愿做出任何的承诺。更糟糕的是，项目负责人们对前次会议中针对部分问题所应采取行动的记忆各不相同。会议也没有详尽的记录。每个人只保留了自己的笔记。这样在本次会议结束时又对需要采取行动的问题做了一次调查和总结。本来四小时的会议拖了六小时。 接下来的几次项目情况会议以相同的方式进行。原定会议时间往往在最后一分钟又有改动。甚至有一次会议因为Macho出差干脆取消了。这样多次反复后，参加会议的项目负责人们越来越少了，而他们的代表越来越多。会议时间总是比计划时间长。对前次会议所发现问题的不同意见不断增多，所指派的问题负责人也越来越多。参会人越来越难以从其他人那里得到关于工作要求的承诺。很多相关过程和工作项未能按时完成，整个项目进度渐渐变慢。有几个项目负责人聚在一起，下决心寻找一种更好的跟踪、记录项目情况的方法，用以实施至项目完成。他们列举了六、七个当前情况会议中存在的主要问题，并给出了解决意见。他们克服种种困难设法让Macho安排了一小时的讨论，并于两天之后见到了他。Macho虽然欣赏他们的投入，也觉得其中一些问题应该要解决。然而他还是问道：“为什么不让所有的项目负责人们按自己的意愿来解决这些问题呢？要想事情有所进展的话，就必须依靠自己的力量让它发生。”他不大情愿地采纳了几条建议，并对他不能出席的会议指派专人负责，由他在每次会议上做几分钟的发言并负责记录所有的问题。对此，项目负责人们觉得松了一口气，欣慰的是情况有了改善，同时又有点失望， 因为他们不得不为取得的改善付出巨大努力。接下来的项目情况会议每周都定期举行，但Macho虽然总是许诺参加 “下一次”会议，却很难抽空参加。各组织间的交流有所改善，却没有得出解决问题的实际办法。对其间相互关系的忽略也更严重了。大部分项目负责人不再参会。每个部门的工作，以及相关部门的工作几乎只依赖于每个项目负责人的个人意愿和所采用的方法。有些项目负责人没有负起领导责任，但缺乏领导并不是有意的，有些人仅仅是因为不知道该怎么做。从一开始，人们就一致认为，要尽快解决高优先级的问题，同时可能需要进行问题升级，以便关注必须注意的问题。（当某位成员不能从其他成员或组织中得到对问题满意的解决时，就会发生问题升级。在得出双方都认同的解决方案之前，该问题保持开放状态并会持续发展。为了解决并了结出现的问题，有时候要求不同组织中更高层的项目负责人们开会研究。）这时候存在着一个大问题，即许多升级问题通过各种渠道进入了项目总负责人的办公室。并花费一个星期或更长的时间等待Macho露面来进行解决。有时候，一些内部工作是必须做的，随后会议日程还需要确定。解决问题的时间越来越长。大家都明白这一点。因此，出现了一种趋向，不把原本需要升级的问题及时升级。人们普遍感觉到事态失控了，因为没有一套能有效监控项目进展并强制修正错误的体系存在。项目进展越来越落后于进度计划表了。由于并不总能确切而又完整地汇报项目情况，一些按计划应在一周之前就已汇报过的活动现在才来汇报，过了一周却又说要再过一周才能汇报。而当一些小组大步前进的时候，另一些小组的工作却严重落后。整个组织似乎就没有领导的存在。人们经常问道“谁管呀？”。通常的回答是，也许是项目总负责人吧还要看他是否有空。也经常听到有人说：“哦，好的，既然项目总负责人没有更多的兴趣，我们就只能各自按所知晓的最好方式去做，希望境况有所改善吧。”（任何时候，只要听到“哦”、“好的”之类的话，就能断定很多责任消失了，并且生产率随之下降。）人人都明白，在实施项目跟踪、确保尽早找出并解决问题方面，Macho严重地缺乏责任感。人们渐渐地失去信心了。不停地指责替罪羊。大家一致认为本项目将赶不上产品交付日期。更糟糕的是，没有人知道项目“陷入壕沟”到底有多深。结论一个软件开发项目就好比一个有机体。为了存活，所有关键部分必须协调工作。任何部分失效都导致其有关部分随之失效。显然，项目跟踪的焦点在于找出问题和解决问题，这就意味着跟踪两方面的信息：项目活动计划和已知问题。二项目跟踪过程的经验教训l 项目跟踪就是在项目中始终保持控制。l 召开项目跟踪会议的首要原因，是为了在问题发生之前就找出潜在的问题。l 如果不能定期找出和跟踪项目的高风险区，也就不能充分的跟踪该项目。l 在项目组员无力有效地解决当前问题的同时，不要去尝试解决更关键的项目问题。l 无论什么时候重新设定目标结束日期，都要在添加新日期的同时保持“旧”日期的可见性。l 如果一个高风险区在表上列出了很长时间，就表明这个关键问题没有得到必要的关注。l 有关项目概观的资料常常反映了上一次PTT（项目跟踪组）会议的进展。l 如果一个项目活动将持续几个星期，则PTT成员在比较实际进展和计划时需要用支持图做辅助说明。l 能否得到诚实、准确、真实的数据是在评价一个项目是否得到控制时要考虑的基本因素。l 不论项目处在开发周期的什么阶段，每个项目成员都应该能够随时记录下问题。l 如果待评估项目没有已承诺的项目进度计划，那么为它指定风险值就没有什么作用。l 根据项目进度计划，PTT会议应该每周举行一次以实现最佳生产率。l PTT会议起到了项目的基本推动力作用。l PTT会议在周二或周三举行是最有效的随后的一天可预留给工作会议和扩大会议。l 为了促进组织低层的责任，通常不应在PTT成员中包括管理层人员。l PTT成员必须能够完全的描述他们的领域。l 计划周密的PTT会议日程可以对保持控制产生积极、深远的影响，这不只是为了会议的需要，也是为了项目的需要。l 对销售商和转包商活动进展的跟踪应该像对项目其他成员的跟踪一样，按惯例进行。l 安排PTT会议时间时要比原计划多留出30分钟的空余。l 一套简单的PTT程序会促进成功。l 为了把项目做得更好，也为了其他成员的方便，任何项目成员需要时都不妨寻求帮助。l 要使项目尽可能的成功，项目领导层就必须全力支持PTT会议和相关活动。l 制定修复计划是为了迅速解决问题并限制可能导致的破坏。l 为了解决争端，问题升级是合适和健康的行为。l 问题升级应该在该项目需要确定后的两个工作日内启动。l 进行问题升级时，不要停止对计划的记录工作。l 在得到了要跟踪的、通过审批了的项目进度计划时，PTT会议才是最有效的。三跟踪项目进度计划的步骤1. 指派PTT（项目跟踪组）领导2. 选定要用事工具和表格3. 准备PTT培训4. 实施PTT培训5. 准备PTT会议6. 召开PTT会议7. 开展工作/问题升级会议8. 分发PTT会议记录9. 转第五步直接到项目结束。 5理解客户的需求问题理解客户的需求-他们希望解决的问题和要求，是软件开发过程中最不受重视的活动之一。但谁能忍受花费数十万甚至数百万美元，开发的产品却不能满足和解决潜在用户的问题和要求呢?一 项目案例现在是计划和开发新的软件产品的时候。虽然当前的产品能取得大量收入，但据分析一年后收入将逐渐减少-这段时间正好可以用来进行新产品的开发。营销部门想要开发新的软件产品，并巴不得开发人员立刻实施。开发人员对开发新软件也很有热情。开发新的软件产品总比旧软件的“维护”工作要有趣得多。 营销人员同开发人员一同开会准备推出新产品。会上，大多数开发人员立刻接受了营销人员的想法，认为新产品会带来预期的销售收入。但是一位叫做larry Whittington的软件开发人员发出了不同的声音：“新产品要解决什么问题呢？” “这样的问题很奇怪。新产品将提高客户的生产率并降低整体费用。” “你能更直接一些吗?能否举例说明这是如何发生的吗？你们是否同某些客户接触过，并得到新产品能产生如你们所希望效果的确认？” “我们没有做得如此具体，但基于我们以往的经验，我们有信心达到这样的目标。我们并不认为我们必须与潜在的客户交流，但无论如何，我们计划在产品开发过程中与潜在的客户进行交流。 “如果我们在产品几乎完工时才知道我们的产品并不能解决客户的问题或满足客户的需求怎么办呢？我们早先的产品已经发生过类似的问题，重新设计软件总是费时费力的。”“别这样悲观。照你的说法，我们就无法开发任何产品了。在商业上我们不得不冒险，我们知道客户需要什么，有时甚至连他们自己也不了解自己要什么。”Whittington退缩了，他无法从其他人那里得到支持。他开始考虑自己是不是错误地理解了客户的问题和需要。毕竟，营销人员知道得最多。 几个星期过去了，人们开始讨论产品目标。新产品有许多“花哨”的功能，看上去能吸引许多客户。开发人员为这些软件功能而感到沾沾自喜。开发目标仅进行了细微的修改就获得了通过。Whittington建议营销人员让若干预期客户确认开发目标是否满足自身需要，但是营销人员拒绝了，他们解释说这些任务是他们的可选工作。“相信我们”，一个营销代表说，“我们了解客户，他们会喜欢这些产品的。 六个星期过去了，产品特性完成了正等待着审核。营销人员又对开发目标进行了一些较大的改动。Whittington建议在让客户审核前不要进行改动，这样做可能会导致今后返工时增加时间和成本开销。尽管一些开发人员开始赞同他的想法，但是他再一次无法得到他人的支持。负责项目开发的领导同意对产品规格进行变更。几个星期以后，产品规格得到了升级并等待着批准。由于在复审草案中已经涵盖了大量的变更，所以复审人员仅仅提出只需要再进行若干细微的变动，这促使产品规格得以通过。但在复审会上，Whittington再次试图建议营销人员把产品规格提交给潜在客户进行反馈，但营销人员则要求立刻进行开发。 Whittington辩解说：“我们现在对项目的时间安排非常主动，我们仍然有好几个月可以等待用户反馈，但是如果在开发基本完成时发现客户反馈意见表明我们需要对产品进行大的改动，那我们将不得不加班工作并牺牲大量的休假时间，更不用说丧失公司收入和利润了。”为了减少项目开发人员将来可能花费的时间和精