MSF在项目中的具体应用.docxVIP

PAGE 1 PAGE 1 MSF在项目中的具体应用  3.1组队模型裁减  在中小软件企业中，一般项目的规模不会太大，通常是十几个人，少的只有几个人，所以必需对MSF的组队模型进行简化。通常的做法是划分成三个组，程序管理组：一般对应于原来的项目经理，通常就项目经理一个人，假如需要还可以给他配个组手，通常称为“项目秘书”;产品管理和测试组：一般包括MSF中的产品管理组，测试组、用户培训和安装管理，主要代表用户确定软件需求并测试产品是否满意需求;开发组：和MSF的开发组相同。这样的组队，比较符合中小项目的需要，在实践中也证明是比较合理的。  首先，确立项目经理角色，符合一般公司的管理模式，比较简单被接受。假如有多人同时负责的话，简单产生责权理不清晰，相互扯皮的现象。有一个项目经理对项目完全负责，遇到问题简单很快得到解决;他作为项目组代表，负责向上级汇报工作，能使其他人全力投入到项目中，而不至于在日常的事务中耽搁太多时间，从而在某种程度上也提高了工作效率。  在原来的许多项目中，大多都没有设置产品管理角色，他的工作一般由项目经理兼任。这样的做法已证明存在许多问题，会使项目经理精力分散，而且产品管理的任务和项目的日常管理工作也不大相同，假如叫一个人负责，怕两头都顾不上搞不好。在产品管理组中，依据项目的大小，可以设置两个负责人，一个代表用户确定需求，另一个主要负责测试，但由前一个负总责。因为只有用户代表认可了的产品品质，才是真正可以交付的品质。  产品管理经理(以下简称产品经理)是项目中特别重要的角色，他可以对技术不是很精通，但是必需对产品所服务的领域特别熟识，最好是领域专家，在他的带领下，项目才不至于偏离预先设定的前景范围。他必需对产品的需求能作出很好的把握，在适当的时候能进行流程重组，对产品的可用性和易用性有最终打算权。依据我们的经验，通过设定产品经理，主要的感觉是产品受用户的欢迎程度增加了，无用的特性少了，因而也更简单成功。  开发组主要负责产品的概要设计，具体设计及代码实现，这和一般项目中的开发人员差不多，就不再赘述了。  依据我们的经验，这样组建的开发团队既有助于提高工作效率，又能保证有良好的产品质量。没有设置产品管理角色的团队最简单产生的问题是开发人员往往喜欢凭他们的主观臆想来设定产品的某些功能，最终导致产品易用性极差，不简单为用户所接受。  3.2软件过程管理  MSF开发过程总的来说是一个基于里程碑的，迭代的，风险驱动的过程。一般遵循如下原则：  ①进度计划留有余地;项目管理培训  ②通过风险管理削减不确定性因素;  ③通过快速原型法尽可能使产品稳定和可预估;  ④缩短生命周期;  ⑤重视创新使资源和性能效率最大化;  ⑥拆分大项目等。  在过程模型上，主要包括四个重要里程碑：  ①前景/范围确认;  ②项目规划确认;项目管理者联盟文章  ③开发完成;项目管理培训  ④对外发布。  我们把MSF的各个阶段对应到传统的项目开发各阶段，目的是使公司全部人员便于理解和使用。其中“前景范围确认”对应传统的“可行性分析”;“项目规划确认”对应“需求分析”和“项目计划”;“首次运行”对应“开发完成”，“发布”的意思和传统基本相同。同时，我们也依据公司的详细状况对流程进行了相应调整，把整个流程分为可行性分析、需求分析、开发计划、开发过程和结项总结五个阶段，下面分别进行说明。  3.2.1可行性分析项目经理圈子  根据ISO9001的要求，在软件开发前有一个可行性分析报告，争论项目的可行性和风险，一般公司项目也都会经历这一阶段。做可行性分析一般由将来的项目经理和产品经理共同完成，争论该项目的技术、经济可行性和潜在的风险等。许多小公司在做项目前都没有这个过程，往往是不管自己的实际状况，匆忙上马，遇到项目就接，结果是做一个死一个，成功的很少。  在做可行性分析的时候，要充分考虑公司以前的各种技术和市场积累，还有目前的资源可用性状况，特殊是要做好风险分析。我以前就遇到过这种状况，一个项目的领域和公司以前的领域不尽相同，在立项前没有充分考虑各种状况，认为这个项目比较简洁，应当没什么问题，结果是没有做得很成功，进度上也拖了一段时间。在后来结项分析的时候，认为主要的问题就是领域的区分造成了公司内部没有人对该领域特殊熟识，缺乏领域专家，并对上述风险估计不足，也没有对风险进行较好的管理，所以造成了项目的不成功。  上面提到，可行性分析一般是由将来的项目经理和产品经理完成，必要时还需要市场人员的参与，项目经理主要考虑技术可行性，包括项目最初估