软件开发团队.docx
《软件开发团队.docx》由会员分享，可在线阅读，更多相关《软件开发团队.docx（38页珍藏版）》请在冰点文库上搜索。
软件开发团队
软件开发团队
将一群人带到一起，这是开端。
让一群人待在一起，这是进步。
让一群人一起工作，这是成功。
—LouHoltz，美国橄榄球教练
早在希腊哲学家希波克拉底生活的时代（公元前400年），人们就已经开始分析其他人的行为了。
理解其他人的行为对于做好软件项目管理的第一步——将人员组成一个有效的软件工程团队——是至关重要的。
那么，我们需要做的就是从技术、教育和经验等角度去寻找“合适的”人员并聘用他们——对吗？
遗憾的是，情况要比这稍微复杂一点。
挑选团队成员需要预测不同人员之间的人际关系以及他们与你这个项目经理之间的交流情况。
大致说来，作为项目经理，你必须正确地回答下面的问题：
“这些人能够一起工作吗？
”、“他们能完成工作吗？
”、“我和他们能够一起工作吗？
”。
的确，在某些项目情况中，你必须和一些难以交流、甚至是一些你不喜欢或是他不喜欢你的人一起工作。
工作就是这样。
这些情况我都曾遇到过，我能够把注意力放在项目上，克服性格上的差异，不管什么时候都尽可能地使这些冲突服务于工作而不是阻碍工作，以此取得成功。
采取这种方式很耗费精力，但是很有效。
本章的一个目的是当你有机会从头开始组建一个团队时，帮助你避免这种状况，至少是克服当前团队中存在的这些问题。
这样就又产生另外一个问题：
如果人们在一起工作，作为一个团队，他们会很好地工作并且表现出最优秀的能力吗？
需要你和你的团队评估的最后一个、也就是第五个问题是：
他们具备所需的技能吗？
在这一章，我们将考察在选择团队成员并组建高效团队时需要的技能与技巧。
我曾使用过这里讲述的多种技巧，这些技巧大都是在软件工程书中找不到的，因为正如本书开始时所说的那样，大多数人都认为在软件工程中，成功主要是技术问题，不是管理问题。
因为你将在制定并执行项目计划的同时组建你的团队，所以你可能需要在执行计划的过程中再回过头来看一看本章所描述的方法和过程。
组建团队的过程
有多少个软件项目经理，可能就有多少种组建软件开发团队的方式。
所有曾经成功组建团队的软件项目经理都有一套自己的公式，因为相信历史会重现，所以他们会一再使用同样的公式。
但他们发现事情常常并不是这样。
软件项目经理是培养出来的，技能不是与生俱来的。
其他在组建团队中不太成功的软件项目经理常常反思：
应该采取其他什么方式，应该如何去了解潜在的团队成员，将来如何防止类似的失败。
在很多情况中，这种反思还是不起作用。
本章总结的组建团队过程的通用模型如图3-1中所示。
你们公司现在所做的很多工作可能都已体现在这个图中了，但其中标号为“管理人格测试”的活动可能是最不常见的条目。
本节的剩余内容将对这方面中进行扩展。
图3-1组建团队过程的通用模型
那么它有什么用呢？
首先，需要理解如何才能组建适合于工作的软件开发团队。
回顾我和同事们在这个领域取得的成功以及遇到的挑战，我非常赞同在某些研究中得出的、决定了技术项目团队是否适合于工作的五个关键因素（Chen与Lin，2004）：
n专业知识和经验这是由潜在应聘者带给项目的培训及经验。
每个公司都有自己的方案，用于确定团队完成项目所需的技能水平。
一般情况下，软件项目经理会优先考虑应聘者专业知识和经验因素。
在面试时向潜在的团队成员询问一些技术问题细节就可以比较容易地了解应聘者的技能水平了。
n作为团队成员的经验很多软件项目经理常常忽略这个因素。
他们常常只注意了潜在团队成员在技术上的能力，而没有注意到这个人是真正独立的人，还是一个“牛仔”——不把自己看做是相互支持的团队中的一分子。
这种类型的人在单独工作时效果可能非常好，但在团队环境中就遇到困难了。
评价潜在候选人团队经验的一个方式是让他们描述他们在现在和以前的工作中与其他人的关系是什么样的。
作为技术资源，他们是否在一定程度上帮助了其他技能水平较低的团队成员，他们是否帮助在组内协调工作，或者以其他方式提供并且（或者）使用基于团队的资源？
问问他们是如何解决技术问题的：
他们是尝试一段时间后就寻求其他同事的帮助，还是不管花多长时间都要独立解决？
n交流技巧多年来，软件行业都在抱怨软件工程师单调的交流技巧。
如果他们对这个问题能足够重视，那么除了编程水平测试外，他们也许还会增加一个交流技巧的测试，看看应聘者是否可以编写条理清楚的句子或是向听众口头解释某些事情。
这是很多软件专业人员最大的弱点。
为了评估候选人的交流技巧，可以让他们就目前或以前的工作、或是将要从事的新工作整理一个简短说明（比如说5到10分钟）。
看看他们如果回答问题。
也可以换一种方式，在面试过程中，让他们在安静的、隔离环境中，用10到15分钟的时间写一篇关于某个主题的短文。
他们能够写出条理清楚的句子吗？
在遇到压力的时候他们还能交流吗？
n工作分配的灵活性这关系到潜在的团队成员认为自己只需要关注在聘用时分配的软件开发工作类型，还是在遇到困难时愿意提供帮助，为了团队的成功愿意做任何事情。
这种任务包括调试其他人的代码，清理由某个数据库工具抽取的、包含了只能在抽取之后才能修复缺陷的数据，做一些数据文件内容的统计工作，以及其他在职位描述或是在工作面试时没有包含或提到的任务。
n人格特质这是最难对付的因素。
软件项目经理很少接受那种使他们能够有效处理这类问题的心理学培训。
相反，他们依赖于是否“喜欢”某个人以及团队其他成员对那个人的评价是否正面。
这可能会像其他方案一样，是一个有效的组合，但是不一定能正确使用。
这个因素对于成功组建团队至关重要。
如果团队成员不能融洽地相处，那么软件项目就会遭受损失，这和体育运动中的团队一样。
需要小心：
不要偏好那些想法和你一样并总是赞成你的意见的应聘者。
你的盲点可能会变成团队的盲点，在今后会产生问题。
在上面这个列表中，大多数项目经理都能比较容易地处理前四个因素。
但是，最后一个因素可能会让人担心。
这个问题不仅仅是软件项目经理与各团队成员之间是否能够融洽相处，它还关系到团队成员之间的相处是否融洽。
这就进入了人格特质领域。
人格模型分为几种，还有几组特征来描述这些模型。
在项目团队环境中接受最广泛、研究最深入的模型之一是迈尔斯—布里格斯（MyersBriggs）模型（Myers与Myers，1995）。
这个模型不仅提供了将每个人的人格进行分类的方式，而且还能按照迈尔斯—布里格斯类型指标（MyersBriggsTypeIndicator，MBTI）对一个人与其他人的融洽程度做出评估。
这个人格模型描述了每个人的人格都有四个维度，每个维度都有两个相反的人格偏好，如下所示：
注意力的集中
n外向（Extrovert，E）喜欢与其他人交流。
与团队一起工作时，外向激发了他们的能量。
n内向（Introvert，I）内向的人喜欢独自工作。
与团队一起工作时，能量就减少了。
寻求信息
n领悟（Sensing，S）这种人注重的是事实和数据，他们从细节中得到信息，在文档中常常发现其他人遗漏的小错误。
n直觉（iNtutive，N）这种人是思考者，使用直觉与理论得到“大图片”。
他们常常重点关注文档中的论据是如何陈列的，而不去关注文档中包含的细小错别字。
决策
n思维（Thinking，T）这些人根据原理、法律、规则、逻辑和客观分析进行决策。
n情感（Feeling，F）正如名称所示，这种类型的人强烈地考虑所涉及的人的情感并重点关注在组内维持和谐气氛。
与世界的关系
n判断（Judging，J）这种人注重结果。
他们做出决定的方式非常迅速——他们喜欢事情尽快完成，对于延迟会感到沮丧。
n感知（Perceiving，P）这种人注重过程。
他们的思路通常很开阔，做出决定的速度很慢，并常常考虑新的可能的方法。
回顾前面的内容，可以看到人格特质一共有16种可能的组合。
你可能已经猜到了，这16种组合中不是每一种都能与其他种类融洽相处的。
对于技术项目，不同类型之间的融洽程度见表3-1所示（Chen与Lin，2004）。
注意这里采用的是归一化（mormalized）表示法，意思是最高的可能值是1.0。
融洽程度的值越高，就越融洽，反之亦然。
表3-1人格类型融洽程度
1-
ESTJ
2-
ESTP
3-
ESFJ
4-
ESFP
5-
ENTJ
6-
ENTP
7-
ENFJ
8-
ENFP
9-
ISTJ
10-
ISTP
11
-ISFJ
12-
ISFP
13-
INTJ
14-
INTP
15-
INFJ
16-
INFP
1-
ESTJ
0.67
2-
ESTP
0.33
0.67
3-
ESFJ
0.83
0.50
0.67
4-
ESFP
0.50
0.83
0.33
0.67
5-
ENTJ
0.83
0.50
1.00
0.67
0.67
6-
ENTP
0.50
0.83
0.67
1.00
0.33
0.67
7-
ENFJ
1.00
0.67
0.83
0.50
0.83
0.50
0.67
8-
ENFP
0.67
1.00
0.50
0.83
0.50
0.83
0.33
0.67
9-
ISTJ
0.50
0.17
0.67
0.33
0.67
0.33
0.83
0.50
0.33
10-
ISTP
0.17
0.50
0.33
0.67
0.33
0.67
0.50
0.83
0.00
0.33
11-
ISFJ
0.67
0.33
0.50
0.17
0.83
0.50
0.67
0.33
0.50
0.17
0.33
12-
ISFP
0.33
0.67
0.17
0.50
0.50
0.83
0.33
0.67
0.17
0.50
0.00
0.33
13-
INTJ
0.67
0.33
0.83
0.50
0.50
0.17
0.67
0.33
0.50
0.17
0.67
0.33
0.33
14-
INTP
0.33
0.67
0.50
0.83
0.17
0.50
0.33
0.67
0.17
0.50
0.33
0.67
0.00
0.33
15-
INFJ
0.83
0.50
0.67
0.33
0.67
0.33
0.50
0.17
0.67
0.33
0.50
0.17
0.50
0.17
0.33
16-
INFP
0.50
0.83
0.33
0.67
0.33
0.67
0.17
0.50
0.33
0.67
0.17
0.50
0.17
0.50
0.00
0.33
这个表格提供了一个（但不是唯一的）指标，说明从融洽程度的角度考虑，谁会或谁不会成为潜在的高效团队成员。
为了有效使用这个模型，每个团队成员都应当完成一份MBTI调查问卷，进行评估，并同意你这个项目经理查看结果。
现在很多公司都采用这种或类似的数据图表，作为雇用的一个条件，并在潜在雇员允许的情况下，让他们的经理查看结果。
在选择团队成员时，一个更为重要的因素可能是确定团队中每个成员对其他人习性的容忍程度。
虽然不是MBTI的一部分，但这却关系到团队的感受。
你可能想知道如何处理那种团队骨干不融洽但又无法换人的情况。
我有过管理这种团队的经验。
在大多数情况下，我首先要保证不融洽的团队成员始终以项目的利益为重。
然后，在外面请的心理学咨询师的帮助下，查明了每个人做的什么事情在无意中令其他人感到不快。
这种方法收到了效果，而且如果当初导致问题发生的行为再次出现时，我就能够识别出来了。
只要稍微提醒一下，事情就又可以平稳地进行了。
如果你发现自己面临类似的情况，可以寻求专家对你和团队进行帮助。
进行面试
将团队组织在一起是成功的关键，需要一些精心设计的工作。
不论是从公司外部聘用还是从公司内部选拔人员，你最后都需要进行一些面试。
需要记住的是，谁也不喜欢进行面试，而且在面试过程中通常会感到紧张。
潜在的雇员因为希望被雇用，所以感到紧张。
对别人做出评价总是一件不容易的事情，并且项目经理在进行面试的时候手头可能还有大量的工作没有完成，所以项目经理也会感到紧张。
你所能做的是尽快、尽量有效地完成面试过程。
首先，让我们看一些由美国联邦政府和各州以及很多其他工业化国家的判例法和现行劳动法所设定的基本原则。
请注意本节并未包含这些内容的完整列表，而是集中关注你这个经理在面试过程中最可能犯的、潜在地会让你付出代价的错误。
我曾亲眼看到或是听别人说到在面试中的一些问题和行为导致了公司被起诉。
为了确保你熟悉在目前面试过程中的规则，了解（按照法律制度）哪些问题能问、哪些问题不能问，可以向你们的人力资源部门咨询。
如果你们的公司不大，没有这样的资源，可以找一本最新的劳动法参考书，向劳动法律师咨询，或是打电话到当地的劳动部门询问、获得有关这个主题合适的出版物。
在美国，你应当联系你们公司所在地的平等工作机会（EqualEmploymentOpportunity，EEO）办公室。
在现今法律中，你不能向潜在员工、现有员工或是准备调入你们组的员工询问某些主题的问题，包括：
n这个人的宗教、政治倾向、原来的国籍或信仰
n这个人的婚姻状态、性取向，现在或以前的两性关系
n这个人的年龄
你能问的问题也很多，其中有一些是法律要求的，包括以下：
n对于新聘用的人，你可以问他们是否获准在美国（或是向他们提供的职位所在的国家）工作，并要求他们提供证明材料来支持他们的回答。
对于已经聘用的员工，假定你或你们人力资源部门已经验证过这一点了。
n重点考察他们对于你们组正在开发的系统的经验、他们使用过的开发支持软件、他们承担各种角色的年限等等。
记住，你是在根据他们以往的经验评估他们是否能够胜任这份工作。
n询问他们是否适应这种面试形式——例如，有些人在一个小房间里有多个面试人的时候会有一些幽闭的感觉，他们可能喜欢大一点的房间。
n询问他们是否需要一些特殊种类的、能够带来方便的设施——例如，某个听觉不好的人可能需要扩音器系统。
介绍如何进行面试的文章和教科书已经很多了，这里不再重复。
实际上，你们公司可能已经有一套在面试过程中必须遵守的标准化过程了。
如果你们公司对于某个职位的所有应聘者还没有一套标准化的流程，需要尽快制定，以免那些参加了面试而没有被录用的人认为录用过程不公平、对他们有歧视而提起诉讼。
我使用过的面试和选择潜在软件工程师最有效的方法是根据我们的需要聘用C/C++编程专业人员。
那时，我们无法找到足够多的、合格的人来填补空缺职位，这损害了我们对客户的承诺以及我们已经同意了的、有些过于自信的进度表。
我们的竞争对手似乎已经聘用了我们的一些最好的人，他们提供的丰厚薪金是我们做不到的。
我发现任何一个能购买并阅读一本C/C++编程教科书的人都声称自己是C/C++高级软件开发技术人员。
我和我们的高级软件工程师提出了一个方案，将技术能力强的应聘者和那些不合格的人区别开。
这个方法即使在今天的劳动力市场也依然证明是有效的：
我让一位高级软件工程师起草了一份编程测试题，形式为代码段，使用的是应聘者将要使用的编程语言。
每个代码段前面都有一段解释，说明代码本来要执行什么内容，实际上执行了什么内容。
应聘者需要解释代码为什么不能正确执行，并提供修改方案，使代码能够按照预想的方式执行。
我们重点考察每个职位的应聘者解决问题的方法，让应聘者说出他们的观察结果以及他们跟踪软件错误原因所使用的方法。
这种代码段很容易从各种包含编码谜题和代码示例及反面示例的网站中找到。
我们知道应聘者在面试过程中会感到紧张，所以我和我们的高级软件工程师观察的是他们打算如何解决问题。
考虑到在这种环境中，他们的表现可能不是最好，所以我们感兴趣的是他们解决问题的方式，而不是他们是否能够成功解决问题。
在一次团队开发项目中，我们让两个表现截然相反的人进行了相同的测试。
一个人因为不习惯使用英语而显得相当紧张，在分配的30分钟时间内只解决了3个问题，而另外一个人在不到10分钟的时间内解决了所有10个问题。
我们把这两个人都录用了，他们都成为了出色的员工。
再次说明，关键的选择标准是重点考察应聘者解决问题的方法，而不是看他们能否得到正确解答。
团队的其他人将要和应聘者一起工作，所以在录用过程中，应当让他们与应聘者做一些交流。
让团队的其他人与应聘者单独会面，并向你反馈他们是否愿意与应聘者一起工作。
在这里，了解当前团队是非常重要的，因为每个人对于评估别人的工作、他们的人际关系技巧等都有自己特点。
让团队成员与应聘者进行交流，因此成为甄选过程的一部分，这样如果选择了这个应聘者，也有助于确保团队能够接受他。
选择的应聘者变成了团队的选择，而不仅仅是经理的选择。
下面是几条应当由其他团队成员遵守的规则。
（你们公司可能已经有一套定型的面试流程来处理这些问题了。
）
n事先准备好问题，并与其他面试人准备提问的问题进行比较。
不同面试人可以问相同的问题。
n与其他面试人的反应进行比较。
n让每天都将与这个应聘者一起工作的人单独面试他，面试的时间相同——例如，20到30分钟。
n如果可能的话，安排整个组与应聘者共进午餐或进行某种交际活动，以便观察他们在交往时是如何进行交流的。
记住，通过面试希望得到的是下面这些问题的答案，包括：
n这个人能胜任工作吗？
n这个人与潜在的团队能够融洽相处吗？
n这个人是否具备足够的人际关系技巧来应对其他组（例如，质量保证组和测试组）以及潜在的客户？
n这个人确实具备他在简历和求职申请上描述的经验和工作记录吗？
（人力资源部或公司外的人可以验证工作历史。
）
某些大公司的人力资源部拟定了由所有经理在招聘专业人员时使用的面试流程。
如果你在这样的一个公司中工作，那么可能无法使用上面介绍的流程。
在任何情况下都要记住，如果你拒绝录用某人，而他认为你和／或你的同事对他有歧视，你和你的团队可能需要提交文件，说明你们是如何在法律的框架内达成你们的录入决定的。
这个支持文件可能包含对一个或多个应聘者的评价、观察和讨论。
对应聘职位的人始终都要保持一致的态度，并将每件事都清晰、一致、简明地记录下来。
如果你确实想知道这个人管理起来以及一起共事时是什么样子的，可以让他们填写一份类似于下页中图3-2所示的调查问卷。
你应当对这份问卷进行裁剪，使它适合于你们的组织，并且在其他人完成之前自己先试着填写一下。
这份调查问卷的主旨是探索融洽性的问题。
例如，如果你支持在项目关键点进行走查的看法，而调查问卷表明这个人对此对没有太多想法，那么这可以作为录用时考虑的一个因素。
另外，让一个职位的应聘者在面试那天的一开始、在进行面试之前就填写这样的调查问卷，可以帮助每个人重点考察一些在调查问卷中反映出来的问题。
与经理以及（或者）其他同事不融洽可能会成为严重问题。
在一个由我担任项目经理的外包项目中，团队成员不到10个人。
大多数人都没有什么经验，但其中有两个是资深人士，具备将项目组织在一起所需要的经验。
在制定计划、收集需求和定义阶段时，一切进展都很顺利。
在设计开始后，任务是分配或自愿认领的。
作为开发设计过程的一部分，每个软件工程师都要求走查他自己那部分设计。
走查原则是在项目计划阶段就制定好的，其中包含一条：
在走查时，一个人作为走查负责人，另外一个人作为记录员。
记录员的工作是记录行动事项。
行动事项指的是在约定的交付日期进行交付的交付物（交付物通常有更正）。
走查负责人的工作是确保大家都不会超出常规的、1小时的会议时间，并且防止人们在讨论时跑题，以及诸如此类的工作。
这两个骨干开发人员中的一个人完全不能容忍别人对他的工作提出批评。
即使是明显的错误点，他也总是为自己辩护。
更糟糕的是，当他担任走查负责人的时候，总是过于吹毛求疵，评论生硬而粗暴，偶尔还很粗鲁。
即使我们向他说明这些行为会影响项目的进展，他也是坚持不改。
当初调他到这个项目组的原因是他是组织内具有经验、又能够调动的为数不多的几个人之一。
现在知道原来的项目组为什么肯放他走了，后来我们达成一致意见，那个人又调到了其他组。
我想说的是，如果能做一套类似图3-2所示的“工作环境偏好情况调查表”中所包含的那些偏好清单，那么问题本来是可以避免的。
应当在下面这个偏好清单的基础上制定你们自己的文件。
修改后的清单应该进行裁剪，以适应你们组织构造的系统类型、你的偏好、组内其他人的偏好以及公司政策等等。
工作环境偏好情况调查表
应聘者姓名日期
使用如下所示的尺度，对每条陈述内容输入一个1-5的整数。
这个调查表的目的是评估你和这个组织相互之间的融洽程度。
强烈反对反对不同意也不反对同意完全同意
1-------------------2--------------------3--------------------4--------------------5
我喜欢独立工作。
如果我不同意某个同事的意见，并且知道自己在技术上正确的，我通常都会坚持立场、不会让步，直到我说服他，让他相信我是正确的。
我喜欢那种体系和规则很少但是仍旧能做好工作的方式。
我发现编码标准、标准过程、审核以及类似的东西会起到阻碍作用，影响我完成工作。
我认为通过在代码中添加注释，能够使得其他熟悉这个语言但是不熟悉这个应用程序的人快速有效地对代码进行维护。
假如有两种情况，一种是必须遵守组织内的过程进行工作，另一种是只要完成工作就可以了，我更喜欢只要完成即可的方式，如果有时间再去填写所需的过程。
我相信获得一个高效开发团队的最佳方式是在所有重大问题上都保持一致意见。
我喜欢首先完成软件相关问题中最困难的部分。
即使时间很紧张或是进度表截止日期已经临近，我也常常为我们团队的其他成员提供帮助。
如果需求没有变化但是工作的预算增加了，我将把更多的工作量放到分析和设计阶段。
如果我在一个编程问题上花费的时间超过10分钟而没有进展，我常常会寻求同事的帮助来解决它。
我编写的代码在我离开公司后会很容易修改，负责那些代码的人一般不需要再联系我，问我代码是怎么回事。
我觉得代码中过多的注释是没有必要的，毕竟，如果某个人很好地掌握了编程语言，他会看出这些代码的用途。
如果在编写高效代码与简单代码之间做出选择，我选择效率。
表3-2工作环境偏好情况调查表
检查求职材料
有一个忠告，总是应当让你们的人力资源部门或外面请的公司验证应聘者的求职材料和工作历史。
他们比你做的工作更加一致，他们会遵守法律，因此保护你和你们公司不会受到潜在的责任起诉，而且他们接受过训练，能够正确记录和解释所得到回答。
法律不容忽视。
例如，因为雇主对他们从前的雇员“说坏话”，导致了一些法律上的诉讼。
在那些例子中，法院认定诉讼所涉及的人受到了前雇主负面评价的伤害，应该得到金钱补偿。
如果有人打电话向你了解前雇员的情况，可以让打电话的人去找你们的人
升级会员 