本文介绍了管理一个软件产品与管理一部电影作品的若干对比，然后讨论了从成功项目中获得的四种软件管理方法。
　　使用传统的工程管理原则管理软件项目是很难取得成功的。把软件管理的挑战与制作一部动作大片进行比较，我们会发现很多有趣的观点。两者的管理问题都集中在在受经济因素制约的环境下进行复杂的集成知识产权的开发。本文介绍了管理一个软件产品与管理一部电影作品的一些对比，然后详细介绍了从成功项目中获得的软件管理的四种方法。主要的推荐做法是使用指导性的领导方式，而不是传统理念上的事无巨细的计划-轨迹领导方式。
　　在我的职业生涯中，我有机会观察并评估了上百个软件项目，它们广泛覆盖了各种工业和应用。一个显著的成败决定因素是在项目从初始到被用户接受的过程中所采用的项目管理方式。
　　根据我的经验，如果软件项目管理者使用更像是管理一部电影作品的方式，而不是管理一个工程产品的方式，那么他们似乎更容易成功。“胡说！”有人可能反对。“软件项目需要更多严格的工程管理，而不是更少！”在你发表你的言论，向权威发出挑战以前，请考虑以下观察资料：
　　大多数软件权威不需要物理定律或者物质属性来制约他们的问题及其解决方案。他们只是受到人类想象力、经济因素的制约，以及当他们获得一些可执行程序时，他们受到运行平台性能的制约。一些嵌入式软件的开发者显然是例外者。
　　在一个软件项目中，你几乎可以在任何时间改变任何东西：计划、人、预算里程碑、需求、设计、测试等等。需求——可能是我们的工业中被最严重误用的词——很少能描述出真正需要的任何事情。一切几乎都是可以协商的。
　　软件产品的评估和衡量没有原子单元。经济性能（在服务行业中更为典型，评价为性价比）被证明是最好的成功的度量手段。质量的大多数方面都是很主观的，比如可维护性、可靠性以及可用性。
　　这些观察结果对电影制片人同样适用，他们是有规律地创作独特的、复杂的、只受视角和人类创造性制约的知识产权作品。我假设电影作品的经济性能与软件项目的经济性能是相似的：从2000年起，只有三分之一作品的发行带有时间或经济上的可预言性。1我知道这些观察在使用工程理念来制造飞机、桥梁、心脏移植管、核反应堆、摩天大楼以及卫星的项目管理者看来是不入流的（除非这些工程项目包括重要的软件内容或是空前的，史无前例的系统）。
　　好的，有人可能会说，软件只是一个未成熟的工程分支，在我的职业生涯中，大约每五年软件项目的底层技术就要翻新一次。这些翻新包括语言、结构模式、应用、用户界面、计算平台、网络、环境、过程以及工具。这种快速持续的进化将要放慢了吗？目前还看不出这种迹象。人类想象力和市场作用仍是非常强大的。
　　就像电影工业，我们需要有资格的建筑师（导演）、分析家（编剧、设计师）、软件工程师（产品工作人员、编辑、特技制造者、演员替身）以及项目管理者（制片人）。还是和电影工业一样，我们必须使软件成为可执行形式（弄到胶片上）来切实进行进度和质量的评估。在我们发现什么可用什么不可用的过程中会产生大量的碎片和重复工作，然后我们把很多人的贡献集成为一个紧密集成的知识产权作品。
　　我所认识到的是，软件管理应被更精确地描述为软件经济的一个分支，而不是软件工程。软件管理者每天的决定（正如电影制作人每天的决定），主要是由价值判断、成本权衡、人为因素、宏观经济趋势、技术趋势、市场强度以及时机控制的。软件项目很少注重于精确的数学、物质属性、物理定律或是其他已经建立的成熟的工程原则。
　　我希望这一对软件-电影的对比刺激了你的神经，使你想继续读下去。如果想了解更详细的对比请参考 Paul Graham 的论文。2下文着重介绍的是一些从软件项目中获得的断言，这些项目包括了我在25年多的时间里在软件项目管理领域跟从、领导、实践、指导的少数成功软件项目和大量不成功软件项目。
　　迭代的方法
　　造成软件集中型项目的低成功率的原因之一是传统的项目管理方法不鼓励进行指导和调整以缓解以下问题的不确定性：
　　问题域（用户究竟想要或者需要什么）
　　解决域（何种结构和技术的组合是最适用的）
　　计划域（成本和时间制约、团队组成和生产力、涉众交流、递增结果序列等等）
　　我们需要一种更为动态和具有适应性的方法来思考软件进程和质量管理的问题，这种方法应当适应成功项目的模式。当今的现代软件管理方法3-5 通常被称为迭代 开发方法。在现今充满不确定性的软件应用程序、产品和服务开发的雷区中，迭代方法指导了软件项目，而不是遵循一个精确的、长期的计划。按时间和预算计划成功发布软件产品需要一种发现、生产、评估和指导性领导方式的进步的混合。“指导”一词意味着积极的管理参与，经常的过程矫正以产生更好的结果。所有涉众应该通力合作，集中实现不断前进的目标。
　　作为一个被广泛接受的现代迭代开发过程，IBM Rational Unified Process，6 为一个更为平衡的发展提供了一个框架，这一发展是鼓励对不确定性和风险进行管理的。它的生命周期包括四个阶段，每个阶段都有可演示的结果：
　　1.起始：远景和商业案例的定义和原型设计
　　2.细化：对架构基线进行集成、论证和评估
　　3.构建：对有用的增量进行开发、论证和评估
　　4.产品化：可用性评估、最终产品以及发行
　　阶段的名称表现了项目的状态，而不是从需求到设计到编码到测试到发行的基于顺序性活动的项目进展。
　　我们把这一迭代管理方式称为基于结果的，而不是基于活动的。在软件世界中，真正的结果是可执行程序。其他的任何东西（需求文档、用例模型、设计模型、测试用例、计划、过程、文档、检查）都是次要的，而且只是实现目标——一个可执行的软件程序——的手段的一部分。回想你做程序员的日子：当你在建立一个模型、画流程图草图、推理一个状态机的逻辑或是写源代码的时候，你知道你只是在思考和集成一个抽象方案。只有当你编译、链接和执行时方案才变得切实可行。项目管理者应该有同样的感觉。当你评估一个计划、模型、文档或一些其他不可执行的表现物的美好和出色之处时，你只是在推测项目质量和进度。电影制作人对剧本、情节串连板、背景设置以及服装设计的感觉也是如此。他们着力于影片的每一个镜头，使得电影成为可以判断总体集成效果的实体。
　　精确度与准确度
　　在一个成功的软件项目中，每一个开发阶段都加深了对发展计划、规格说明和完整解决方案的理解，因为每一个阶段都延伸了可执行序列和团队对竞争目标的认识。在生命周期中的任意一点，次要工件的精确性应与这种理解相平衡，在详细程度上保持一致，相互之间保持一定程度的可追踪性。
　　精确度与准确度之间的区别（在软件管理的上下文中）并不是它们看起来那样小。软件管理充满灰色的区域、情景依赖性以及不明确的折衷。对优秀的软件管理者来说，理解精确性与准确性之间的区别是一种基本技能，因为他们必须准确地对投资、风险以及变化带来的影响进行预测。未被证实的精确度——在需求或是计划内的——实际上是造成阻碍成功的潜在而微妙的因素。大多数时候，早期的精确性是不诚实的，造成了有比实际上更多的进展和更高的质量的假象。不幸的是，很多项目发起者和涉众要求这种早期精确性和详细性，因为这给了他们对已经取得的进展的（虚假的）安慰。
　　我在软件工业中所见的最常见的失败模式之一是开发有五位数精度的规格说明，而涉众其实对问题、方案或者计划只有一位数精度的理解。延长建立一个精确的需求理解或详细的计划的时间实际上耽误了对架构上更重要的问题的理解。你曾经做过、修改过、痛苦地回顾过多少厚度吓人的需求文档或是详细的管理计划呢？而几个月后当项目取得了有实际意义的可演示的进展，加快了涉众对实际的权衡的理解时，你又要全部重新检查这些文档和计划了。这种普遍现象在我们的行业里被称为刨光废物。
　　一些成功的指导模式
　　迭代过程大多是由解决不确定性和管理软件风险的需要而发展的。这里的指导需要动态控制以及中间的检查点，这样涉众就可以评估到目前为止完成了哪些工作，应该对目标作出什么修改，以及如何重新分配他们的工作以使目标按照最为经济的方式组合。我曾观察到成功的软件集中型项目典型的四种模式。这些模式表现了一些“抽象规格”，对指导评估、范围管理、过程控制、进展和质量控制有所帮助。我有预感，多数在项目管理中“被鉴定过的”项目管理者对此都会作出消极的反应，因为这些理念在一定程度上是与传统相悖的。
　　范围管理：方案从用户具体的要求发展而来，而用户的具体要求从候选方案发展而来。与从开始就确定所有需求不同。
　　过程控制：过程和工具的使用从轻到重渐变。与把整个项目的生存周期过程定义为轻或重不同。
　　进展：健康的项目展示出一个进展和背离的序列。与按照预期计划100%实现价值，没有明显的背离不同。
　　质量控制：测试可演示的发布版本是一个头等重要的、贯穿全生命周期的活动。与认为它是次要的，生命周期晚期的活动的观点不同。
　　我承认在实际软件项目中，上述四点都是说起来容易做起来难，而且对不同领域它们应该被不同地应用。网络应用程序开发团队与嵌入式应用程序开发团队实现这些模式的方法应该是不同的，但是对他们来说模式都是可用的。方法、模式和技术的书籍和论文的写作，（工业界称为思想领导），是相对简单的。尽管如此，我们中的多数人并不是在寻找最好的思想，而是在寻找最好的实践方法。管理实际项目需要实践的领导力，而在实际项目条件下应用和执行这些理念是相对困难的。我们应当珍惜懂得实践的领导力的项目管理者：他们可能是每个公司中最稀有的资源。优秀的项目管理者，就像优秀的电影制作人一样，不只是常常创造出优秀的产品，他们还是年轻团队成员的良师益友，这些年轻人能够学习有效的技术并发展他们自己在多维权衡、持续性沟通、风险管理、模式识别以及指导式领导等方面的技能。项目管理训练课程是学习的良好催化剂，但是学徒期是不可或缺的。
　　范围管理
　　传统软件过程的比较微妙的挑战之一是如何把生存周期表现为一系列顺序的活动：从需求分析到设计，编码，测试，最后发行。成功的项目确实用一种抽象的方式实现了这种进展路线，但是活动之间的界限是模糊不清的，只能被合作的涉众所接受。另一方面，不成功的项目则陷入了挣扎着寻找活动间清晰的界限的误区。比如，在过渡到设计前追求100%固定的需求基线，或是在过渡到编码前追求非常详细的设计文档，都是严格的中间目标，造成了注意力被琐碎细节所分散，而重要工程决定的进展却被放缓甚至停止。
　　当我们建立一个全新的软件方案时，从需求到设计的连续的详细规格说明流也许是有一定意义的。但是现在，我们通常是升级一个已有系统或者根据已有部件（操作系统、网络服务、网络、图形用户界面、数据管理、封装的应用程序、中间件、计算平台、遗留系统等）建立新的系统。改造或复用已有财产的经济效益迫使我们考虑在这些已有财产的环境和限制下的用户具体需要。
　　我前面曾经说过，需求可能是我们的工业中被最严重误用的词。需求意味着不可协商，但我们却在几乎所有成功项目中看到需求的变化，妥协和让步。改变一个需求需要进行大量严格的审查，因为这通常对涉众间的合同有很大影响。我建议我们使用规格说明来代替需求。规格说明是可以更改的，而且可以理解为我们现阶段对项目的认识状态。
　　就我所见过的而言，用户规格说明有两种重要形式。第一种是观点陈述（或用户需要），它抓住了开发团队和买方或说用户之间的合同。这些信息应以用户可理解的形式（一种包括了文本、原型、用例，电子表格等等的特殊格式）表现。一个支持观点陈述的用例模型起到了用户或买方可以理解的语言表达可操作的概念以及期望的行为的作用。
　　规格说明的第二种形式与需求非常不同。我倾向于使用评估标准这种说法，它被自然理解为目标的瞬间快照，而目标是一个生存周期的中间检查点，比如一个可演示的版本发布。评估标准是从观点陈述或者其他资源（制作/购买/复用分析、风险管理相关、架构方面的考虑、隐藏问题、实现限制、质量极限等等）中派生出来的中间的指导目标。它们与用例模型一起，为早期测试，而不是为传统的需求表达提供了更好的框架。一个计划的发布内容序列和计划的评估标准的初始提议就是一个风险管理计划的很好的形式。

上一页12下一页