总 结
图 8-1 项目阶段
软件项目开发经历多个阶段，每个阶段包含多个任务，每个任务会产生相应的工件。需要相应的质量保证措施对任务进行监控，保证任务的执行。任务完成后也需要对任务进行评审，保证任务的质量。
这些工作均由开发团队和相关人员按照工作流程执行。因此，合理的角色任务分配和沟通制度是软件项目成功的重要保障。
图 8-2 列出几种比较普遍的角色和任务划分方案：
图 8-2 角色和任务划分方案
职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因，一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分，这样团队中的每个成员才可能有清晰的责任和目标。
软件开发不管采用哪种生命周期模型和开发方法论，整个过程都会包含需求，设计，开发，测试，配置管理等各项活动。而这些活动会对应到项目中的不同角色，项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。
方案一 项目负责人总览全局
对于小作坊的软件开发团队，可以由一个项目负责人总览全局。项目负责人承担从用户需求->软件需求->总体设计的所有工作。同时还 需要做到整个团队进度规划，质量保证，配置管理和沟通协调等相关工作。所以小型项目团队对项目负责人的业务，技术和沟通管理等技能都要求较高，项目负责人 是项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。
我们这里指的小型团队并不是只一个人单打独斗的项目，所以项目负责人最好不要介入到模块设计和编码活动中，而是应该把重点放在进度的控制和质量 的保证上面。由于项目负责人一般有较强的技术能力，所以项目负责人可以承担项目中要使用的一些新技术的研究，项目中一些疑难问题的解决等相关工作。项目负 责人还应该有计划的设计开发人员的代码进行Review，对发现的规范性，性能，复用差等问题跟项目成员确认，并写入到项目开发规范中。
方案二 项目负责人和开发负责人分离
在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同来确认项目的总体方案和架构。项目负责人的重点在 项目管理和与客户交流沟通上，只有确认清楚第一手的用户需求，才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚就开工，项目成 员完全凭借着自己的感觉在做系统，过程中又不注意与用户及时反馈和迭代，导致开发出完全不能使用的系统；开发负责人的重点是对整个开发过程负责，包括对项 目经理确认的进度目标进行任务的进一步分解，安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理，架构的核心移动到了开发负责人，而项目经理仅 仅是参与讨论和评审。而单独剥离出开发负责人后，可以更好的对开发过程进行跟踪和协调，开发负责人重点放在项目内部，而避免过多去和外部干系人沟通和协 调。
方案三 测试的专职化
对于项目团队发展到5-10的时候，项目中的测试工作必须专职化的由测试人员来完成。一般测试人员的配置比例为4-6个开发人员需要配置一名专 职化的测试人员。测试人员站在第三方和模拟使用者角度来进行系统的测试，可以更好的发现系统的BUG和相关问题，有效的保证系统的质量。
方案三中项目经理工作进一步清晰，项目经理不在承担软件需求和架构的相关工作。而重点放在项目内外的沟通协调和整个项目进度计划的安排上。这个 时候项目中的设计负责人对整个系统的总体设计方案和架构负责，而且设计负责人也将不在参与具体的功能模块的设计和开发工作。设计负责人的重点转化到的软件 需求的开发和总体设计上面(如涉及到RUP中的用例建模，用例分析，架构设计，组件接口复用)。
方案四 项目经理和需求角色分离
当项目团队的规模发展到12-20人的时候，项目团队基本上可以算做中小型的项目团队。这个时候项目经理完全专职化做项目管理的工作。包括项目 进度计划制定，项目跟踪监控，风险分析和控制，项目度量分析和决策等相关内容。对于需求活动设置专门的需求工程师岗位来完成需求的开发。同时项目中设置专 门的架构设计人员，架构设计人员不再负责需求的开发工作，而重点在于系统总体设计方案的确定，系统的4+1视图的分析，同时架构人员要考虑整个系统的集成 方案的确定和具体功能单元和模块的集成。
由于项目规模的扩大，项目的配置项更加复杂，项目也需要同时起开发，测试，集成和BugFix等多个分支。因此需要设置专门的配置管理员来进行项目的配置管理。
对于项目同时需要开发新版本，又需要对已经发布的维护版本进行功能改进的时候，项目中要考虑设置专门的维护人员。由维护人员来完成项目小功能的改进和BUG的修复。这样新版本设计开发人员可以更专注的进行新功能的开发。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
