解析不同种类的软件项目团队模型.pptVIP

解析不同种类的软件项目团队模型 传统项目团队模型 项目组在项目经理的带领下，各角色协调工作，为项目成功而努力！ 各角色的具体职责如下： 项目经理：整体协调项目，编制计划及保证计划执行，推动项目成功。 系统分析员：分析系统需求，保证系统需求既满足客户要求，同时保证技术可行性；指导项目技术方案及系统架构设计。 软件设计师：细化系统设计。 程序员：编码实现设计。 测试工程师：测试系统，保证系统满足需求。 实施工程师：部署、调试系统，培训客户，协助客户推动系统上线运行。 配置管理员：对整个项目周期中的工作产品实施配置管理。 QA：质量保证工程师，保证开发过程按照既定的要求进行，保证工作产品符合既定的规范。 这个传统团队模型有两大特点： 1.一个团队总有一个头（这也是我们的惯性思维），这个头就是项目经理。 2.假设各种专业的角色能协调工作，并能各自发挥所长。 我们希望项目团队能有一个强大的头领，加上一班专业人才，共同为项目成功而努力。 但实际情况有这么理想吗？ 项目经理会埋怨手下能力不够、不主动报告工作、不主动承担责任...... 而项目组成员会埋怨项目经理不够强，只会叫他干活，不授权，更加不会传授知识...... 实际项目团队模型 我们实际项目的团队结构，往往是这样的： 实际情况与理想的传统模型比较，有以下重大差异： 1.项目经理身兼多职。 很多项目往往没有专职的系统分析员和软件设计师，项目经理兼任需求分析与软件设计的工作，甚至还需要负责编码的工作。图中系统分析员、软件设计师这两个角色都是虚线框，意思就是表示这两个角色往往只是虚位，难以落实具体的专职的人员。 项目经理要做的事情太多了，往往没有办法专注项目管理，项目计划相关的文档能免则免，项目设计文档能少则少。 2.测试工程师、实施工程师低人一等。 很多公司公司的测试工程师、实施工程师会“低人一等”，开发人员有天生的优越感，而项目经理往往是由开发人员升任的，项目经理会有意无意地将测试工程师、实施工程师摆低一级。各角色如果不能平等的工作，项目团队战斗力自然大受影响。 造成这种不平等的原因主要有两个：一就是开发人员的天生优越感，二就是整体来说我们的测试工程师、实施工程师水平确实还不够 在我们公司其实也有这样的“不平等”情况，我花了很多时间营造“平等”的氛围，我的主要办法有： 1）通过各种途径不断强调项目团队各专业人才的重要性。 2）想尽办法提高测试工程师与实施工程师的水平。 3.配置管理员、QA再低人一等，甚至可有可无。 图中这两种角色是灰色的，这两者可能是整个项目团队中最“惨淡”的角色了！ 好一点的公司都会有配置管理员，但往往被当作文员来看待，而有些公司甚至没有专职的配置管理员，项目经理甚至没有想到要配置管理这回事。QA是一个四面不讨好，到处惹人非议的角色，可以说是项目组中最“差”的职位了。 造成这局面原因也主要有两个：一就是大家的习惯性思维认为这两个职位就是最不重要的，二就是我们的配置管理员、QA的水平还不够的问题。 对于配置管理工作，其实实质就是项目生命周期中各种工作产品的管理工作，我认为项目经理应该发挥更大的作用，而我们的配置管理员应该嵌入到项目的具体中去完成工作，而不要只抱着配置管理的大道理来工作。 QA确实是最痛苦的职位，优秀的QA需要有资深的项目经验，但有资深项目经验的人大都不愿意做QA，这是多么矛盾和痛苦啊！ 简单地说，实际的项目团队结构有以下严重问题： 1.团队的头不能专职项目管理。 2.项目团队中各专业人才要么缺失、要么严重不平等。 MSF的项目团队模型 微软的团队没有项目经理，由6类角色组成： 产品经理(Product Management)、 程序经理(Program Management) 开发(Development) 测试(Test) 发布管理(Release Management) 用户体验(User Experience)。 各类角色负责的职责如下 1.没有所谓的项目经理。 程序经理这个角色可以说是最接近项目经理的了，他需要编制计划及跟踪计划执行，但在行政级别上，他不是大家的头，大家都是平等的，大家只是处在不同专业的角度来负责工作。 2.强调项目团队是由各专家组成的。 软件开发活动是高强度高挑战的智力活动，我们需要由各类专家共同负责协调工作，每位专家都是同等重要的。 3.用户体验是我们常常忽略的部分。 用户体验简单地说就是用户使用软件时的感觉，软件的颜色、布局、文字、行为等等会直接影响用户使用软件的满意度。目前我们国内的项目组，往往没有用户体验设计环节，也没有专职的用户体验设计师。 MSF团队模型在实际工作中难以应用的原因 1.各专业人才水平参差不齐。 国内以上六类角色的水平由高到低排列，大致这样：开发、程序经理、产品管理、测试、发布管理、用