文档介绍：软件开发团队软件开发团队将一群人带到一起,这是开端。让一群人待在一起,这是进步。让一群人一起工作,这是成功。— Lou Holtz , 美国橄榄球教练早在希腊哲学家希波克拉底生活的时代(公元前 400 年),人们就已经开始分析其他人的行为了。理解其他人的行为对于做好软件项目管理的第一步——将人员组成一个有效的软件工程团队——是至关重要的。那么, 我们需要做的就是从技术、教育和经验等角度去寻找“合适的”人员并聘用他们——对吗?遗憾的是, 情况要比这稍微复杂一点。挑选团队成员需要预测不同人员之间的人际关系以及他们与你这个项目经理之间的交流情况。大致说来,作为项目经理,你必须正确地回答下面的问题:“这些人能够一起工作吗? ”、“他们能完成工作吗? ”、“我和他们能够一起工作吗? ”。的确, 在某些项目情况中, 你必须和一些难以交流、甚至是一些你不喜欢或是他不喜欢你的人一起工作。工作就是这样。这些情况我都曾遇到过, 我能够把注意力放在项目上, 克服性格上的差异, 不管什么时候都尽可能地使这些冲突服务于工作而不是阻碍工作, 以此取得成功。采取这种方式很耗费精力, 但是很有效。本章的一个目的是当你有机会从头开始组建一个团队时, 帮助你避免这种状况, 至少是克服当前团队中存在的这些问题。这样就又产生另外一个问题:如果人们在一起工作, 作为一个团队, 他们会很好地工作并且表现出最优秀的能力吗?需要你和你的团队评估的最后一个、也就是第五个问题是: 他们具备所需的技能吗? 在这一章,我们将考察在选择团队成员并组建高效团队时需要的技能与技巧。我曾使用过这里讲述的多种技巧, 这些技巧大都是在软件工程书中找不到的, 因为正如本书开始时所说的那样, 大多数人都认为在软件工程中, 成功主要是技术问题, 不是管理问题。因为你将在制定并执行项目计划的同时组建你的团队, 所以你可能需要在执行计划的过程中再回过头来看一看本章所描述的方法和过程。组建团队的过程有多少个软件项目经理,可能就有多少种组建软件开发团队的方式。所有曾经成功组建团队的软件项目经理都有一套自己的公式, 因为相信历史会重现, 所以他们会一再使用同样的公式。但他们发现事情常常并不是这样。软件项目经理是培养出来的, 技能不是与生俱来的。其他在组建团队中不太成功的软件项目经理常常反思:应该采取其他什么方式, 应该如何去了解潜在的团队成员, 将来如何防止类似的失败。在很多情况中, 这种反思还是不起作用。本章总结的组建团队过程的通用模型如图 3-1 中所示。你们公司现在所做的很多工作可能都已体现在这个图中了, 但其中标号为“管理人格测试”的活动可能是最不常见的条目。本节的剩余内容将对这方面中进行扩展。图 3-1 组建团队过程的通用模型那么它有什么用呢?首先,需要理解如何才能组建适合于工作的软件开发团队。回顾我和同事们在这个领域取得的成功以及遇到的挑战, 我非常赞同在某些研究中得出的、决定了技术项目团队是否适合于工作的五个关键因素( Chen 与 Lin , 2004 ): n 专业知识和经验这是由潜在应聘者带给项目的培训及经验。每个公司都有自己的方案, 用于确定团队完成项目所需的技能水平。一般情况下, 软件项目经理会优先考虑应聘者专业知识和经验因素。在面试时向潜在的团队成员询问一些技术问题细节就可以比较容易地了解应聘者的技能水平了。 n 作为团队成员的经验很多软件项目经理常常忽略这个因素。他们常常只注意了潜在团队成员在技术上的能力, 而没有注意到这个人是真正独立的人, 还是一个“牛仔”——不把自己看做是相互支持的团队中的一分子。这种类型的人在单独工作时效果可能非常好, 但在团队环境中就遇到困难了。评价潜在候选人团队经验的一个方式是让他们描述他们在现在和以前的工作中与其他人的关系是什么样的。作为技术资源, 他们是否在一定程度上帮助了其他技能水平较低的团队成员, 他们是否帮助在组内协调工作, 或者以其他方式提供并且( 或者) 使用基于团队的资源?问问他们是如何解决技术问题的: 他们是尝试一段时间后就寻求其他同事的帮助, 还是不管花多长时间都要独立解决? n 交流技巧多年来, 软件行业都在抱怨软件工程师单调的交流技巧。如果他们对这个问题能足够重视, 那么除了编程水平测试外, 他们也许还会增加一个交流技巧的测试, 看看应聘者是否可以编写条理清楚的句子或是向听众口头解释某些事情。这是很多软件专业人员最大的弱点。为了评估候选人的交流技巧, 可以让他们就目前或以前的工作、或是将要从事的新工作整理一个简短说明( 比如说 5到 10 分钟)。看看他们如果回答问题。也可以换一种方式, 在面试过程中, 让他们在安静的、隔离环境中,用 10到 15 分钟的时间写一篇关于某个主题的短文。他们能够写出条理清楚的句子吗?在遇到压力的时候