如果希望在软件团队中推动一些行之有效的变更或者施以更大的影响力，那么有两种选择：一种选择是自行对各种技术进行实验，在黑暗中摸索几年；另一种选择就是购买本书，阅读并且应用书中所给出的技术。当然，究竟如何选择，决定权在于你自己。
　　——Matthew Heusser

　　Jim Brosseau对于IT工作环境中各种驱动因素的真知灼见在本书中得到了充分的体现。对于提供IT解决方案的开发人员和管理人员来说，他在书中给出的见解不仅能促进项目朝着更好的方向发展，而且能使工作本身也变得更为轻松。
　　——Bruce A. Stewart，Accendor Research公司CEO

　　本书是一本令人信服的、全面创新的以及切实可行的指导著作，它能够有效地改善在构建优秀软件中的一个重要方面——人力因素。
　　通过与众多团队的多年合作，Jim Brosseau在书中阐述了如何通过小规模的、立竿见影的变更，来逐步推动大型的改进工作。这些变更针对团队整体来设计，充分考虑现有的组织文化。此外，Jim Brosseau还提供了每个人都可以立即付诸实施的方案，而无需等待管理层来推动。
　　无论采用何种方法、技术或者组织结构，通过阅读本书，你都能够掌握如何将各种解决方案应用于实际的开发环境中，这些实际问题往往涉及错综复杂的利益相关者。Jim Brosseau还与读者共同分享了在面对项目管理软件方面的问题时，人们的态度、动机和人际关系方面重要的新观点。
　　本书是一本启示录——对于每个项目团队成员、领导者以及利益相关者来说，它是您工作中的一份宝贵的参考资源。

无

有些书籍当属经典之作，例如 Tom Demarco和Tim Lister合著的《Peopleware》以及Fred Brooks的《Mythical ManMonth》。这些书的内容具有很高的实用价值，但却很少得到应用。我们曾采取过一些行动，并且期待一个更好的工作环境，但最终却不得不抱怨我们的管理层没有积极地推动变更。
随波逐流或许是非常容易的，但要提高自己的工作效率，就必须成为一个积极主动的团队成员。我们每个人都应主动承担责任，培育一个健康的工作环境，生产优秀的软件产品。
每个从事软件开发的人都应该读这本书，而不只是那些经理或者推动变更的关键人物。我们每个人都要积极地改善自己的工作环境——这不只是管理层才需要关注的问题。从个人角度来说，我们都可以极大地提高自己的生产率。只有每个人都积极地参与进来，才能对团队整体效能的提高起到最大的推动作用。
本书的“领导力”是指，能够与他人一起合作以最有效地实现一个共同目标。如果团队中的每个成员都是高效的“领导者”，那么就能够创造出奇迹。我们每个人都需要有主动意识，努力将这些奇迹转化为团队的生产率。
本书中的许多讨论主题并非仅限于软件开发团队，也可以应用于其他团队。事实上，在这里讨论的许多原则和方法在软件开发之外的许多领域中都是普遍适用的。不过，本书的主要内容还是基于我在软件开发团队中的工作经验，以及一些不同于其他领域的因素：
由于软件通常被视为抽象的和无形的，因此对于软件开发的成果或者范围很少会有共同的理解。
由于在软件开发的培训中主要侧重于技术方面，因此很少会明确地注重对个人态度或者团队动力的管理。
由于这些因素，团队往往在项目中遇到各种问题，有时甚至是彻底失败。
即使这样，团队的可持续性仍然很少被认为是项目成功的关键因素之一。
因此，从某种意义上来说，本书的内容是针对于软件开发领域的。软件开发领域中存在的问题要远远多于我所知道的任何其他领域。虽然我们一直在讨论着最优方法，但却很少成功地应用它们。我们通常会倾向于借助某个技术方案来解决问题，而这将可能给团队带来进一步的制约。我认为一定存在某种更好的方式。
现在开始行动
事实上，永远都不会存在“银弹”这种神奇的解决方案来解决我们的问题。一方面，Fred Brooks在1986年指出在软件开发中不存在“银弹”，另一方面，许多对“银弹”的反复探索最终都成为泡影。我们不能指望某个英雄来拯救世界，而要依靠我们自己通过积极的方式来尽可能地改善软件开发过程。
有些人认为自己属于这个问题解决方案的一部分。在我与这些人合作之后，我得出的结论是，所有这些人都在一定程度上遇到了类似的问题。大多数软件开发顾问在向客户提供咨询和帮助时都遇到了许多相同的问题。我们都局限在自己的认知范围之中，而无法看到这个范围之外的东西。
那么，如果没有“银弹”、没有英雄，并且我们都局限在自己的认知范围之中，我们该怎么办？解决方案是通过协调团队的整体努力来改进我们的工作。我们每个人都要在解决方案中作出自己的贡献，所有这些贡献都是为了谋求一个共同的利益。
我们必须亲自推动变更。我们不能将问题归咎于外部环境，也不能将软件产业的相对年轻作为一个借口。虽然医药行业曾经被称为最年轻的科学，在这个行业中有着庞大的信息量以及较高的变动率，但从业者从不将这些问题作为失败的借口。在软件行业中，我们同样有许多东西需要学习，并且经历着较高的变动率，但我们在应对这些问题时却没有采取积极主动的态度。
我们一直以来在寻求的解决方案其实就是我们自己。我们自己应该负有责任使软件开发工作更为高效。我们必须从现在开始。
我们每个人都可以作出一些贡献，即使这些贡献仅仅是从一个不同的角度来看待问题。那些运转良好的团队总是能够通过融合所有成员的努力来形成一个强有力的整体。
变更的推动需要逐步进行。虽然朝着一个总体背景或者战略目标努力是不错的做法，但在大多数软件开发团队中的问题都是极端的和根本性的，有时甚至只需一些小小的调整可以带来重大的效果。我曾见过许多的组织只是进行一到两次有效的调整就彻底扭转了困境。
然而，大规模变更所带来的文化冲击往往要大于它所带来的正面利益。有些公司之所以没有支撑到今天，至少有一部分原因是由于某个大规模的改进措施所带来的负面影响。
本书并不会告诉你某种固定的方法，而是包含了许多值得借鉴的方法，这些方法可能是适用范围过窄而无法得到广泛的应用，也可能是适用范围过宽而无法很容易地应用于某个具体的情况。
你同样不会在本书中找到某个预定的解决方案或者检查列表。你最好结合自己的具体问题对这些方法进行调整，即使它们是来自于软件领域中的一些优秀著作。
本书研究的内容包括一些我们需要考虑的问题，处理这些问题的合理顺序，以及在每个阶段的建议。虽然本书给出了所有需要考虑的要点，但却并不会给出某个固定的答案。
本书的目的是为了使团队成员能够理解并接受变更。团队中的变更应该是小规模的、有重点的、并且考虑到对现有文化的影响。
内容简介
本书共分为六个主要部分。
第一部分重点说明软件行业的当前状况。虽然我们都在努力改进软件开发工作，但与30年前相比，并没有取得明显的好转。我们分别从历史信息和现实数据等方面来探讨问题，此外我认为软件开发工作中的一系列阶段能够产生强大的整体解决方案。
我们在第二部分将开始讨论这些阶段，阐述每个人对所遇到的情况有着怎样不同的看法，以及由于过去的看法和经验所形成的独特观点和情绪。所有这些因素都是需要重点考虑的，并且应该通过某种客观方式来慎重处理。
在工作场所或其他的地方，团队成员之间的互动将起着主导作用。它将极大地影响团队中的关系以及团队工作的质量。正如在第二部分探讨了“个人”方面的因素，我们在第三部分将讨论与“群体”动力相关的因素。
第四部分将讨论在团队形成过程中出现的问题。这一部分的核心问题是关于如何有效地组织，协调和引导团队朝着共同的目标前进。
在团队能够处理好协调问题之后，就可以在第五部分中分析利益相关者方面的问题。在这一部分，最大的挑战在于共同的沟通以及对变更的管理，这对于成功地解决问题来说是非常关键的。
最后，第六部分讨论与引入变更有关的问题。无论以何种方式引入变更都是困难的，而要在推动全面变更的同时，注意最大限度地减少负面影响则更为困难。在这一部分中将给出在组织中推动变更时可以使用的一些指导原则。
虽然本书的内容组织是逻辑有序的，但你也可以独立阅读每一部分。每章的内容都是完备的，以循序渐进的方式从问题提出一直到获得解决方案。在页边的图标表示问题的表现形式、成功指标、提出的问题以及所使用的工具，这些图标的含义在图标说明中进行了解释。
本书的图标说明给出了这些参考信息，并且为从第二部分到第五部分的内容提供了导航。
来源
本书的大多数主题来自我10余年的咨询经验，以及我在20年之前的软件开发经验。一个问题出现时，我们努力分析问题的本质，找出一种方法来解决这个问题。我曾经在嵌入式系统、空中交通管制系统以及套装软件等领域中工作过，并且为许多公司的不同部门提供过咨询服务。虽然任何一个部门在培育可持续的团队中都会遇到各种各样的问题，但大都会取得成功的启示。
在过去5年中，我在每周通讯中发布了许多这方面的资料。最初，每周要发布一次通讯的任务似乎比较困难。然而这么多年来，我却总是能够发现一些可写的新内容。在今天的软件开发团队中，最不缺乏的就是需要面对的挑战。许多人认为，如果在开发过程中没有遇到任何挑战，要么是自欺欺人，要么是正在欺骗其他人。
在本书中所讨论的问题发生在各个阶段的团队中，包括早期阶段的创业团队（以及一些还没有启动的团队，他们甚至没有意识到他们正试图通过软件来解决问题），以及那些庞大的、成熟的、开发高安全性应用软件的团队。
在本书中讨论的大多数团队只是略微了解软件开发框架和成熟度模型，而其他团队则被评估为处于高成熟度水平。有些团队通过使用框架获得成功，并且丰富了最优方法的内容。
本书的内容并不是要替换现有的方法以解决软件业中面临的挑战，而更应该是一种辅助手段。我们需要通过互动来建立新的体系，而要实现这一点，就需要在一个能够充分发挥创造力的环境中工作。在某种程度上，本书的内容能够使你更有效地使用一些工程上的解决方案。
本书记述了一些真实的情况和过去发生的事情，我故意没有调整这些内容。有的读者可能会从字里行间中发现自己的影子；我希望这种发现会起到积极的作用。
致谢
正如许多耗费数年的工作一样，许多人都为本书做出了很大的贡献。
Geoff Flamank、Patrick Conroy、Robert Goatham以及许多其他人，多年来都是我的良师益友，我们经常在一起讨论软件行业的现状以及如何解决问题。
感谢我们变更协调小组的David Forrest, Sharon Habib, Marina Ma和Simon Mok。你们使我明白了在软件团队中所面临的问题都是一些具有普遍性的问题。
Steve Tockey邀我参与AddisonWesley的评审工作，第一本评审的书就是他所撰写的《Return on Software》。Karl Wiegers多年来为我提供了巨大的支持和指导，把我引见给AddisonWesley。Steve和Karl都对本书的草案提供了详细并且富有建设性的反馈意见。
本书所包含的东西远远不止125 000个单词，其中最重要的是技术评审人员的重要反馈意见。感谢本书的技术评审人员：Matt Heusser提供了许多深层次的反馈，这反过来又引出了一些讨论和思考; Ethan Roberts、Dmitri Zimine和Karl Wiegers同样提供了重要的反馈意见。
感谢Personal Strengths Publishing 公司的Tim Scudder，他使我能够透彻地理解Elias H. Porter的工作以及他的Relationship Awareness理论。
再次感谢Chris Guzikowski、Kim Boedigheimer、Chris Zahn以及AddisonWesley的其余工作人员，感谢他们的所有建议和支持，使得本书的写作过程对我来说是一次愉快的体验，让我感受到了许多令人振奋的时刻。
感谢读者容忍我在每周通讯中的一些夸张言辞。我敢肯定，虽然这些通讯有时候看上去是不一致的，但我希望你能够从中发现一些有价值的信息。
感谢我在这些年以来所看到的一些团队运作失败的情况。那些最痛苦的经历往往是我们最好的学习机会。虽然并非所有的团队都是失败的，但这些失败的情况足以使我们看清楚在这个行业中所面临的挑战。
感谢我的孩子Lauren和Owen，感谢你们能够理解我以家为办公室的做法，至少大部分时间是这样。我在推出一些想法之前，首先在你们身上做一些尝试，虽然这是非常有趣的，但我还是得为此而道歉。
最要感谢的是我的妻子Winney ，感谢她帮我审查文稿，去掉了其中的许多语法问题，并且确认书中的主题确实都是有意义的。特别感谢Winney在我沉浸于本书的写作中承担起家中的大小事务，以及在我创建自己事业时给我的坚定支持。没有别人会像你那样在过去5年中如此坚定地支持我。
这本书是为你而写的。
关于作者
Jim Brosseau自1980年以来一直在软件行业中工作，从事的工作包括测试人员、开发人员、项目经理以及讲师。他在嵌入式电子设备、ATC系统和商业软件包等领域有着丰富的开发经验和管理经验。在他的职业生涯中，始终致力于在团队之间实现更有效的合作。Jim是Clarrus Consulting Group公司的负责人，并且自1998年以来，他已经为世界各地的不同组织提供了咨询服务，帮助他们改进交付软件的方法。他出版了Clarrus Compendium每周通讯，从一个独特的角度看待软件行业（ www.clarrus.com / resources.htm ）。他发表了大量的技术文章，并且参加过许多重要的会议和地方行业协会。Jim与他的妻子和两个孩子生活在温哥华。

如果希望在软件团队中推动一些行之有效的变更或者施以更大的影响力，那么有两种选择：一种选择是自行对各种技术进行实验，在黑暗中摸索几年；另一种选择就是购买本书，阅读并且应用书中所给出的技术。当然，究竟如何选择，决定权在于你自己。 ——Matthew Heusser Jim Brosseau对于IT工作环境中各种驱动因素的真知灼见在本书中得到了充分的体现。对于提供IT解决方案的开发人员和管理人员来说，他在书中给出的见解不仅能促进项目朝着更好的方向发展，而且能使工作本身也变得更为轻松。 ——Bruce A. Stewart，Accendor Research公司CEO 本书是一本令人信服的、全面创新的以及切实可行的指导著作，它能够有效地改善在构建优秀软件中的一个重要方面——人力因素。 通过与众多团队的多年合作，Jim Brosseau在书中阐述了如何通过小规模的、立竿见影的变更，来逐步推动大型的改进工作。这些变更针对团队整体来设计，充分考虑现有的组织文化。此外，Jim Brosseau还提供了每个人都可以立即付诸实施的方案，而无需等待管理层来推动。 无论采用何种方法、技术或者组织结构，通过阅读本书，你都能够掌握如何将各种解决方案应用于实际的开发环境中，这些实际问题往往涉及错综复杂的利益相关者。Jim Brosseau还与读者共同分享了在面对项目管理软件方面的问题时，人们的态度、动机和人际关系方面重要的新观点。 本书是一本启示录——对于每个项目团队成员、领导者以及利益相关者来说，它是您工作中的一份宝贵的参考资源。

Jim Brosseau：Jim Brosseau: 自1980年以来一直在软件行业中工作，从事过测试、开发，担任过项目经理以及讲师。他在嵌入式电子设备、ATC系统和商业软件包等领域有着丰富的开发经验和管理经验。Jim是Clarrus Consulting Group公司的负责人，自1998年以来，为世界各地的众多组织提供咨询服务，帮助他们改进交付软件的方法。他在Cutter IT Journal杂志上发表了多篇文章并且担当顾问，出席过许多重要的会议并参与地方行业协会。Jim与他的妻子和两个孩子生活在温哥华。

聂雪军：2002年起从事软件开发工作，主要开发语言为C++，具有较丰富的Windows和Linux开发经验。译作有《C++编程风格》、《Exceptional C++中文版》等。

软件开发中的个人英雄主义已逐渐成为历史，取而代之的是团队合作形式。然而，由个人过渡到团队并非简单的1+1=2问题。随着团队规模的增加，所面对的挑战将呈非线性增长。如何提高软件开发团队的生产率，这是目前困扰着大多数软件公司和开发人员的主要问题之一。人们通常倾向于从技术层面上来解决这个问题，例如引入某种新的语言或者框架，却似乎达不到预想中的效果。即使采用了一些标准的开发管理流程，例如CMM，通常也只是做一些表面上的工作，而没有深入理解这些流程的本质内容，因此，往往流于形式。开发人员仍然要忍受着加班，返工以及无休止的编码-修改过程，而公司的管理层也不得不面对庞大的开发成本和居高不下的人员流失率。
　　这些问题的根源在于忽视了团队开发中的人力因素。与传统的制造行业相比，软件行业有其特殊性。传统制造业中的生产要素包括生产设备、原材料等，这些生产要素的一个共同点在于它们之间的差异很小，可以通过标准的流水线方式来提高生产率。然而，我们不能将软件开发工作等同于流水线。软件行业中的生产要素为开发人员，他们作为社会中的独立体，每个人都有自己独特的个性（情绪、需求和关注等），我们要理解和尊重这种差异。高效的软件开发团队并不只是包含一些标准的管理流程，更重要的是精心培育团队中的人力因素。
本书的作者在软件行业中工作了近30年，具有丰富的开发经验和管理经验，他目前的主要研究方向是如何在团队之间实现更高效的合作。本书的内容从个人、团队和利益相关者等三个方面进行组织，讨论主题包括个人、质量、责任、主动性、可持续性、沟通、动机与期望、合作、一致性、组织、协调、指导、客户、目标设定、规范、优先级、变更等，基本上涵盖了构建高效团队合作的各个方面。
掌握一项技术可能需要几个月或者一年的时间，而培育一个成功的团队则需要更长的时间，并且要持之以恒，不能松懈。团队合作需要很长时间的相互磨合才可以形成，而不是可以一蹴而就的。希望本书能够对读者在构建软件团队的过程中有所帮助。
参与本书翻译工作的还有李杨、吴汉平、徐光景、童胜汉、陈军、胡凯、刘红、张玮、陈红、李斌、李勇涛、王海涛、周云波、彭敏才和张世锋等。由于译者的时间和水平有限，翻译中的疏漏和错误在所难免，还望读者和同行不吝指正。
致谢
感谢机械工业出版社华章分社的陈冀康先生为我们提供了这次翻译机会，与陈冀康先生的合作总是很愉快的。感谢我的妻子云兰和女儿彤彤在工作中对我的支持和理解，感谢我的父母在生活上给予的帮助，感谢你们一如既往地支持着我。聂雪军
2008年9月于武汉

译者序
图标说明
前言


第一部分问题空间
第1章我们面临的巨大挑战
11困难
12缺乏远见的解决方案
13人力因素的脆弱性
14最优方法的真相
15小结
第2章做正确的事
21正确地做事与做正确的事
22做事的方式
23我们需要掌控成功
24解决方案框架
25小结
第二部分个人
第3章个人的正确态度
31牛仔和无名英雄
32合理的自我批评
33情绪
34加快进度
35我们都是领导者
36小结
第4章以质量为中心
41质量是一种责任
42输出质量理念
43按照人员、过程、产品的顺序
44小结
第5章面对挑战
51感受痛苦
52应对痛苦
53否定
54忽视
55毅力
56思维定式
57小结
第6章主动性成效
61认识你自己
62赌徒与冒险家
63设计我们的环境
64并行工作
65决策
66坚持到底
67小结
第7章可持续性
71什么才是重要的
72充电
73闻一闻玫瑰的花香
74将内省作为一种商业策略
75生活质量
76小结
第三部分群体
第8章沟通
81表达自己的意见
82舒适的沟通
83全面公开
84信任
85客户满意度
86明确性和共同的理解
87沟通的消极面
88小结
第9章动机与期望
91动机驱动行为
92成为一个激励者
93公开我们的动机
94反思阿喀琉斯之踵
95期望
96管理我们的期望
97没有消息其实就是最坏的消息
98小结
第10章合作愉快
101技术赎金
102游戏
103工作保障
104谣言和暗讽
105尽量减少干扰
106质量圈族谱
107就像在家里一样
108小结
第四部分团队
第11章一致性
111团队保持一致
112团队规模的增长
113与团队保持步调一致
114制订规则
115有意识的团队契约
116包容各种观点
117按比例缩放
118小结
第12章组织
121各得其所
122已定义方法，还是科幻小说
123过程架构
124阅读组合方法说明中的小字内容
125这是一个过程项目吗
126通过优化提升速度
127培训
128当问题出现时
129但是我们不在乎
1210有条理的讨论
1211小结
第13章协调
131清理路障，还是阻塞道路
132开诚布公的管理
133只是一名雇员吗
134检出，检入
135对文档化工作的态度
136不要轻易地将一切都外包
137有人情味的平衡
138保留上下文
139小结
第14章指导
141胡萝卜和大棒
142可控的多样性
143是懒惰还是创造力
144捷径
145过程工效学
146规模并不重要
147持续的一致性
148小结
第五部分利益相关者
第15章客户
151谁是我们的客户
152终端客户的代表
153真实可靠
154掌控期望
155小结
第16章设定目标
161目标和任务
162定义成功
163根据产品的优势调整优先次序
164是否真正重视产品质量
165滑坡
166全局观
167小结
第17章规范
171意外的规范
172规范的锥体特性
173保持领先一步
174到什么程度才是足够的
175小结
第18章优先级
181正确的开端
182在确定优先级之前首先制定计划
183优先级排序
184衡量和确定项目范围的优先级
185拖延带来的成本
186小结
第19章变更
191变动性要求多样性
192偏离预计路线
193通过配置管理来了解我们当时的
思考
194只需再多一点
195小结
第20章进展
201三个关键角色
202一种有条理的方法
203解决难题
204有风险的业务
205关键路径
206文档签字的含义
207知道何时退出
208完成
209小结
第六部分理清思路
第21章挑选目标
211正确的过程
212规则
213解耦项目
214亡羊补牢
215小结
第22章灵活性和严格性
221指导与规定
222检查列表与签字
223真正的设计问题：多样化和趋同
224文档化和公共知识
225避免发展过程中的复杂性
226张贴出来
227小结
第23章回顾进展
231将量化作为一项必要工作
232战术度量和战略度量
233隐性消耗
234不能太大，也不能太小
235小结
第24章回顾变更
241为变更制定计划
242去掉旧方法
243对未来的工作分类
244机会
245采取小的、可量化的步骤
246提高认识
247小结
第25章始终保持警惕
251眼罩
252有哪些伤害
253倒退
254小结
第七部分附录
核心工具