以角色为基础的软件开发团队建设

0 评论 2763 浏览 2 收藏 23 分钟

软件开发管理的重要任务之一就是团队的组建。本文提出了一种以角色为基础的团队建设方法,以有效提高团队建设能力。在软件开发过程中,对开发和管理活动进行分解会产生一系列的子活动,对子活动及其相关知识的抽象产生角色——问题角色;对人的分析和抽象也产生角色——人员角色。

在软件开发过程中,对开发和管理活动进行分解会产生一系列的子活动,对子活动及其相关知识的抽象产生角色——问题角色;对人的分析和抽象也产生角色——人员角色。

问题角色与人员角色的有效关联也就是团队的组建,问题角色与人员角色的再定义和改进也就是团队的建设。以角色为基础来进行软件开发团队的组织,能够比较全面地解决项目管理问题,而且团队建设很容易达到可持续改进的目的。

角色抽象作为一种载体,可以很好地进行软件工程知识体系和企业知识地图的组织,满足企业知识体系持续改进的需要,因此角色团队组建和建设也可以作为软件工程实施方法之一。

软件开发项目立项时,重要工作之一就是开发团队的组建;在软件工程实施(把软件工程研究结果产生的标准或规范如ISO、RUP、MSF、XP具体应用到软件开发活动的程称为软件工程实施)的过程中,要解决的问题之一就是关于团队组建规则的定义;从企业发展的角度来看,软件开发团队建设是企业建设的重要任务。总之,软件开发团队的组建和建设是企业经营和发展的重要内容之一。

几乎所有的管理知识体系或规范都涉及到个体和团队建设问题,比如组织行为学[Stephen P.Robbins,1997]对个体和团队的行为进行了研究;项目管理[PMI,2000]中的计划、人力资源管理、项目集成管理、项目沟通管理等多个项目管理领域都涉及到团队建设和管理;在软件能力成熟度模型(CMM)[SEI,2000]的发展过程中,从个体软件过程和团队软件过程来研究软件的开发和管理。对个体和团队管理的研究是管理学的核心任务,涉及到的知识和学科纷繁、复杂。

然而,在管理的具体实施过程中,客观上管理环境的不同及主观上管理者的偏好,一般会在理论或规范基础上进行简化、删减、方向取向、分类归纳等工作,最后表现为各自独立的制度、规则、知识、评估方法、认证等多种独立体系,失去了其内在的联系,管理工作仍然复杂,而且不利于改进。

瑞理统一过程(RUP)[Rational,2001]通过对工作流分解的方式进行了软件开发过程及活动的分解和定义,并以角色为中心来进行知识、活动、规则、工具等的关联组织,从而把软件开发活动一体化、层次化、结构化,并保持其内在的有机联系,为个体和团队软件开发活动提供了很好的指导。

本文以“角色”这一概念为基础,提出了“以角色为基础的软件开发团队建设”的观点,阐述了其原理和方法,并对其优、缺点进行了分析,简要说明了该方法对“软件工程过程改进”的支持。

为简化叙述,文中“以角色为基础的软件开发团队”简称为“角色团队”,对应地,其它一般团队简称为“一般团队”;许多地方把文档、资源、信息、规则等统称为“知识体系”。

一、角色的含义

根据RUP[Rational,2001]的定义(如 “图 1 RUP中角色的含义”所示),角色的含义是:角色是抽象的职责定义,它定义的是所执行的一组活动和所拥有的一组资源。角色通常由一个人或作为团队相互协作的多个人来实现。

图 1 RUP中角色的含义

角色定义是一种管理上的要求,是“以活动为基础的管理”的表现形式,角色定义的依据是:问题、人、管理都可以分析为一系列活动的组合,这些活动有输入、输出,需要一定的环境和工具,需要活动承担者具有一定的能力,所有这些要素都是可以定义的,其联系的核心可以称为“角色”;管理本身的任务包括对问题域的角色分解、对人的角色分解、问题角色与人员角色的配对等。

因此,我们可以定义通用的角色模型如“图 2 通用角色模型”所示。

图 2 通用角色模型

通用角色模型的含义:

  • 角色是活动的承担者,角色与所需要的知识、工具、环境、输入、输出相关,是分析和定义结果的抽象,是一个容器;
  • 角色是构成知识体系的基本粒子,角色粒度大小和层次构成根据企业对角色团队掌握的成熟度灵活控制。

问题角色容纳了对问题域的认识和分析结果,人员角色满足预定义的能力和人格要求,并在掌握了相关知识和工具后获得认证;问题角色和人员角色关联后,人员角色利用知识、工具、输入文档等进行创造性活动,解决问题角色的需求;关联活动产生的结果经过总结、分析,进行经验总结反馈,从而可以改进问题角色和人员角色的定义和认证,为组织进步提供通道。

二、角色团队组建原理

在软件开发实践中涉及到的问题、人、管理都具有一个共同特点:复杂,人类解决复杂问题的方法离不开“分解”,分解结果被定义为一系列的“信息点”,由于这些“信息点”的粒度、层次、构成还是太复杂,因此又被进行分类、归纳、总结成为一系列的“知识体系”,这些“知识体系”各自有重点,同时又具有一定的相关性,有的发展为“学科”,有的发展为“规范”,知识体系在具体应用时又以知识、规则、制度、工具等各种方式来具体体现。

在这些分析、综合、归纳、合并的过程中,关联性并没有消失,但是变得难以掌握和理解——在学习的过程中很少有机会同时应用多种知识及其关联性,而在知识的具体应用过程中,由于其庞大、复杂,只有少数专家能够充分理解、综合应用,大部分人难见全貌、只见一斑,能够学习独立的学科,但是很难根据相关性进行综合应用。于是,又产生了一个新的问题:良好的知识体系得不到良好的应用,这就是常见的“理论与实践脱节”问题。

“角色”是一个抽象的概念,通过角色,能够有机地把知识体系以及实践结果联系在一起,而且是恰到好处——只有需要的知识体系和实践结果才和对应的角色进行关联,通过角色粒度的控制甚至可以达到这样一种效果:只要符合了角色定义要求,那么就能够顺利完成角色活动。另一方面,角色概念与“社会化分工”原理不谋而合,主要差别仅仅是粒度、层次上的差别而已。

人员角色并不代表个人,而是说明个人在某一具体业务活动中应该如何表现以及他们应该承担的责任。角色有一组互相联系的活动需要执行,这些活动密切相关,在功能上互相补充,所以最好由同一个人来执行。活动与知识体系密切相关:知识体系提供活动的输入和输出,并提供活动之间的通信机制。项目团队成员在履行角色职能的过程中,一个人可以担任许多不同的角色,一个角色也可以由多个人来承担。

三、角色团队组建方法

根据“角色团队组建原理”,角色团队组建就是面向问题、人进行角色的定义和关联,把相关知识有机地分布到角色上去,在具体团队组建时进行合理关联配对:让合适的人在合适的时间利用合适的工具完成合适的任务。

1. 从问题分析角色需求

根据相关知识体系、过去的定义、经验、角色定义原则,把解决问题的过程分解为子问题及子活动,控制子活动的粒度甚至粒度层次,并就每个子活动进行关联分析、环境分析、知识分析,最后定义为角色,称为问题解决角色,如“图 3 从问题分析角色需求”所示。

图 3 从问题分析角色需求

 2. 从人员分析角色认可

根据企业发展要求、角色定义原则、人的能力、兴趣等要素,对人进行分析和认可,控制知识体系的粒度、相关性等,最后定义为角色,称为人员认可角色,如“图 4 从人员分析角色认可”所示。

图 4 从人员分析角色认可

四、角色团队组建

在项目团队组建时,根据对问题域的分析结果,在成员角色表中选取对应的角色去承担问题角色任务,并从项目管理的角度来进行工作时间分配、费用预算等。如果企业内部没有所需要的角色,则可以考虑寻求外部资源。如“图 5 以角色为基础的团队组建”所示。

图 5 以角色为基础的团队组建

五、角色团队组建与建设过程

角色团队组建是发生在项目立项时的工作,而角色团队建设是在企业经营的整个生命周期内都要进行的,建设结果是角色团队组建的基础。建设是持续性的,组建是临时性的,建设为组建提供基础,组建后的项目团队的实施结果为建设提供依据,整个过程如“图 6 角色团队组建与建设过程”所示。

图 6 角色团队组建与建设过程

角色团队建设要完成的工作有:

  • 通用问题域角色定义:定义企业开发领域的通用问题,根据对通用问题的解决“从问题分析角色”工作,定义问题域角色体系;
  • 通用人员角色定义:根据“问题域角色体系”,对人进行分析、定义和认证,建立关于“人员角色体系”;对某些超出问题域角色体系的人的角色也进行定义,选择标准可以根据企业的发展方向进行选择;
  • 问题域角色与人员角色映射规则:为了适应企业业务的变化和发展、满足管理要求,问题域角色与人员角色不一定要一一对应,甚至粒度、层次也可以不一样,所以要建立映射规则为以后的工作安排提供指导。

角色团队组建时要完成的工作有:

  • 具体问题域角色定义:以“问题域角色体系”为基础,分析项目所面临的问题,定义“项目角色体系”;
  • 具体人员角色定义:对照“项目角色体系”和“人员角色体系”,根据映射规则,进行配合、关联、调整,完成项目团队的组建和任务计划,进行项目实施;
  • 角色体系改进:在项目实施的任何时刻,如果有超出“问题域角色体系”的角色产生,可以根据需要补充到“问题域角色体系”中,对人员角色体系的变化也可以采取同样方法处理。

在具体的角色团队建设过程中,实际上可以保留多个层次的角色体系,主要原则就是适应企业的经营要求和发展要求,其它相关内容如取舍、粒度控制、层次控制、结构控制、管理、认证等原则和方法本文不再赘述,部分内容可参考RUP。

  • 角色团队分析
  • 一般团队面临的问题和原因

在过去的实际管理过程中,一般团队存在很多问题,包括:

  • 结构简单:过于简单化,“开发团队”等于“工程师集合”,其相关性控制、团队配合等全部依赖于领导者的直觉或感觉;尽管不会完全错误,但是不够精细,属于“粗放”管理范畴;
  • 管理困难:缺乏层次级别,几乎都处于同一个层次上,令难行,禁难止;
  • 职责不清:针对工作内容,一方面缺乏规范,另一方面范围模糊,因此导致职责不清楚,工作目标模糊;
  • 资源浪费:由于组织和管理不力,软件开发效率低、成功率低,并期望通过提高个体素质来提高效率或成功率,片面追求文凭,本科不行用硕士,硕士不行用博士,等等,导致资源浪费,经营成本高;
  • 发展缓慢:团队的进步没有明确的计划和方向,团队的进步依赖于个体的随意发展,因此团队的建设变成了艰难地培养“全才”,很难培养“专才”;企业发展不明确,员工发展也不明确。

导致上述问题存在的根本原因是什么?我们认为,主要的原因有:

  • 对问题的认识不充分:没有对问题域进行定义、分析、内容组织,或者比较薄弱,仅仅从比较高层的软件开发的“需求、分析、设计、开发”出发来进行开发团队的组织,缺乏“具体问题具体分析环节”;
  • 对人的认识不充分:对个体的认识依赖于管理者的直觉、感觉和经验,个体的发展依赖于自己的兴趣,把工作当成任务,过多依赖于文凭评价;
  • 对管理的认识不充分:过分依赖管理者的直觉和感觉,安排任务时“大体上”知道存在的问题、什么人能解决什么问题,但是没有进行问题的分化、定义、具体化等细节工作,比较“粗放”;管理过于依赖于权力;
  • 过于平面化和大粒度:从问题认识、人的认识、管理认识三个方面都缺乏层次化、模块化和结构化,分工粒度过大,忽略问题的多样性、人的多样性、管理的多样性,决策一刀切;

最基本的原因是全面性问题,不够全面导致管理不到位:用不合适的方法去解决模糊的问题,如“图 7 一般团队的问题域覆盖程度”所示,应该解决的问题没有解决,解决问题的人又不一定是合适的。

图 7 一般团队的问题域覆盖程度

六、角色团队对问题的解决

角色团队通过“问题角色体系”的建立来促进对问题的分析,很大程度上解决了一般团队存在的“不够全面”问题,改善了对问题域的覆盖程度,如图“图 8 角色团队提高问题域覆盖程度”所示。通过“人员角色体系”的建立来进行培训、认证、甄别,促进团队建设,并为薪酬体系、绩效考核提供依据。角色团队组建后,管理定位更加容易:管理者有事可做,有章可循;被管理者明确管理定位和职责,依照角色关联的合作更加顺畅。

图 8 角色团队提高问题域覆盖程度

更重要的是,角色团队的组建和建设过程,就是企业知识体系的建设过程,角色体系也就是知识体系,角色体系的改进就是知识体系的挖掘和进步,是学习性组织的良好选择。

七、角色团队的缺点

角色团队的建立和组建,其本身就是一项复杂的管理活动,需要有力的资源支持;角色团队的建设是一个持续性发展的过程,不是一蹴而就的,因此需要企业具有持续建设的需要和能力,也就不适合那些业务方向频繁变化、业务领域不明确的企业。

八、角色团队原理在软件工程实施中的作用

在目前软件工程实施中,“持续改进”无疑是最重要的思想;首先,改进就必须要有一个载体,这个载体必然是企业知识体系,因此也可以采用“角色团队”作为这一载体;其次,改进必须是持续的,也就意味着过去定义的知识体系能够在一定程度上重用。角色团队通过“角色”这一概念来进行知识体系的分解,通过粒度和层次的控制很容易达到高程度重用的目的,因此,角色团队原理可以在软件工程实施中作为实施载体来使用。

以角色团队为基础的企业知识体系还可以很方便地容纳软件工程规范,因而对软件工程的实施具有很高的支持性;通过“人员角色体系”的建立,可以达到对个体的针对性培训和学习引导,对团队的进步具有很好的引导作用。

由于角色粒度、层次控制的灵活性,角色团队的组建和建设可以从任何时候、任何规模开始逐步建设,非常灵活,满足企业逐步成熟的要求。

小结

软件开发是一项知识性活动、创造性活动,软件技术日新月异,软件应用领域复杂多变,所有的这些原因造成了软件开发管理的困难,导致了软件危机的产生。软件管理问题的解决,离不开对知识体系的依赖和对变化的适应。角色团队原理作为一个知识体系的载体以及对持续改进的充分支持,可以作为软件工程实施方法之一。

参考资料

[1]  Stephen P.Robbins,《组织行为学》(第七版),1997,中国人民大学出版社;

[2]  PMI,《A Guide to The Project Management Body of Knowledge》,2000;

[3]  SEI,《CMMI for Systems Engineering/ Software Engineering》,2000;

[4]  Rational,《Rational Unified Process 》,2000。

本文由 @我观世界观 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!