如何组织软件开发团队
2008-05-23 06:17
295 查看
google_ad_client = "pub-8800625213955058";
/* 336x280, 创建于 07-11-21 */
google_ad_slot = "0989131976";
google_ad_width = 336;
google_ad_height = 280;
//
如何构建软件开发团队取决于可供选择的人员、项目的需求以及组织的需求。本文阐述了各种团队组织的策略。
有效的软件项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色；可能一个人专门负责项目管理，而另一些人则积极地参与系统的设计与实现。常见的一些项目角色包括：
分析师
策划师
数据库管理员
设计师
操作／支持工程师
程序员
项目经理
项目赞助者
质量保证工程师
需求分析师
主题专家（用户）
测试人员
您是如何组织项目团队的？是采用垂直方案、水平方案还是混合方案？以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括多面手，又包括专家。
一个重要的考虑因素是可供选择的人员的性质。如果大多数人员是多面手，则您往往需要采用垂直方案，同样，如果大多数人员是专家，则采用水平方案。如果您正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑您的项目和组织。本文描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。本次讨论的一个重要含意是您的团队组织和用于管理项目的手段之间应构成默契；任何方法上的失谐都很可能导致项目产生问题。
垂直团队组织
垂直团队由多面手组成。用例分配给了个人或小组，然后由他们从头至尾地实现用例。
优点
以单个用例为基础实现平滑的端到端开发。
开发人员能够掌握更广泛的技能。
缺点
多面手通常是一些要价很高并且很难找到的顾问。
多面手通常不具备快速解决具体问题所需的特定技术专长。
主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
所有多面手水平各不相同。
成功因素
每个成员都按照一套共同的标准与准则工作。
开发人员之间需要进行良好的沟通，以避免公共功能由不同的组来实现。
公共和达成共识的体系结构需要尽早在项目中确立。
水平团队组织
水平团队由专家组成。此类团队同时处理多个用例，每个成员都从事用例中有关其自身的方面。
优点
能高质量地完成项目各个方面（需求、设计等）的工作
一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。
缺点
专家们通常无法意识到其它专业的重要性，导致项目的各方面之间缺乏联系。
“后端”人员所需的信息可能无法由“前端”人员来收集。
由于专家们的优先权、看法和需求互不相同，所以项目管理更为困难。
成功因素
团队成员之间需要有良好的沟通，这样他们才能彼此了解各自的职责。
需要制定专家们必须遵循的工作流程和质量标准，从而提高移交给其他专家的效率。
混合团队组织
混合团队由专家和多面手共同组成。多面手继续操作一个用例的整个开发过程，支持并处理多个使用例中各部分的专家们一起工作。
优点
拥有前两种方案的优点。
外部小组只需要与一小部分专家进行交互。
专家们可集中精力从事他们所擅长的工作。
各个用例的实现都保持一致。
缺点
拥有前两种方案的缺点。
多面手仍然很难找到。
专家们仍然不能认识到其他专家的工作并且无法很好地协作，尽管这应该由多面手来调节。
项目管理仍然很困难。
成功因素
项目团队成员需要良好的沟通。
需要确定公共体系结构。
必须适当地定义公共流程、标准和准则。
项目团队士气是项目成功的一个因素
大部分项目成功的定义说的是项目如何按时完成、是否在预算内以及是否满足用户的需要。但是，在如今要找到好的软件专业人员都非常困难，更不用说留住他们的这种情况下，还需要将项目成功的定义扩展为包括项目团队的士气。可能在努力完成一个软件项目后，不料却因为压榨他们过度而失去了重要的开发人员，这样做可能会符合组织的短期需要，但它对构建一个高效的软件部门的长远利益来说肯定是有害的。衡量项目成功与否的一个重要手段是项目结束后团队的士气。在项目结束之际，项目团队的各个成员是否觉得他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。
参考资料
有关构建成功项目团队的详细信息，请参阅：
Process Patterns -- Building Large-Scale Systems Using Object Technology ，Scott Ambler 著。New York: Cambridge University Press，1998。
The Unified Process Inception Phase，Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books，2000。
The Unified Process Elaboration Phase，Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books, 2000.
Constantine on Peopleware，Larry L. Constantine 著。Englewood Cliffs, NJ: Yourdon Press, 1995.
Peopleware: Productive Projects and Teams, 2nd Edition，Tom Demarco 和 Timothy Lister 合著。Dorset House Publishing，1999。
"Organizational Patterns for Teams," Pattern Languages of Program Design 2, pp. 345-352，Neil B. Harrison 著。Addison-Wesley Publishing Company，1996。
关于作者
Scott W. Ambler 是 Ronin International 的总裁，该公司是一家专门提供面向对象过程指导、体系结构建模和 Enterprise JavaBean (EJB) 开发的咨询企业。 他自己著作或者与其他人合著了几本有关面向对象开发的书籍，包括最近出版的 The Object Primer 2nd Edition，该书详细介绍了本文所概述的主题。可以通过 scott.ambler@ronin-intl.com 和他的网站 www.ambysoft.com 与他联系。
/* 336x280, 创建于 07-11-21 */
google_ad_slot = "0989131976";
google_ad_width = 336;
google_ad_height = 280;
//
如何构建软件开发团队取决于可供选择的人员、项目的需求以及组织的需求。本文阐述了各种团队组织的策略。
有效的软件项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色；可能一个人专门负责项目管理，而另一些人则积极地参与系统的设计与实现。常见的一些项目角色包括：
分析师
策划师
数据库管理员
设计师
操作／支持工程师
程序员
项目经理
项目赞助者
质量保证工程师
需求分析师
主题专家（用户）
测试人员
您是如何组织项目团队的？是采用垂直方案、水平方案还是混合方案？以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括多面手，又包括专家。
一个重要的考虑因素是可供选择的人员的性质。如果大多数人员是多面手，则您往往需要采用垂直方案，同样，如果大多数人员是专家，则采用水平方案。如果您正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑您的项目和组织。本文描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。本次讨论的一个重要含意是您的团队组织和用于管理项目的手段之间应构成默契；任何方法上的失谐都很可能导致项目产生问题。
垂直团队组织
垂直团队由多面手组成。用例分配给了个人或小组，然后由他们从头至尾地实现用例。
优点
以单个用例为基础实现平滑的端到端开发。
开发人员能够掌握更广泛的技能。
缺点
多面手通常是一些要价很高并且很难找到的顾问。
多面手通常不具备快速解决具体问题所需的特定技术专长。
主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
所有多面手水平各不相同。
成功因素
每个成员都按照一套共同的标准与准则工作。
开发人员之间需要进行良好的沟通，以避免公共功能由不同的组来实现。
公共和达成共识的体系结构需要尽早在项目中确立。
水平团队组织
水平团队由专家组成。此类团队同时处理多个用例，每个成员都从事用例中有关其自身的方面。
优点
能高质量地完成项目各个方面（需求、设计等）的工作
一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。
缺点
专家们通常无法意识到其它专业的重要性，导致项目的各方面之间缺乏联系。
“后端”人员所需的信息可能无法由“前端”人员来收集。
由于专家们的优先权、看法和需求互不相同，所以项目管理更为困难。
成功因素
团队成员之间需要有良好的沟通，这样他们才能彼此了解各自的职责。
需要制定专家们必须遵循的工作流程和质量标准，从而提高移交给其他专家的效率。
混合团队组织
混合团队由专家和多面手共同组成。多面手继续操作一个用例的整个开发过程，支持并处理多个使用例中各部分的专家们一起工作。
优点
拥有前两种方案的优点。
外部小组只需要与一小部分专家进行交互。
专家们可集中精力从事他们所擅长的工作。
各个用例的实现都保持一致。
缺点
拥有前两种方案的缺点。
多面手仍然很难找到。
专家们仍然不能认识到其他专家的工作并且无法很好地协作，尽管这应该由多面手来调节。
项目管理仍然很困难。
成功因素
项目团队成员需要良好的沟通。
需要确定公共体系结构。
必须适当地定义公共流程、标准和准则。
项目团队士气是项目成功的一个因素
大部分项目成功的定义说的是项目如何按时完成、是否在预算内以及是否满足用户的需要。但是，在如今要找到好的软件专业人员都非常困难，更不用说留住他们的这种情况下，还需要将项目成功的定义扩展为包括项目团队的士气。可能在努力完成一个软件项目后，不料却因为压榨他们过度而失去了重要的开发人员，这样做可能会符合组织的短期需要，但它对构建一个高效的软件部门的长远利益来说肯定是有害的。衡量项目成功与否的一个重要手段是项目结束后团队的士气。在项目结束之际，项目团队的各个成员是否觉得他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。
参考资料
有关构建成功项目团队的详细信息，请参阅：
Process Patterns -- Building Large-Scale Systems Using Object Technology ，Scott Ambler 著。New York: Cambridge University Press，1998。
The Unified Process Inception Phase，Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books，2000。
The Unified Process Elaboration Phase，Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books, 2000.
Constantine on Peopleware，Larry L. Constantine 著。Englewood Cliffs, NJ: Yourdon Press, 1995.
Peopleware: Productive Projects and Teams, 2nd Edition，Tom Demarco 和 Timothy Lister 合著。Dorset House Publishing，1999。
"Organizational Patterns for Teams," Pattern Languages of Program Design 2, pp. 345-352，Neil B. Harrison 著。Addison-Wesley Publishing Company，1996。
关于作者
Scott W. Ambler 是 Ronin International 的总裁，该公司是一家专门提供面向对象过程指导、体系结构建模和 Enterprise JavaBean (EJB) 开发的咨询企业。 他自己著作或者与其他人合著了几本有关面向对象开发的书籍，包括最近出版的 The Object Primer 2nd Edition，该书详细介绍了本文所概述的主题。可以通过 scott.ambler@ronin-intl.com 和他的网站 www.ambysoft.com 与他联系。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 