对软件研发项目管理的深入探讨

1、对软件研发项目管理的深入探讨第一章简介1.1研究背景我之前曾在厦门一家中等规模（合计开发人员50MSF（MicrosoflSoknions Framework）软件开发模型1.2研究动机在这篇文章中，要紧淡论了在产品开发中的项目治理问题此处的''产品开发''是折做一个通用的软件 产品或者一些具体的领域性系统集成项目。卜面我要紧结合我们公可实施MSF的悄形.谈谈自己对软件 工程的一些初步看法。第二章MSF概要介绍MSF2。2.1组队模型MSF38人）.多侧面:角色交叉、目标一致:人员技术.业务粘:关注能力 和交货期:対项目的前景认识一致:人人参与设计:善干总结体会

2、:共同治理.共同决策项目人员同地工作等。程序泊理组的工作是： 推动开发过程： 负贵产品规范说明； 沟通和和谐各组关系： 治理项目进度，报告项目状态： 把握总体决第。产品治理组的工作是: 代表客户(customer); 描述项目产品轮廓； 负贵需求定义： 平稳功能和进度要求： 负贵市场、宜传、公共关系等。开发组的工作是： 概要.详细设计： 完成产品开发： 预备安装的产品。测试组的工作是： 制定测试策略和打算： 尽町能发觉问题。用户培训组工作是： 代表终端用户(end user); 负贵用八需求定义;项目治理音联盟文章 把握町用性和用八性能指标。项目治理培训安装治理组工作是： 负贲产品安装： 把損

3、町治理性和町支持性。项目治理培训2.2过程模型项目治理者联盟文承MSF过程模型要紧确立了四个車要的里程碑：丽景范畴确认、项目规划确认、开发完成、对外公布.通过操纵这四个里程碑来分解治理项目过程。2.3应用模型项目治理论坛MSF2.4风险模型MSF第三章MSF在项目中的具体应用项目经理圈子3.1组队模型裁减在中小软件企业中，一样项目的规模可不能太大.通常是十几个人，少的只有几个人因此必须对MSF "；产品治理和测试组：一样包括MSF 中的产品治理组，测试组.用八培训和安装治理要紧代表用八确定软件需求并测试产品是否满足需求； 开发组和MSF第一，确立项目经理角色.符合一样公可的治理模式比

4、较容易被同总。假如有多人同时负贲的话， 容易产生贵权理不浦晰.互相扯皮的现象。有一个项目经理对项目完全负贵.遇到问题容易专门快得到解 决:他作为项目组代表，负贵向上级汇报工作.能使其他人全力投入到项目中，而不至于在日常的事务中 耽搁太多时刻，从而在某种程度上也提高了工作效率。项目治理者联盟 产品治理经理（以卜简称产品经理）是项目中专门垂要的角色他能够对技术不是专门熟知.然而必须对 产品所服务的领域专门熟悉，最好是领域专家.在他的带领下，项目才不至于偏离预先设定的前景范畴。 他必须对产品的需求能作出专门好的把握.在适当的时候能进行流程重组，对产品的町用性和易用性有最 终决定权。依照我们的体会，通

5、过设定产品经理.要紧的感受是产品受用八的欢迎程度增加了，无用的特 性少了.因而也更容易成功。开发组要紧负贵产品的概要设计.详细设计及代码实现这和一样项目中的开发人员差不多，就不再 赘述了。依照我们的体会，如此组建的开发团臥既有助于提高工作效率.又能保证有良好的产品质量。没有设 置产品治理角色的团队城容易产生的问题是开发人员往往喜爱凭他们的主观臆想来设定产品的某些功能. 垠终导致产品易用性极差，不容易为用八所同意。32软件过程治理MSF开发过程总的来说是一个基于里程碑的，迭代的，风险驱动的过程。一样遵循如下原则： 进度打算留有余地:项目治理培训 通过风险治理减少不确定性因索： 通过快速原型法尽可

6、能使产品稳固和可推测： 缩短生命周期： 垂视创新使资源和性能效率最大化； 拆分大项目尊。在过程模型上，要紧包括四个重要里程碑： 前景/范畴确认； 项目规划确认:项目治理者联盟文住 开发完成;项目治理培训 对外公布。我们把MSF的各个时期对应到传统的项目开发符时期.目的是使公可所有人员便干明白得和使用。其 中"前景范踌确认"对应传统疔可行性分析丫项目规划确认”对应啼求分析粋片项目打算丁首次运行”对 应开发完成二公布，的慰思和传统差不多相同。同时.我们也依照公司的具体怙形对流程进行了相疱调 整.把整个流程分为可行性分析、需求分析.开发打算、开发过程和结项总结五个时期.卜面分别进

7、行说 明。3.2可行性分析项目经理圈子按照IS09001的要求.在软件开发前有一个町行性分析烈告讨论项目的町行性和风险.一样公可项 目也都会经历这一时期。做对行性分析一样由以后的项目经理和产品经理共同完成讨论该项目的技术、 经济町行性和潜在的风险等。专门多小公可在做项目前都没有那个过程往往是不管自己的实际情形.匆 忙上马，遇到项目就接.结果是做一个死一个，成功的专门少。项目治理者联盟并对上述风险估显不足，也没有对风险进行较好的治理.因此造成了项目 的不成功。转自项目治理者联盟上面提到可行性分析一样是由以后的项目经理和产品经理完成必要时还需要M场人员的参与，项 目经理要紧考虎技术可行性.包括项目

8、尿初估晁的进度表和资源需求悄形:产品经理要紧考虑山场和经济 上的町行性（要紧是针对软件产品而言）。只有预先对各种问题进行完备的分析后.才能得出正确的决策。 不要到后来因为那些爭先没考虑到的.但应该想到的各种缘故造成项目失败:或者尽管完成了.然而没有 取得预期的成效.不能给公司带来较好的收益。只有在町行性分析通过评审.公司高层领导者认可的情形下才能付渚实施。通过町行性分析.揭示了 立即面临的各种问题及凤险使得公司内部对该项目有了一致的认识.在后来的资源申请上也更容易得到 高层支持.更易干导致项目成功。那种只有一个方法就开始实施的做法是绝对不町取的能够是单兵做 战.但决不是公司行为。项目治理论坛需

9、求分析需求治理是软件开发中专门垂要的部分.在一样的MIS需求的治理要紧由产品经理负贵，其中城终用八（end user）VB或FrontPage建立玻终产品的界面，然后把功能实现和界 面一一对应起来，和用八进行讨论.并不断的修改界面。最终在差不多达成一致后.对应原型写出需求规 格说明书.在评审后纳入基线治理。在后面的开发中.我们必须保证玻终产品界面和原型差不多一致如有变更.則必须提交项目组和客 户讨论。依照我们的体会，优秀的产品经理十用八参与+原型法二良好的需求说明。项目治理论坛1MIS2需求的优先级：需求的优先级是专门重要的特性.只有在准确把握的需求优先级的基础上我们才可能 规划外部里程碑（产

10、品版本）和内部里程碑（开发的时期性.后面会讲到）。通常是用八最关怀.使用最频繁 的功能应该属于高优先级，而那些不如何里要或专门少用到的功能应该属于低优先级。我们必须在产品的 开始版本和项目的开始就把匝点放任高优先级的需求上而关于低优先级的功能能够在项目后期依照需要 进行裁减或纳入F个版本规划。项目经理圈子34其他需求特性：如性能要求、健壮性等。这些特性是产胡的非功能性需求.也是项目成功的关铤因索.专门是在些大型的涉及垂要领域的治理信息系统中。需求分析是整个项目活动中的专门关键的部分.它的好坏往往决定了项目的成败。依照体会.需求分 析所需的时刻往往占整个项目时刻的在需求分析中开发打算风险治理策略

11、等。项目的进度安排相人力资源安排町能是开发打算中瑕遐要的部分.也是最难以估衆的部分。一样国内 的中小软件公司对项目工作显和开发人员能力的量化程度不高因此导致进度和资源安排不确切.有时候 甚至是相差专门远。目前一个鼓实际的方法确实是依照以往项目的枳存，但必须要求是同-领域的类似项 目.如此才有较强的可比性。由于这些打算安排是预估粗略的因此还必须在以后的项目各时期完成后进 行合理的变更.反应项目的实际需求。微软的方法是把进度估显的权限交绐开发人员，由开发人员依照自 己的体会进行估显.由于一样开发人员往往会髙估自己的能力，估虽的进度也会相应偏短.最后再做适当 的延K2。这种方法有它合理的地点.在中国

12、还需进行实践摸索。关于进度的估量.我们有个体会公式，即您最初预估的时刻再乘以2.5,K4。风险治理是项目治理中专门垂要的部分.同时要贯穿项目的始终。一些软件企业往往不是专门重视风 险治理，导致任项目的后期显现了专门多预料之外的情况，使项目进度-拖再拖.往往质量也达不到预期 要求。因此我们要专门重视风险的治理.具体方法留待后面专门详述。324开发过程时期性完成项目比传统的开发方法最明显的优点是不必到项目的末期才开始整合产品使产品模块之 间协作产生的问题及早产生90%大部分的功能模块都已 完成.但剩卜的10%总是完不成.项目进度一拖再拖，专门叫能还要再花90%的时刻来完成剰卜的10%-样在开始的时

13、期进行的是系统架构和最垂要的功能.后面的时期是相对不如何垂要的功能。如此的 分配有利于最终用八在早期就能看到系统的大致楔样.便于他们及早的对产品提!11意见.并对相应的错误 进行修改:也有利于项目组在项目后期时刻专门紧的怙形1去掉一些不垂要的功能，把它们纳入卜一个 版本处理确保产品的推出时刻。迭代的顺利进行依靠于良好的架构设计.前面时期的设计应该给后面要 加入的功能预留出各种接口.并能使后面的工作在前面的基础上连续进行卜去。还有确实是迭代的次数也要依照项目的具体情形而定。不能太多.导致車复的工作虽过大:也不能太少. 使得该方法退化到传统方法。我们的项目（项目小组在10人左右开发时刻在5个月左右

14、）一样分了四个时 期：架构完成、要紧功能完成.其他功能完成、整合发行。实践证明如此的实施比传统方法确实在专门 大程度上减小了项目失败的风险.再没有产生那种唔起来永久也做不完的感受S项目治理者联盟文章那个地点举一个具体例了来更形飲的说明该方法的运用。一个一样的MIS程序，第一时期能够构建数 据库结构和基于待定领域的核心平台服务（包括一些差不多服务类）.并进行初步整合:第二时期町并行同时 开发系统徐大模块的差不多功能.并进行第二次整合:第三时期可开发其他增强功能.也需要相应的功能 整合:第四时期进行整个系统的垠后整合，并可进行相应的性能改进.使产品进入可发行状态。结项总结3.3风险治理MSF的风险

15、治理原则是：1 风险应该在整个项目的进程中一直被估同时作为项目决笫的依据之一。2有效的风险治理过程覆盖了所有关键的人力、过程.商务及技术领域。3风险任纳入治理前必须被淸晰的表述。4垂要的风险必须优先被处理。MSF K险治理过程包括以卜时期：风险识别、凤险陈述.风险分析、处理打如风险跟踪.14险操纵. 风险解除。MSF采纳的方式是：凤险阻碍程度二风险的可能性x风险发生造 成的缺失依照风险阻碍程度的大小对风险进行评级。项目经理博客ill who. when, how, how much等事项.并对风険处理的结果进彳j迫踪.玻后决定是 否差不多解除风险或再进入风险处理循环。3.4质量治理关于软件质量

16、治理现任差不多得到了专门多公司的垂视.那个地点我想针对性地强调几个问題：1 质駅治理不单单是测试。一个容易犯的错谋是把质蛍治理和测试等同起来.假如软件有问题确实是测23使用缺陷迫踪治理工具。我们的实践证明：使用缺陷迫踪治理工具比往常单纯的使用文档传送方式的 效率提高几倍，并在治理诸如优先级.防止遗漏等方面有更大的优势。3.5其他那个地点谈-些没有包括任上述内容里的体会教训.供大伙儿参考：1 项目治理工具。我们使用的是MS Project来治理项目过程.Project 一个专门好的优点是能把项目治 理的内容自动公布到网站上去，这极大地点便了各阶层人员对项目状态的了解，有助于及时发觉问题解决 问题.对项目组成员也是个专门好的鼓舞方法。转自项目治理者联盟2项目团队中需要资深开发人员。我曾经经历过一个项目，项目负贵人坚持用C+ Builder开发（可能是 为了学习的缘故），然而公司没有任何一个人对那个工具专门熟悉.也没有进行相应的风险治理。结果在 项目的过程中出了太多问题使项目一直延期.