读《移山之道》之自问自答

花絮：

移山之道作者不仅仅是一个技术达人，书中旁征博引，让读者“便如一叶小舟于大海巨涛之中，怒浪澎湃之际，小舟自然抛高伏低，何尝用力？若要用力，又哪有力道可用？又从何处用起？”（摘自金庸小说《笑傲江湖》）

1. 君子之过也，如日月之食；过也，人皆见之，改也，人皆仰之。（团队协作需要 充分的信息交流与共享，没有必要遮掩自己的错误）

2. 如果相爱能够轻易推测出结果，谁还需要真心来沟通？（本来是强调团队成员之间需要沟通，但总能让人产生联想）

3. 无责任的旁观者和有重大责任的当局者的看法自然是不一样的。（旁观者清也未必）

4. 君子和而不同，小人同而不和。

。

。

正文：

1、如何做到团队的沟通？

Schneider man将软件开发团队概括为三种类型：传统团队、无我开发团队和主程序员制团队。这三种团队的沟通形式如图1所示(双向箭头表示信息的沟通)。Schneiderman认为，上述三种开发团队结构在沟通方面各有千秋。传统团队只允许必要的人际沟通，比较适合于项目本身就是层次结构的大型开发项目。无我的团队成员沟通十分充分，这种团队被认为适合于研制时间长、开发难度大的项目。而主程序员制团队突出主程序员的领导，属于集中领导形式，主程序员是沟通的核心，能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能。

随着对软件产品可用性(Usability)的重视，用户成为日益受到关注的信息源。Castka和Bamber在总结软件开发的团队策略时指出最好的创意通常来自客户或用户，他们认为Kidd在1994年提出的“人机综合制造”结构(Human And Computer Integrated Manufacturing，HCIM)，正是考虑了与客户沟通的因素实现快速制造范例的团队策略。“人机综合制造”结构如图2所示，这样的结构能够使企业实现组织内部围绕流程形成自然群体，并提供了将企业外部的用户、客户、供货商包含进来的空间。HICM结构强调了这些群体之间的沟通(人员和技术沟通总线)，同时描绘了人员与技术之间的接口。

 

2、 如何协调团队中人的关系？软件工程是一个项目驱动型的，书中提到的多是人怎么样来规划和协作来使项目运作，但是作为运作主体的人之间的关系处理该如何处理？

书中提到的一种方法：充分的授权和信任。所有的成员都应该能够得到充分的授权，有权力在自己的职权范围内按照自己的承诺完成任务，同时也充分信任其他同事能够实现各自的承诺。参与项目的人只有拥有了自己的活动空间才能够“自由”地工作，将大部分精力放在项目上面。

作为项目经理，尤其需要处理好与技术牛人的关系。技术牛人的通病是不服技术不如自己的人，且如果他在公司的资质较深的话那更加是个刺猬。因此在项目管理过程中，要让技术牛人很顺利的服从自己的安排和管理通常是一件比较困难的事情。

如何处理和“技术负责人”之间的关系成为了很多项目经理头疼的事情。

第一，项目经理必须明白，一个项目中有一个技术很强的人是自己的幸运，你要考虑的是如何利用和发挥这么优质的资源，而不是心里不平衡。

第二，项目经理必须摆正自己的心态，管理者本质上是为项目服务和提供支持，而不是高高在上的“经理”，项目经理要从一个帮助技术负责人实现自身价值的角度去开展自己的工作。

第三，每一个人都希望得到肯定，技术强人就更希望得到别人的肯定，项目经理要时刻让他感受到他的价值和项目团队的需要，并不时的给予肯定，如果偶尔在更高级的场合给予肯定，他心里会记住你为他做的。

前面几点都是和技术强人相处时的“锦上添花”，仅仅是如此，你还是无法让他从心里服从你。

第四，必须表现出你在项目中的价值，且这种价值又恰恰是作为技术负责人他无法望及的。例如：商务能力、和客户有效沟通，优秀的计划控制，需求管理（需求、调研、需求变更等），项目协调等。

第五，项目经理在项目管理过程中，应注意从细节入手，细节决定成败，项目管理同样适用。例如：项目计划过程中多听听技术负责人对工作量估算的建议，加强他对项目管理的参与，也无形中保障了计划的可行性。

 

3、 什么样的人适合结对编程？

书中提到，极限编程对实施的程序员提出了更高的要求，这种要求不是技术水平，也不是学历水平或工作经验，这种要求是对一个人心智、道德修养的更高要求。

对于结对编程的双方，一般采用自由组合；但如果两个能力相差太多的开发人员组合在一起，会形成“师徒关系”。可能有各种原因会造成这种关系的产生，但这严重地妨碍了项目的开发进度，不但浪费了能力强的开发人员的宝贵时间，而且使能力差的开发人员发挥不出作用。可以做适当的人员调整。

对于一个开发团队，各小组成员不一定都要结对，对于能力层次高的和入门级的开发人员，最好让他们单独工作。能力高的开发人员，单独负责开发单元，同时可以担任仲裁员，为其他结对小组解决疑难问题；而对于入门级开发人员，也不要让其结对以免影响进度，可以让其做些辅助性工作，并提供各种提高能力的机会。

 

4、 软件测试有很多种方法，应该如何组建测试团队？

软件测试团队的四种类型

（ 1） 融 合型

所 谓融合型软件测试团队是指软件测试人员和软件开发人员融为一体，软件测试 工 作实

际上 就 是由从事该软件开发的人员完成。

适用环境分析 ：

这种类型的测试团队虽 然从 某种角度来看有些优势，但其致命的缺陷是 无法有效 地 保证测试质量。因此，这种类型的测试团队只能作为事业刚刚起步 的小公司（因为 这种类型的公司一方面资金较紧、项目少，另一方面管理也不完善）权宜之计，绝对不能作为长期采用的类型。

（ 2）相对独立型

所谓相对独立型软件测试团队是指软件测试人员和软件开发人员同属于一个部门，但属于不同的小组（即测试人员属于测试小组，开发人员属于开发小组，相对独立），软件测试工作由测试小组完成，软件开发工作由开发小组完成，两小组分工明确。这种测试和开发相对独立的测试团队具有以下一些优缺点。

适用环境分析 ：

这种类型的测试团队虽然存在明显的不足，但在大部分情况下还是能较好地保证测试质量，同时也能好地控制测试成本。因此，这种类型的测试团队适合规模不大的软件企业采用（因为这种类型的测试团队不需要占用公司较大的资金和人力投入）。

（ 3） 完全独立型

所谓完全独立型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门（即测试人员属于测试部门 ，开发人员属于开发部门 ），测试部门的工作质量由公司评价，测试人员的工作质量由测试部门主管评价。具体地说 ，就是测试人员和开发人员属于各自独立的部 门 ，公司对各部门独立考核 ，测试人员的绩效完全由测试主管考核 ，产品是否通过测试需要由测试人员给出明确的结论 。

适用环境分析 ：

这种类型的测试团队能有效地保证测试质量，但容易造成开发人员和测试人员之间的误解和矛盾。这种类型的测试团队比较适合从事产品研发和销售的公司采用（因为这样的公司一般 产品比较单一 、稳定，测试人员不需要向开发人员了解太多的产品 信息）。

（ 4）相 互制约 型

所 谓相互制约型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门（即测试人员属于测试部门 ，开发人员属于开发部门 ），但测试人员和开发人员之间存在互相评价工作质量的关系 。 具体地说 ，就是测试人员和开发人员属于各自独立的部门 ，公司对各部 门独立考核 。测试主管考核测试人员的工作绩效时， 以开发部门认可的有效测试工作量和测试质量作为考核指标之一 ； 开发主管考核开发人员的工作绩效时 ，以测试人员提供的测试缺陷作为考核指标之 一， 并且产品是否通过测试需要由测试人员给出明确的结论。

适用环境分析 ：

这种类型的测试团队虽然存在一定的不足，但能有效地保证测试质量。这样类型的测试团队所占用的测试成本较高 ，因此比较适合具有一定经济实力的大公司采用，特别是以项目运作为主要业务的大公司采用（因为这样的公司很需要测试人员和开发人员密切沟通和配合）

 

5、 书中对软件工程团队组成更倾向于从技术开发的角度，高效（高效率也要高效能）的团队应该是怎样的构成？

开发团队人才选拔和培养是建设高效团队的基础。一个软件项目的完成是由项目经理，系统分析员，设计员，程序员和测试员共同完成的，在这个工程中每个角色的职责是不一样的，因此在人才选拔和培养上的标准不同。

项目经理：对产品有激情，具有领导才能；对问题能正确而迅速地做出决定，能充分利用各种渠道和方法来解决问题，能跟踪任务，有很好的日程观念，能在压力下工作。

系统分析员：善于协调，并且具有良好的沟通技巧，有业务和技术两个领域的知识。

设计员：拥有良好的设计技术与系统观念。

程序员、测试员：良好的编程技能和测试技术

软件工程团队本身就是一个系统，需要各方面人才的协作，团队建设中需要以产品为核心，以团队合作为核心。

 

by: Yue Wu

Oct. 9th,2011

转载于:https://www.cnblogs.com/rosting/archive/2011/10/09/2204156.html