《软件团队模式设计：团队质量决定产品质量》_项目管理书籍_

用户名密码

·VIP会员申请
·施工企业管理
·联盟特刊下载
·工程软件光盘

新闻 | 文库 | 培训 | 软件 | 书籍 | 专题 | 认证 | 招聘 | 下载 | PM俱乐部

联盟访谈电子杂志个人专栏新闻专题 PROJECT 互动： 案例咨询论坛博客

职业认证: PMP NPDP PgMP IPMP P2 MPM 建造师 行业应用: 基础工程软件制造活动研发

服务区	网站登录：个人会员企业会员专家企业服务：PMP培训内训课公开课工具箱：发表文章提问题交案例

搜索： 项目管理者联盟PMP培训班（2018年度）项目管理者联盟NPDP培训班（2018年度）

邮购方法

发邮件到:member@mypm.net
a. 姓名
b. 通信地址/邮编(您收书的地址)
c. 书籍购买信息：什么书多少本
d. 汇款信息：汇款方式汇款时间汇款金额
汇款至项目管理者联盟
方式 A：在线支付
方式 B：邮局汇款
收款人：华琰
汇款地址：北京市西城区德外新丰街2号A座705室
邮编:100088
方式 C：银行汇款
开户名：宣晓锋
开户行：工商银行北京市西城区黄寺大街储蓄所
帐号：0200219601020858639
工作人员核对汇款信息与购买信息后，即日发书
备注:
1.每单收5元邮寄费用
2.汇款总金额=书籍总金额+5元
3.书籍用挂号寄出,约2周左右寄到
4.如需使用快递购买,快递费由买方支付
5.如需开具发票,请提供发票开头.并加付书籍总金额5％的费用.
6.电话咨询：010-82273401/11/37-11

经典书籍


	原价 49元

书名：《项目百态—软件项目管理面面观》

原价
48元

书名：《项目思维:为什么很好的项目经理会做出糟糕的项目决策》

原价
108 元

书名：《项目管理最佳实践方法达成全球卓越表现》

邮购热线：

member@mypm.net

010-82273401-11

市场价：￥29元

本站优惠价：￥元

软件团队模式设计：团队质量决定产品质量，Software for your Head: Core Protocols for Creating and Maintaining Shared Vision

【译者】
【著者】	Jim McCarthy(吉姆·麦卡锡) Michele McCarthy(米歇尔·麦卡锡)
【书号】	7-5053-9240-9
【出版日期】
【出版社】	电子工业出版社

【字数千】
【页数】	256
【所属行业】	IT软件
【所属主题】	项目团队管理

本站优惠价 ("0"表示无存货)邮购热线:member@mypm.net；010-82273401-11

内容简介

内容简介：本书是打造优秀软件开发团队的制胜宝典，揭示出只有高质量的团队才能开发出高质量的产品。作者通过亲身经历和长达5年的调查研究，经过不断实验，寻求出一种能够引导软件开发团队获取成功的科学工作模式，并形成一套能在5天内培训出高效团队行之有效的基础教学体系。在本书的编写中，作者结合软件开发团队的特点，以编写软件的形式，把团队建设与团队工作的核心要素，通过模式、反模式、定义、协议等形象的比喻体现出来，使读者深刻领悟其中蕴含的丰富内容，最大程度地在团队工作中发挥个人的智慧和才能。读者对象：适用于软件开发人员和项目管理人员。

作者介绍

吉姆·麦卡锡和米歇尔·麦卡锡在从事微软公司、白水集团、贝尔实验室和其他公司的产品开发和程序管理工作之后，于1996年成立了麦卡锡科技有限公司。吉姆·麦卡锡还是《软件开发动力》（微软出版社，1995年）一书的作者。

图书目录

序言前言

译者序
序
第1部分  预备行动
第1章  预备行动的要素	
1.1  超越距离	
1.2  预备行动协议	
1.3  退出行动协议	
1.4  省略协议	
1.5  沟通	
1.6  有问题的行为	
1.7  与预备行动协同的模式	
第2章  预备行动模式与协议	
2.1  模式：预备行动	
2.2  对预备行动的附加讨论	
2.3  模式：退出行动	
2.4  模式：省略	
2.5  模式：沟通	
第3章  预备行动的反模式	
3.1  反模式：过于感情用事	
3.2  反模式：处事圆滑	
3.3  反模式：对错误的容忍	
第4章  预备行动家族中
第4章  的其他模式	
4.1  模式：团队=产品	
4.2  模式：自我关照	
4.3  模式：思考与感受	
4.4  模式：伪装	
4.5  模式：伟大的循环	
第2部分  最终决策
第5章  最终决策的因素	
5.1  与其他决策相关的因素	
5.2  反模式	
第6章  最终决策模式与协议	
6.1  模式：最终决策	
6.2  模式：解决	
6.3  模式：有目的的工作	
6.4  模式：观点生态学	
第7章  最终决策的反模式	
7.1  反模式：回避解决	
7.2  反模式：漫不经心	
7.3  反模式：势力范围	
7.4  反模式：上司不授权	
7.5  反模式：团队庸医	
第3部分  调整认识
第8章  调整认识的因素	
个人和团队的调整认识	
第9章  调整认识的模式和协议	
模式：调整认识	
第10章  调整认识的反模式	
10.1  反模式：人员不足	
10.2  反模式：自我调整	
第11章  调整认识模式	
11.1  模式：个人调整认识	
11.2  调整认识工作的
11.2  方法和原因	
11.3  模式：调查	
11.4  模式：理解力	
11.5  模式：承诺网络	
11.6  模式：请求帮助	
第4部分  共同目标
第12章  共同目标的要素	
12.1  共同目标的各个方面	
12.2  建立共同目标过程
12.2  中涉及到的模式	
第13章  共同目标的模式和协议	
13.1  模式：共同目标	
13.2  模式：超级目标	
13.3  模式：远期目标	
13.4  模式：版本	
第14章  共同目标的反模式	
14.1  反模式：盲目状态	
14.2  反模式：技术至上	
14.3  反模式：反冲力
14.4  反模式：反馈	
第15章  完善游戏模式	
游戏和完美	
第5部分  附录
附录A  基础课程的专用词汇	
附录B  新兵训练营资料	
附录C  基础课程协议1.0版

序
基础课程1.0版的背景
    我们并没有创建基础课程，而是看着它成长起来。然而，我们与约翰·雷格兰泰共同确定了初始条件，并以此为基础，形成了基础课程协议及其他诸如此类的东西。这些年来，我们为基础课程的发展提供了便利的条件。在此过程中，我们还不断修改和订正，防止基础课程向错误的方向发展。此外，我们也奉献了自己的金钱和时间，关注基础课程，并付出了极大的耐心。我们精心保护它，进行详细记录，不断尝试，最后将它奉献给读者。
    感谢数百名产品开发人员和来自世界各地的学员，这些年来，他们对基础课程的发展做出了贡献。之所以会有现在的成果，完全是集体智慧和努力的结晶，而不是某个人的成果，整个过程既是简单的又是复杂的。
    可以说，我们从1994~1995年的经历导致了基础课程的出现。当时我们为一家商业软件公司工作，领导一个约有150人的开发团队。我们自创了一条格言，来帮助自己尝试新的观点：
团队=软件
    就是这个观点，其中既有优点，又有缺点。不管别人怎样看，该格言几乎成了我们神奇的“咒语”。在危难之际，当我们面对复杂的软件开发要退缩时，当我们心怀疑惑和困惑时，当时间不断流逝、目标渺茫、前景暗淡时，都是如此。在我们最需要的时候，团队里总会有人想出新点子，依靠“团队=软件”提出了新鲜的观点，然后滔滔不绝地讲出一些能够解决问题的新方法。这些观点有时非常出色，虽然更多的时候差强人意，但总会有用途。
   “团队=软件”的精髓在于，团队的行为直接与其产品对应，反之亦然。如果想要生产具有某种特性的产品，在产品开发之前，就必须确保该团队具有那些特性。
    我们还认识到，每个人都有自己的产品制作思路，都贡献了自己的力量。每个人都展现出自己的价值观念，将人的美德和缺陷体现出来。
我们的领导团队在做些什么呢？我们将说明组织的各个等级，并针对每个兴趣点回答两个相关问题，即其中的团队是谁？它的产品是什么？
    我们将一线开发人员称为一级团队。一级团队生产实际产品。该团队的管理者构成了二级团队，其产品是一级团队。应用“团队=软件”这个公式时，一个级别的团队成为下一个更高级别团队的产品。如果二级团队从一级团队中看到了令人不快的情况，其中必定反映了二级团队的工作情况及二级团队成员的表现。该模式适用于所有级别的团队，由下向上，直至全部等级。
    这种观点看起来浅显易懂，有些标新立异，也可以说有些牵强附会，但对于我们来说，确实很有用。使用该模型，没有人能躲避责任。就我们的工作状况而言，即使是上司，除非能亲自证实这一点，否则不能指责某个团队一无是处。如果我们不能亲身模仿出这些问题，也就不能指望找出补救措施。一方面，这种情况很令人沮丧，因为一切都无法逃避：责任不可避免地要向上移，沉重的负担不时地落在我们的肩上。虽然我们的报酬丰厚，但是缺乏锻炼。另一方面，这也使我们可以从崭新的角度更为直观地来看问题，可以把事态完全置于我们的控制范围之内，而且能够用于补救团队工作中的任何缺陷。
    如果看到某些事情已经乱成一团，或是注意到某些事情正在走下坡路，我们可以立即找到问题并加以改正。为了激励其他团队成员获取胜利的果实，而不是等待它腐烂直至灭亡，我们应当随时采摘果实，品尝它的美味。
    如果想让一级团队具有特点，就必须将这些特点融入自己的行为中。这种行为上的改变从概念上来说很简单，但实施起来却颇具挑战性。在任何情况下，牢记这一点都会得到解决团队问题的许多新奇方式。第一次应用这一观点时，就很快出现了许多新的可能性，速度快得使我们几乎跟不上前进的步伐。尽管许多小测试和几个大测试曾经产生过预期的结果，但是我们也得到许多新的方案，来帮助我们解决那些多年来一直困扰着我们、使我们几乎不知道从哪里入手的问题。我们很快认识到，我们不可能进行充分的试验，完全精确地理解该公式的用处，发现它在什么地方会失效，或看到它所激发的行为将会把我们引向何处。我们想要探究的是动力，并在所支配的系统中以各种方式检测它。
遗憾的是，在商业软件的开发过程中，试验的机会必然很有限，主要的障碍就是时间不足。大型商业软件项目可能需要数月或数年的时间。我们看到的潜在机会非常有价值，然而，如果要了解每件可能的事，即使是几个月，对于每个开发周期来说也太长了。一次开发需要数百万美元，若是完全进行试验，似乎要冒相当大的风险，可以进行补救的余地很小。总的来说，缓慢、繁多的日程安排，在实践中谨慎求稳的做法，都与我们所想要实施的具有持续性、完整性、快速的试验相抵触。但是，我们仍然认为，在团队开发过程中，有可能、有机会产生大的突破，从而使任何团队成员的合作都变得更加简单而有效。
    为了深入学习，我们必须在很短的时间里完成一个开发周期。人的生命短暂，不能经历很多的开发周期。即使是某个开发项目经理非常勤勉、可靠，而且集中全力地工作，如果他长期管理开发工作，在其专业生涯中，也只可能监督10~20个项目。在这些项目中，有许多项目可能是相同的团队开发的，这就减少了团队资源的多样性，而多样性会丰富该经理的知识和能力，并加速试验的进展。
    早在1996年，为了增加我们试验的数量和广度，我们自己建立了一个实验室，用于该项研究以及团队培训。在我们决定如何运营该新实验室的时候，基础课程协议最终成为必然的选择，我们将其命名为“软件开发新兵训练营”。主要进行重复的产品开发模拟，大约每个月一次，每次对每个团队持续五天五夜。开发人员将按下面4个步骤完成开发工作：
- 成立团队。
- 想像产品。
- 就该产品如何制作进行协商，达成一致意见。
- 设计并且构建该产品。
    在一个星期结束时，该团队必须按时交付产品，或者自己选择是延长时间继续进行，还是停止。
    我们知道，我们可以成功地进行这样的产品开发过程，如果需要的话，甚至亲自领导这个过程。我们多年来所做的就是这些，在各种环境中求得生存。我们有充足的信息、技巧、技术以及丰富的实践经验，向大多数学员传授有价值的知识。我们可以教他们如何去做，保证在自己的产品开发过程中获得成功。无论是现在还是将来，是模拟的过程，还是非模拟的过程，均是如此。
    我们领导或参与了数十个开发过程，在这些过程中，我们获得、组织并掌握了丰富的经验，结果证明这些经验多数都相当成功，因此所形成的知识体系成为了第一个新兵训练营团队的起始点。即使我们自己在新兵训练营中什么也没有学到，我们仍然会向学员奉献丰富的经验。
    在新兵训练营，我们有效地将软件开发周期压缩成五天。在这五天中，学员们学到了通常要在长期的开发中才能学到的东西。在新兵训练营中，会遇到成立团队的过程中通常所遇到的全部失败和成功的经历，确立团队共同的目标、进行设计、实施并交付产品。每一天，团队都在加速运转，通常需要一年或更长时间才能开发出来的东西，在日以继夜地忙碌几天后，就创造出来了。
    在新兵训练营，随着经验的增多，我们领悟了许多新的观点。通过与大约60个不同的软件开发团队的密切合作，我们加快了学习的步伐。首先我们帮助成立团队，然后帮助开发产品。我们以难以置信的频率和速度完成开发周期，在高峰时期，甚至达到了每个月一两次。通过与各个种类以及不同成分组合的团队一同工作，通过新兵训练营建立之前和之后的工作，我们将所学到的经验和知识都应用到团队工作之中。
    另一个因素导致了基础课程协议的创建，并由此确定了学员的任务。每个团队务必在一个星期之内建立一个产品。但新兵训练营团队将制造什么产品呢？
    从某个角度来看，新兵训练营的概念很简单，即我们将一组软件开发人员聚集在一起。有时，学员是原有团队中的成员；有时，他们代表了众多的开发人员：公司职员、企业家、计算机科学家、软件测试人员、作家、编辑、图形艺术家、编码人员、经理、执行官、程序和项目经理，以及生产者；经常也有非开发人员，如护士、教师、家庭成员、顾问，以及出版界成员。我们给每个新团队一项简单的任务：
    设计、实施并交付产品，通过这一过程教会大家掌握每次都能按时完成优秀软件所需的条件。
    自第一期新兵训练营以来，该任务一直保持不变。对我们而言，比较有用的方法是：在有效的团队工作状态下，以实际工作实时的视角来看待团队的动态特性。只有团队展示出最理想的工作状态，才最有能力解决这样的团队合作难题。
    新兵训练营致力于解决团队问题，努力使团队状态保持良好。这是一场生产性的革命。团队获得新的高效状态，从而产生非同寻常的结果。当他们检查其高效的条件和要素时，所获得的都是实质性的结果。
几乎每个新兵训练营团队都考虑到下面的情形：如果团队工作本身可以变得更加有效和直接，该团队成员将能够找到解决方案，解决受到困扰的重要问题。然后，以这种知识为基础，使他们的努力获得更大成效。
通常，高效的团队能够完成为自己设定的目标，从而名声远扬。例如，优秀的篮球队会赢得许多篮球比赛。人们之所以能记住球员，不是因为他们在团队精神和科学训练方面做出了贡献，而是因为他们将球投入篮筐中。实现团队目标是一项任务，并不直接和明确地揭示团队的状况。就新兵训练营团队而言，当前的任务是对总能形成优秀团队的各项规则进行观察、提炼和汇编。
    随着开办一个又一个的新兵训练营，我们开始掌握了使团队获得成功的最佳规则，我们将对这些行为进行编码，使其易于表达和接受。从新兵训练营的经历中产生的这些经验，逐渐发展成为基础课程协议。如果某团队经常应用基础课程协议，就会产生出众的结果。
    在基础课程协议的推动下，整个训练过程得到发展，产生更加高效、更有能力的集体。我们看到每个新的新兵训练营团队学到更多知识，取得更多成就，并为基础课程核心的“多人”模式和协议增加更丰富的内容，更具生命力时，这些课程再次明显地得到加强，使新兵训练营的训练过程得到全面发展。
    这就是我们的故事，我们关注基础课程协议形成的全部过程。
基础课程的基本原理
    我们对那些有助于团队产生满意结果的行为信息进行了编码，将这些信息组织、加工、分类，构成了一个小的知识体系，从而组成了基础课程。
( 四个核心构成
- 模式
- 反模式
- 定义
- 协议
    对于将会采用新兵训练营的用户来说，基础课程协议在这四类信息中最为重要。基础课程的模式与反模式，清晰地说明了我们在设计基础课程协议的过程中为何做出许多选择，而基础课程协议则细致、正规地阐示出我们推荐的个人行为与团队行为。基础课程协议已经通过多次反复的试验和开发，而且在相当长的时间内被许多人使用。我们相信，始终如一地正确应用基础课程，将会产生非常好的结果。即使基础课程的模式和反模式的众多观点都存在着严重错误，在我们发现和尝试的各项实践中，使用基础课程协议仍然会产生最好的结果。尽管我们不知道为什么会有效，但我们确实知道，其中具有有益的效果。
    另外，应该注意的是，需要深入理解并真正接受基础课程定义中的一些专用术语，以便恰当地应用基础课程协议。想要做到这一点，就必须同样重视定义与基础课程协议。
模式
    模式（pattern）是在整体环境中通过有效沟通获得问题解决方案的一种标准化方式；应用模式将会产生某些现象，并告诉你这些现象是如何出现的。如果应用模式，可能会得到特定的结果和结局。例如，应用某种服装模式，便会产生所需的服装，但是却限制了穿着者的选择。使用基础课程模式后，许多团队的表现要优于他们自己的预先期望。
    对于软件开发人员而言，“模式”一词具有特殊的意义。在软件行业，模式的观点来自思想家和建筑师克里斯多佛·亚历山大，在20世纪70年代，他首先给这个词赋予了特定的意义。他创造了一种语言，用于记录模式和模式集的结果，即“模式语言”。人们利用这些模式语言进行编码和通信，去实践和完成建筑业中一些重要的观点和目标。
    模式对常见的问题给出了总的解决方案。在软件和建筑业中，“模式”一词的专门含义与该词通常的含义实际上并无太多的差异。如果你得到一个模式，尤其在应用中模式总是获得成功，你就不只拥有模式本身，而是有了一个重要的起始点。你要制造模式，或是学习足够的知识来制造或使用模式。因为这一原因，在软件领域，模式已经作为一种沟通机制被广泛讨论。
    这类模式的经典定义是“某环境中问题的解决方案”。人们难免会对软件模式的定义有一些争论。通常，对程序员面临的反复出现的技术问题来说，软件模式是抽象的解决方案。为讨论问题，程序员去理解和获取软件模式这种语言，由此产生知识的积累。理论上讲，通过模式，人们能够重复使用迄今最好的思想成果，并允许模式使用者访问解决方案的主体。
    我们将模式定义为“拓展才能的软件”。像其他模式概念的应用一样，我们的模式软件，提供常见问题的一些解决方案。基础课程中的模式包含信息、过程和约束力，你可以将其“载入”你的头脑中，一旦经过载入或学习，就可以应用它们。你的队友可以做同样的事情，然后，全体成员都可以共享丰富的资源，包括心理、语言和行为资源等。无论何时，无论怎样，只要你愿意，就使用这些模式吧。
    基础课程模式适用于塑造集体的思维，而且做出决策并加以执行。我们提供这类模式的目标是：
    我们想要创造一个世界，在这当中，团队的行为应该能够步调一致地达到预定目标。
反模式
    这些模式描述了通常会产生恶劣结果的解决方案。实际上，这是错误的模式，是注定要失败的模式。对于基础课程中的每个反模式，我们都提供一种模式或一个协议（或两者都有），这些模式和协议都曾多次提供对该问题的解决方案，取得了令人满意的效果。
   “180度转弯”是一个有点古怪的名称，用来表示我们观察到的特殊现象，这种现象的出现频率比我们料想的更为频繁。“180度转弯”是一种描述传统智慧的观点，但是可能产生令人不快的结果，还会用最恶劣的方式产生出来。“180度转弯”糟糕透顶，如果人们没有遵循讨论中的观点，而是用“180度转弯”来代替，人们执行的步骤与指定或建议的步骤会恰恰相反，他将实际达到“180度转弯”的虚假目标。换言之，传统智慧通常是真的智慧，但是被“编码”成相反的愚蠢念头。
定义
    多数软件系统对于专门术语有自己的定义，通常，系统的作者定义这些术语。自然，这些术语定义的范围是局部的。
在日常语言中，基础课程使用的词汇都可以找到。为了减少日常应用的词汇与基础课程背景中这些词汇的特定用法和含义引起的复杂问题，我们提供了一个定义词典。
- 该词典的目的是指明可能含有歧义的词汇与短语的确切含义。这些词汇与短语在基础课程之外可能有（也可能没有）一般的用处，如果有，我们就再定义它们，因为我们发现，这些词汇与短语的应用通常缺乏精确性。
- 进行定义是为了提高团队的成效，不一定会在团队生活范围之外提供任何实质的价值。基础课程的定义不是词典定义，它们是系统中的标记。
- 该定义有些专断，必须被系统接受才能发挥功效。对于应用基础课程的目的而言，最好将定义看做是直接而局部的公理，具有专门的含义，仅仅是特定的定义。
- 这些定义提供了创建和使用基础课程时所要求的语言材料。该定义只是游戏规则的一部分，是专门的约束，它能够引导进行该项游戏的团队发挥出实质性的力量。
    只要可能，我们就尽量使用与术语试图传达的含义相接近的、确实具有一般可行性的词汇，而不去创造新词汇。这样，任何人都可以明白学习基础课程的团队在讨论什么，而无需重新去理解词典。
协议
    基础课程几乎涉及全部团队活动。基础课程协议的目的是为了确保团队获得几个面向结果的重要行为，同时具备：
- 先前不可能达到的可靠程度
- 高于通常程度的效率
- 更为均衡的责任分布
任何团队都可以使用基础课程协议来达到这些目标。其余的时间内，一如该团队的期望，团队生活会继续进行。
一旦采用基础课程协议，将为团队提供可靠的方式，以高效方式取得下列成效：
- 小组成员之间人际关系更为良好。
- 制定集体的、一致的决策，并且分配相关的责任。
- 团队及个人合作。
- 获得共同的目标，包括
—  长期或远期的目标
—  短期或各版本的目标
—  个人对于团队及个人目标的承诺
—  团队对于个人及团队目标的承诺
许多团队从未取得这样的成就，基础课程协议将它们变成了日常活动。
基础课程协议并不预先定义或限制相关当事人之间所传递的内容。相反，该协议提供机会来传递或接收当事人认为重要的内容。
    基础课程中各个协议概念简单、好记，而且实用。我们已经发现，每一条都极其有效；许多团队都曾使用过这些协议，而这些协议很快成为了这些团队的第二特性。鉴于我们并不希望将正常团队之间的相互作用形式化，我们确实提供了充分的结构，以便团队可以享受特定种类的相互作用，这些作用相互一致、质量优良和可靠性强，而且如团队期望的那样面向结果。

译 者 序
本书是软件开发团队的制胜宝典。作者通过亲身经历和长达5年的调查研究，经过不断实践，寻求出一种能够引导软件开发团队获取成功的行为方式。本书作者有着丰富的软件团队工作经验，对团队工作的环境、人员状态、成功所必需的条件等，做了深入细致的研究。通过总结经验，他们把大量的实践材料上升到理论高度，对团队工作进行了系统的概述和分类，对其中出现的问题给予切中要害的剖析，提出了具体有效的解决方案。在此基础上，他们建立了新兵训练营，把软件开发周期压缩到5天，以模拟方式使参加训练营的学员体验到团队工作中通常会遇到的失败和成功，学到在团队工作中不可缺少的知识和经验。
    随着新兵训练营的开办，作者逐渐掌握了团队工作的最佳方式，形成了一整套结构严谨、内容科学的工作模式，从而创造出最为基础的教学体系，也就是基础课程协议。作者以编写软件的形式，把团队工作的核心要素通过模式、反模式、定义、协议等体现出来，并且具体地加以说明，使读者能够简单明了地把握各个概念，了解其中蕴含的丰富内容。
    作者使用了许多软件术语做比喻，对团队的人际关系、行为方式进行了论述，形象生动，寓意深刻。但译者体会到，本书所含的内容不仅限于软件团队，实际上涉及了所有以制造产品为目标的团队都会遇到的问题，目的是为了最大限度地在集体工作中开发人们的智慧和发挥人们的才能。因此，本书的读者不应只以IT行业人员为主，同样适用于范围广泛的各类集体，使其受益匪浅。为了能使本书所阐述的观点在更多的领域得到传播，获得更多的读者，我们对某些普通读物中不常见的软件术语做了处理，以更容易让人理解的形式表达出来。例如，connection没有完全译为“连接”，而是根据上下文译为“沟通”。我们认为，本书可以作为工具让人们使用，让读者清晰地了解其中的含义就算达到了目的，所以使用变通的方式进行翻译，只求能为读者所接受。当然妥当与否，尚待有识之士予以评说和指正。

译  者
2003年10月

发表评论

书籍评论

如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者