四种团队开发范型_团队管理制度范例

四种团队开发范型由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“团队管理制度范例”。

3.2.3软件项目组

软件开发的组织结构几乎与开发软件的组织一样多。不管怎么说，组织结构不能轻易改变。关心组织改变所产生的实际的及政策上的影响，并不是软件项目管理者的责任范围。但是，在一个新的软件项目中直接涉及到的人员的组织，则是项目管理者的职责。

下面给出为一个项目分配人力资源的若干可选方案，该项目需要n个人工作k年n个人被分配来完成m个不同的功能任务，相对而言几乎没有合作的情况发生；协调是软件管理者的责任，而他可能同时还有六个其他项目要管。

2.n个人被分配来完成m个不同的功能任务(m＜n)，建立非正式的“小组”；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。

3.n个人被分成t个小组；每一个小组完成一个或多个功能任务；每一个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；协调工作由小组和软件项目管理者共同控制。

虽然对于上述的每一种方法都可以找到其优点和缺点，但越来越多的证据表明正式的组织小组(策3种方法)是生产率最高的。“最好的”小组结构取决于组织的管理风格、组里的人员数目及他们的技术水平和整个问题的难易程度。Mantei［MAN81］提出了三种一般的小组组织方式

民主分权式(Democratic Decentralized，DD)：这种软件工程小组没有固定的负责人。“任务协调者是短期指定的，之后就由其他协调不同任务的人取代”。问题和解决方法的确定是由小组讨论决策的。小组成员间的通信是平行的。

控制分权式(ControlledDecentralized，CD)：这种软件工程小组有一个固定的负责人，他协调特定的任务及负责子任务的二级负责人关系。问题解决仍是一个群体活动，但解决方案的实现是由小组负责人在子组之间进行划分的。子组和个人间的通信是平行的，但也会发生沿着控制层产生的上下级的通信。

控制集权式(Controlled Centralized，CC)：顶层的问题解决和内部小组协调是由小组负责人管理的。负责人和小组成员之间的通信是上下级式的。

Mantei还给出了计划软件工程小组的结构时应该考虑的七个项目因素

·待解决问题的困难程度。

·要产生的程序的规模，以代码行或者功能点来衡量。

·小组成员需要待在一起的时间(小组生命期)。

·问题能够被模块化的程度。

·待建造系统所要求的质量和可靠性。

·交付日期的严格程度。

·项目所需要的社交性(通信)的程度。

表3－1［MAN81］总结了项目特性对小组组织的影响。因为集中式的结构能够更快地完成任务，因此最适合处理简单问题。而分散式的小组比起个人而言能够产生更多更好的解决方案，因此，这种小组在处理复杂问题时成功的可能性更大。因为CD小组是集中式地解决问题，所以CD或CC小组结构能够成功地用来解决简单的问题。而DD结构则适于解决难度较大的问题。

因为小组的性能与必须进行的通信量成反比，所以很大的项目最好采用CC或CD结构的小组组织方式，如果子组能够很容易地协调的话。

小组“在一起”的时间的长短影响小组的士气。我们发现DD小组结构能够产生较高的士气和工作满意度，因此适合生命期较长的小组。

DD小组结构最适于解决模块化程度较低的问题，因为它需要更多的通信。如果有可能要较高的模块化程度(这时人们自己做自己的事情)，则CC或CD结构更加合适。

CC和CD小组已被发现能够产生比DD小组更少的缺陷，但这与小组所采用的质量保证活动密切相关。分散式结构通常需要比集中式结构更多的时间来完成一个项目，但如果要求高社交性，它是最适合的。

Constantine［CON93］提出了软件工程小组的四种“组织范型”封闭式范型：按照传统的权利层次来组织小组(类似CC小组)。这种小组在开发与过去已经做过的产品类似的软件时十分有效，但在这种封闭式范型下难以进行创新式的工作。

2.随机式范型：松散地组织小组，并依赖于小组成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但当需要“有次序的执行”才能完成工作时，这种小组组织范型就会陷入困境。

3.开放式范型：试图以一种，既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适于解决复杂问题，但可能不象其他类型小组那么效率高。

4.同步式范型：依赖于问题的自然划分，组织小组成员各自解决问题的片断，他们之间没有什么主动的通信需要。

从历史角度看，最早的软件小组是控制集权式(CC)结构，原来称为主程序员小组。这种结构由Harlan Mills首先提出，并由Baker［BAK72］描述出来。小组的核心是由以下人员组成的：一个高级工程师(“主程序员”)，负责计划、协调和复审小组的所有技术活动；技术人员(一般2到5个人)，执行分析和开发活动；以及一个后备工程师，支持高级工程师的活动，并能在项目进行过程中，以最小的代价取代高级工程师的工作。

主程序员可以由一个或多个专家(如电讯专家，数据库设计者)、支持人员(如技术文档写作者，行政人员)和软件资料员来担当。资料员为多个小组服务，执行以下功能：维护和控制所有软件配置(如文档，源程序，数据和磁介质)；帮助收集和格式化软件生产数据；分类和索引可复用软件模块；辅助小组进行研究、评估及文档准备。资料员的重要性不能过分强调。资料员充当了软件配置的控制者、协调者及潜在的评估者。

不考虑小组的组织，每一个项目管理者的目标都是帮助建立一个有凝聚力的小组。在“人”的论著中，DeMarco和Lister［DeM87］讨论了这个问题

我们在商业中随便使用小组这个词，把任何被分配在一起工作的一组人都称为一个“小组”。但很多这样的组并不象小组，它没有统一的对于成功的定义，没有任何可标识的团队精神，它们所缺少的是一种很珍贵的东西，我们称之为凝聚力。

一个有凝聚力的小组是一组团结紧密的人，他们的整体力量大于个体力量的总和……

一旦一个小组具有凝聚力，成功的可能性就大大提高。这个小组不可阻挡，成为成功的象征……他们不需要按照传统的方式进行管理，也不需要去激励。他们已经有了动力。

DeMarco和Lister认为有凝聚力小组的成员比起一般的小组而言，具有更高的生产率和更大的动力。他们共享一个共同的目标、共同的文化，而且在很多情况下，“精英的感觉”使得他们独一无二。