|
|
|
2003年9月-10月
|
导航：Mypm.net>PMTW>2003年9月-10月期
栏目：编者寄语
译者：龚辉、王蕾、贺炜，PMU翻译组
校对：徐文宇,PMU翻译组
|
|
欢迎您志愿参加该杂志的翻译与校对工作，请联系translation@mypm.net
|
|
软件项目的十大与众不同
|
詹母士.巴洛克
一个经验丰富的项目经理在接手公司的软件项目管理办公室时向NewGrange论坛咨询：我应该在软件项目中注意些什么？
其中一个答复列举了软件项目和非软件项目的四个最大的不同之处。加上其他一些软件项目的参与者的鼓励，论坛最后归纳出了软件项目在十个方面的最大特征。本文就列举了软件项目和其他项目的十个不同之处，它们往往是一个没有过软件项目管理经验的项目经理可能一下子不容易掌握的。
这些特征分成几个部分：本质的不同，开发过程的不同，软件项目管理的不同和软件项目经理职责的不同。它们都是基于了对“敏捷”开发，软件开发过程的观察和一些相关文献资料的参考得出的，这些观察研究总结了20多年的实战经验，其描述的是软件项目之细微的不同之处，而不是一些显而易见的地方。
作者詹母士.巴洛克在在的书中解释说：“我有幸负责编辑项目管理讨论集一书（请参见以下Dorset House网站地址：:http://www.dorsethouse.com/books/rpm.html）, 它来自40多个项目管理、直线经理和管理者之间展开的对话，并按照描述一个个原型项目的故事形式组织起来。内容几乎涵盖了方方面面的问题，因为是指示和相互建议的形式，让它看起来很象是抄袭来的。但假如在我为一个软件项目工作时，必须拥有一本非软件项目管理的书在桌上的话，那应该是这本，我一直情愿如此。
阅读英文原文：下载英文PDF
我曾花费大量时间向非软件专业人员，包括客户、支持机构、项目发起人，有时是项目经理，解释什么是软件项目。多年以前，我曾帮助PMI培训项目经理，那是一个多年来一直负责工厂设备安装项目的机械工程师，培训要帮助她具备能力来挽救一个陷入困境的但至关重要的软件项目。既然项目已经上马而且又十分重要，她负责了其中大部分的软件开发部分项目。她首先得对软件项目和其他项目的区别有所了解，还有就是软件专用词汇、对任务的合理检查、技术和产品的了解，就足以帮助她成功了。软件项目有细微不同，但并非处处不同。
就在上个月，一个经验丰富的项目经理在接手公司的软件项目管理办公室时向NewGrange论坛咨询：我应该在软件项目中注意些什么？（见引言1）尽管我很久以来一直向非软件人员解释什么是软件项目，但我从来没有记录下我的答案。我的回答从最初的四个方面变成了十个，所有，以下就是专门为非软件项目经理准备的软件项目的十大不同之处。
软件的本质区别
软件和其他产品项目的最大不同不是物质方面的。软件包含思想、设计、指令和公式。开发软件几乎完全是一个认知的活动。我们能看到和感知到的东西，从代码文件。。。(此处无法准确理解)。 他们代表了真实的东西，反之亦然。并且，只有当软件作为真实的东西存在，就算仅仅是在屏幕上彩色的字符那样真实的存在时才有意义。让一团思想的东西称为一个真实的东西是软件的一个最大最特别的挑战。
1-软件项目的典型成果不想其他项目那样可见并且很好理解。既然软件没发象砖头一样可以踢得到，你必须想出办法看到它就在那里。程序跟踪通常是软件里最难的事情。一些重大软件项目失败了，是因为前期的结果象设计并没有象我们原先设想它的那样。相比软件，我们能够更清楚厂房设计蓝图是否正确、完整和有效？一些所谓的敏捷项目失败了，是因为他们没有一整套完整的知识和方法来完成。软件项目的生产过程透明化需要两个条件，它使我们可以摆脱砖头。首先我们需要一个不可见的思想的东西的代理，其次我们需要能看清这个代理的状态。所以，要让这些“已完成”的东西在那里是一致而且可见的。为每个子项建立一个“客户”，并检查每个“砖”是否已经达到“已完成”的标准。有效的软件工程方法、工具和管理思想对保持透明度和完成任务是同样重要。因为软件是思想的东西，有效的测试比任何其他东西都更难进行，但也更有价值。软件测试就是要建立代理对象并检查有效完成情况。逐步交付和重视早期测试能够保证在项目过程中总体蓝图和每个步骤都很清晰。
2-软件项目的最后完成状态比其他项目有更多的不确定性。有时，我们对我们想做的东西最多也就是些含糊的概念，而有时我们的想法是清晰的，但忘了告诉给其他人听（通常指内在的需求部分），通常想法还会在这过程中改变。因为软件是个相对新的领域，软件项目几乎都涉及创新的做法－将软件应用到新的或者其周边问题中。我们逐渐发现想做的就是我们正在做的。研究软件能做什么是给我们提供了一个平台，以便研究软件的更多用途，这是有足够理由的。出于许多原因软件项目的目标是一路变化的，但其变化的识别比之砌到一半的墙要困难一点。所以软件项目需要一点一点地管理正在完成的部分。使用渐进方式和反复检查有利于将整个过程中新的价值和挑战包含进来，也可以去除掉一些不切实际的需求。这种不切实际的需求的影响很大，循序渐进的时候，测试可以帮助发现新的功能，不切实际的需求和软件变更。通常情况下，软件的开发和测试是基于事先规定的投入和交付成果的基准，并基于这样的经验来为其他项目制定投资数是有意义的。
3. 我们所谓软件和软件开发的项目有着不可思议的多样性。设计一级方程式赛车不同于设计明年的Camry车型，也不同于设计通用汽车新的燃油汽缸的多用途平台，这都和汽车设计有关，但我们却以完全不同的活动来区别对待。一定程度上我们看待软件开发的方式和在赛车、Camry和汽动平台的产品间的不同一样。但不论如何，软件开发还是和汽车生产不一样。软件更象是轮子，它是一个物质。然而，软件开发更多的是设计而不是生产，不同系统的软件开发象是设计不同的赛车、Camry和新的汽动系统。系统用于解决不同的问题，对软件设计过程来讲，每一个软件的设计过程都是不一样的。基于如此的多样性，我认为通用的软件方法论简化为“做有意义的事情，跟踪任务，交付成果”。你的软件项目可能和模板项目和上一次项目完全不同，它并不象模型中那样，那就相信你自己吧。
软件生产
即使是具有交付的可预见性和稳定的目标，软件生产通常还是会发生较大的变动，并且经常无法预知，部分是由于“软件生产”也意味着许多其他的内容。所以，一个软件项目经理必须积极地去了解在他们的特定项目中生产是如何进行的。
4-从编码定义到执行填充的生产链在总处理能力、可用度、可靠性、甚至可变性本身都有很大的不同。软件生产在应用技术、平台、甚至同一生产链的配置之间也有不同之处。软件生产因人而异，随工作环境而变。就软件而言，我们无法保证能够在任何给定的进度下将粘土制成砖块，虽然上个星期我们做的很好。
软件项目也包含着生产工具及方法的自主或强制的变动，这会改变你所预订的生产计划。胡佛水坝采用新式方法来加速混凝土的熟化，使进度提高了一百多倍。生产过程中的这种变化在软件项目中也很常见（虽然有时是朝着错误的方向）。所以，为了适应生产，就要调整项目计划，包括进度、修正和附加行为。渐进主义在这里又一次奏效了——你可以随时校准，并注意到情况的变化。作为项目经理，重新规划一个软件项目不是走形式，而是必需的。
5-编码生产在工作性质上千差万别。编码生产主要包括：发现、调查、设计和创作、生成代码、集成或其他。如果你的项目主要是象Y2K那样的纠错，“编码生产”也是一种生产，过程制造模型也可应用其中。如果你的项目基本上属于新系统开发，“编码生产”更像是我们所谓的制造产品设计。即使你得到了很多编码，制造模型也不能应用到设计当中。就像报纸专栏的写作可以重复，而汇编副本的排版不可重复一样，编码生产中的设计和发现也是可以重复的。所以，实现和安排此类编码生产，可能需要几次变动，可能在项目寿命期中一直变动，也可能同时需要进行多种编码的生产。大多数方法论采用特定的生产过程，它仅在某些时候才与现实相符。
6-软件生产包含着很多生产软件之外的东西。前端（定义前）和后端（执行后）生产过程比编码生产的变动还多，它经常支配着项目进程、风险和可变性。非生产活动也充斥着整个项目，如组织变化、团队信息和技术应用。更糟糕的是，“完整”的编码并不意味着已经完成。例如，某些环境为你管理配置（或多或少），而其他环境没有，所以“做完的”编码也包含着许多后端工作。
软件项目可能包括软件生产方式的变化——就象发明新的方式浇铸混凝土来加速建造胡佛水坝一样。通常，当我们改变了一种软件的范围后，我们的测试和配置方法也不得不变化——由于采取标准化生产，它不会显现出来。为了成功地完成软件生产，你必须管理项目中的非软件生产部分。当重新规划软件项目时，整体任务或范围模块可能出现或消失，并伴随着生产率的调整。当一种行为出现，正式方法不会排斥它，但是会最明显地去定义它。
经营软件项目
在变化较少的领域内，管理一个软件项目与其说是管理，不如说是经营。经营软件项目是一场与客户、发起人、技术团队、供应商和支持组织的持续的谈判。
7-没有任何纯软件项目。软件至少需要运行的硬件和使用它的人。硬件必须被详细说明并配置，通常还要被发明。使用软件的人使世界发生变化——这才是要点。这适用于拆封和嵌入系统以及明显的IT系统。所以，如果你经营一个软件项目，你要么不得不拥有项目的非软件部分并负责整个价值陈述，要么需要清晰的接口和其他部分的跨区转接。接口和跨区转接有一点难度，因为软件产品的物理性不是非常明显。
软件开发能力通常是有限的、共享的资源。它不是按照日程得到一队水泥卡车来浇铸工厂地面，我们要得到我们想得到的东西。开发商经常会承揽几个系统。再加上我们经常要考虑一些我们能够对这个系统所做的其他事情，所以，软件生产总是超额认购的。由于脑力工作者占大多数，多重任务开发商降低了生产率和士气，并使得它们难以捉摸。所以，要像工作室一样分配工作，对待致力于单一项目的团队。在单一产品或系统内，我们使用迭代法并允许大块制作。软件独一无二地适合渐进主义，因为它通常能交付附加价值。一个制造厂可能没多大用处，除非它大部分在那。如果我们正确地挑选出了软件中有用的10％，就可以说软件总是有用的。
9-软件项目的工具和方法是可以调整的。所以，如果每五分钟重建软件有助于编码生产的话，就调整你的环境去做吧。如果你依赖于数据库中的数据，但是你不了解数据库手段——那么，制作一个副本或伪造一个副本。如果推动软件到1万个点火系统是缓慢并昂贵的，那么，在你耗费数百万美元和数月的市场时间之前，调整你的方法使其绝对正确。你可能需要引导点燃的碎片，当实际的交易发生时，你会遇到一个缩放比例问题——1万是一个大数目——但是知道功能是正确的，启动是有效的。你可能需要发明一种并行启动1万芯片的方式。软件工具与制作砖头或混凝土的工具相比，具有更大的延展性，所以注意到损坏了的东西，修好它。在软件工具和技术中，发明新工艺既是共同的需要，也是共同的失败。跳跃在迷人的新路上同坚持走在失败的老路上一样错误。我喜欢重申每个项目增量的过程和方法——“我们怎样做下一步更好，更快更便宜？”然后明确地按照项目计划追踪过程或方法的变化。
软件项目经理的职责
所以，软件项目是有几分模糊的项目——象非软件项目，又不止这些。通过软件，我们不需帮助就能使其他种类的项目成功，象大多数人完全知道工厂是什么样子、能数砖头一样，我们拥有丰富的混凝土生产和建筑经验（肯定有2000到2500年，可论证的更多vs软件不足60年）。假定条目10全部是显而易见的。
10-雇佣一个软件项目经理是有原因的。挑战性的项目需要领导者和经理，不仅是管理者。你管理项目并对项目成员提供支持，使他们能够应对变化的目标、多重的需求、变化的生产、各自环境中偶然的（或有准备的）变化、多重任务、新方法等。项目（和生产线）管理有一个巨大的诱惑，后退到管理：方法论说. . .那些糟糕的和不幸的客户、开发商、利益干系人、激动的人说. . .PMO要求. . .太难了，太复杂了，太胡涂了，太模糊了. . .让它发生是你的工作。如果你不能解决它（可能通过发现一个值得信赖的顾问），那么你的工作描述就是无效的。
这个建议也是针对软件项目发起人和软件项目经理的。任命你手下最好、最认真、最机灵的人管理软件项目。放手让他们管理。对他们满怀期望，但要支持他们，否则他们的工作描述也是无效的。
其他选项：关于敏捷方法
近来，软件领域中的敏捷方法引起了许多的议论。极端规划XP是一种最常见的敏捷方法——指定了12个核心准则。这里是额外的关于XP的两项，使得总数达到12。
11－敏捷方法包括了渐进改革和足够好的成功标准以接纳处理在软件生产中的未知事物、发现物及可塑性。到目前为止，一切都很好。常常会有我们不知道的材料。我认为成功的软件项目总是以渐进且令人满意的方式进行。 (2)大爆炸的方法总是在隐含假设“它总是更好的”下来进行，如果可能，甚至要提前计划并设计好每件事。有时做些尝试更为有效。有时我们还不知该如何。但是，（这里就是异端情况）有些事情早知道比晚知道强，有时你可以提前了解的很清楚（令人满意的）。与建一个工厂相比，很难提前估量软件所需要的“砖”的数量。我相信一个真正的敏捷方法在项目早期，在考虑真实的、已有的风险的同时，遵从低风险决策原则，直到有更多信息。XP有一个关于避免在项目早期过度设计和过度规划的名言：你不会需要它，我更愿意知道，我们现在实际需要解决什么问题？
12－敏捷方法是对于方法、工具、政策、原则和价值评估的高度说明。这些方法被成功高产的软件开发团队和长期项目所采用。（这里异端再次出现）我认为如此的规范使得他们正在丢失一个诀窍。例如虽然12个XP准则是个好的开端（并且不是新的），但我并不认为他们对于所有的软件开发过程都是必要的或者足够的。如果其中之一没有用我不会坚持所有的12条，如果其他别的原则有用，我也不会限制自己。当前的工作是对于较大的项目和系统、维护系统和遗留系统以及像游戏或者嵌入式系统采用敏捷方法。如果你与“敏捷方法”的实践者在管理一个软件项目，他们会有很多好的主意，并且特别热衷于在软件开发中应用。但是，一旦敏捷成了目地，你就会冒有“手术成功但病人死亡”的危险了。要明确哪些有用，哪些没用，并据此来调整方法和工具。想要有收益，就必须有意识的尝试新的技术，无论它是否是在XP的变化的12条之内。最终的敏捷是项目的成功所必须的，无论他们是什么。
参考文献：
Dwayne.菲利普的《软件项目管理者手册》的一个主要的主题便是使软件项目中的遗留物直观可见。那里有许多使得信息和遗留物可见的软件技术，来自Gilb 的非功能需求或者Cockburn 提出的用例中的扩充的数据，以便用自动回归测试方法持续的构建系统。手工可视化技术可以在检查和回顾中找到，例如Gauss 和Weinberg著的《检查手册，预演和技术性回顾》。一些组织的软件顾问会进行快速的个人评论，只需要30秒，但你或许不喜欢所发现的东西。其中有些列在项目管理的项目指示过程指示的协商会上以及其他一些地方。
渐进主义在参考文献中有述，最早可追溯到Brook的《人月神话》，Barry Boehm 的关于螺旋型发展的论文，在Richard Thayer 编的IEEE的软件工程项目管理手册中再版，以及Tom Gilb 的《软件工程管理原理》。在这些敏捷方法中，XP沿着发展增量的方向构建起来的，而SCRUM 则实现了项目水平增量。
人的共同思考过程在DeMarco和Lister的《人件》、Constantine 的关于人件的论文和Weinberg 的《计算机编程心理学》、Robert D. Austin 的《组织的管理和性能量测》－一本远比题目要好的书－是一个对于量测滥误用和无意识推理规则的扩展研究，应该为组织中任何创造奖金的人所读。
“软件项目中的调整方法是改进发展系统模型的主题”，我的在IEEE Computer杂志1999年10月期上的James Bach的软件实事专栏的特约文章。软件测试的内容驱动学派全部都是针对于手边问题而调整方法。Alistair Cockburn的水晶方法也是基于调整软件发展方法以对应手边的问题。Gerald Weinberg的品质软件管理系列丛书是关于获得对于软件开发系统是如何为我们工作的可见性的，特别是第二卷，一阶量测。
Gilbreath 的不幸的命名为《赢得项目管理：什么会起作用，什么会失败以及为什么仍是组织中最好的担当项目管理者角色》。Robert Glass的《软件大逃亡》用一些不著名的例子项目来分析软件项目如何走错路的。他们中没有一个软件产品失败。一个有趣的文献是Tom DeMarco 的小说《最终期限》，它的很好的特点在于一些署名作者是为故事中的项目作顾问的。生产线－你工作的描述是不起作用的，来自Tracy Kidder 的《新机器的灵魂》，也在推荐之列。
一位有思想的XP的实践者，Laurent Bossavit 维护着一个Blog ，网址：http://www.bcr.com/bcrmag/2002/05/p06.asp
关于修建胡佛水坝的信息来自James Tobin 的《伟大的项目》，该书也描述了因特网的起源，阿波罗计划和乔治·华盛顿大桥。
我被授权可编辑修改《项目管理的协商》（可从多西特出版社获取http://www.dorsethouse.com/books/rpm.html）－40多个项目和生产线管理以及实践者，围绕一个原型项目故事组织起来的。它覆盖了迄今为止，直接、对等的提出建议，从而较为实际的形式而命名的所有事务。如果我在进行一个软件项目的时候不得不将一个非软件项目管理的书放在桌子上，则它就是合适的选择。我自己曾经用过这种方式。
其他选项：软件生产过程
软件项目的一个常见问题是对于软件产品的范围的混淆。开发，或者软件开发尤其会被这样滥用。许多项目的失败源于他们不会考虑软件产品的所有部分。上面的# 4、#5、#6和#7分歧是关于软件产品在软件项目中如何被误解的。
产生代码的行为各式各样，比如生产和可重复性（分歧#4和#5）。软件产品，意味着得到了一些可用的、可运行的软件，可以做你想要做的，包括许多除产生代码外附加的行为（分歧# 6）。最后，在一个更大的项目中产生软件实体，如果软件有用（分歧#7）。
作者简介：
James Bullock在构建系统方面已经有20年的专业经验了。他的经历包括为热力泵构建高容量内嵌控制软件、生产平台自动化、企业级数据仓库、为数百万的SLOC 代码库作软件工程工具、创建测试框架和测试工具并测试大型IT部署以及一对主要的电子商务网站。他也运行小型的软件开发项目，主要的IT部署，包括开发、转换项目、开发工具团队、项目特定QA团队、QA部门以及一个自动测试实践。 James 是多西特出版社项目管理协商的主编。.他当前的研究中心是使用并教授一般系统工具和思想，模型化并提高组织或者项目的发展过程。他住在西雅图，联系方式：jbullock@rare-bird-ent.com
|
|
|
|
项目管理者联盟授权翻译，请勿转载
|
|
