MSF在项目中的具体应用
作者: 来源: 文字大小:[大][中][小]
3.1组队模型裁减
在中小软件企业中，一般项目的规模不会太大，通常是十几个人，少的只有几个人，所以必须对MSF的组队模型进行简化。通常的做法是划分成三个组，程序管理组：一般对应于原来的项目经理，通常就项目经理一个人，如果需要还可以给他配个组手，通常称为“项目秘书”;产品管理和测试组：一般包括MSF中的产品管理组，测试组、用户培训和安装管理，主要代表用户确定软件需求并测试产品是否满足需求;开发组：和MSF的开发组相同。这样的组队，比较符合中小项目的需要，在实践中也证明是比较合理的。
首先，确立项目经理角色，符合一般公司的管理模式，比较容易被接受。如果有多人同时负责的话，容易产生责权理不清楚，互相扯皮的现象。有一个项目经理对项目完全负责，遇到问题容易很快得到解决;他作为项目组代表，负责向上级汇报工作，能使其他人全力投入到项目中，而不至于在日常的事务中耽误太多时间，从而在某种程度上也提高了工作效率。
在原来的很多项目中，大多都没有设置产品管理角色，他的工作一般由项目经理兼任。这样的做法已证明存在很多问题，会使项目经理精力分散，而且产品管理的任务和项目的日常管理工作也不大相同，如果叫一个人负责，怕两头都顾不上搞不好。在产品管理组中，根据项目的大小，可以设置两个负责人，一个代表用户确定需求，另一个主要负责测试，但由前一个负总责。因为只有用户代表认可了的产品品质，才是真正可以交付的品质。
产品管理经理(以下简称产品经理)是项目中非常重要的角色，他可以对技术不是很精通，但是必须对产品所服务的领域非常熟悉，最好是领域专家，在他的带领下，项目才不至于偏离预先设定的前景范围。他必须对产品的需求能作出很好的把握，在适当的时候能进行流程重组，对产品的可用性和易用性有最终决定权。根据我们的经验，通过设定产品经理，主要的感觉是产品受用户的欢迎程度增加了，无用的特性少了，因而也更容易成功。
开发组主要负责产品的概要设计，详细设计及代码实现，这和一般项目中的开发人员差不多，就不再赘述了。
根据我们的经验，这样组建的开发团队既有助于提高工作效率，又能保证有良好的产品质量。没有设置产品管理角色的团队最容易产生的问题是开发人员往往喜欢凭他们的主观臆想来设定产品的某些功能，最终导致产品易用性极差，不容易为用户所接受。
3.2软件过程管理
MSF开发过程总的来说是一个基于里程碑的，迭代的，风险驱动的过程。一般遵循如下原则：
①进度计划留有余地;项目管理培训
②通过风险管理减少不确定性因素;
③通过快速原型法尽可能使产品稳定和可预测;
④缩短生命周期;
⑤重视创新使资源和性能效率最大化;
⑥拆分大项目等。
在过程模型上，主要包括四个重要里程碑：
①前景/范围确认;
②项目规划确认;项目管理者联盟文章
③开发完成;项目管理培训
④对外发布。
我们把MSF的各个阶段对应到传统的项目开发各阶段，目的是使公司所有人员便于理解和使用。其中“前景范围确认”对应传统的“可行性分析”;“项目规划确认”对应“需求分析”和“项目计划”;“首次运行”对应“开发完成”，“发布”的意思和传统基本相同。同时，我们也根据公司的具体情况对流程进行了相应调整，把整个流程分为可行性分析、需求分析、开发计划、开发过程和结项总结五个阶段，下面分别进行说明。
3.2.1可行性分析项目经理圈子
按照ISO9001的要求，在软件开发前有一个可行性分析报告，讨论项目的可行性和风险，一般公司项目也都会经历这一阶段。做可行性分析一般由未来的项目经理和产品经理共同完成，讨论该项目的技术、经济可行性和潜在的风险等。很多小公司在做项目前都没有这个过程，往往是不管自己的实际情况，匆忙上马，遇到项目就接，结果是做一个死一个，成功的很少。
在做可行性分析的时候，要充分考虑公司以前的各种技术和市场积累，还有目前的资源可用性情况，特别是要做好风险分析。我以前就碰到过这种情况，一个项目的领域和公司以前的领域不尽相同，在立项前没有充分考虑各种情况，认为这个项目比较简单，应该没什么问题，结果是没有做得很成功，进度上也拖了一段时间。在后来结项分析的时候，认为主要的问题就是领域的区别造成了公司内部没有人对该领域特别熟悉，缺乏领域专家，并对上述风险估计不足，也没有对风险进行较好的管理，所以造成了项目的不成功。
上面提到，可行性分析一般是由未来的项目经理和产品经理完成，必要时还需要市场人员的参与，项目经理主要考虑技术可行性，包括项目最初估计的进度表和资源需求情况;产品经理主要考虑市场和经济上的可行性(主要是针对软件产品而言)。只有预先对各种问题进行完备的分析后，才能得出正确的决策。不要到后来因为那些事先没考虑到的，但应该想到的各种原因造成项目失败;或者虽然完成了，但是没有取得预期的效果，不能给公司带来较好的收益。
只有在可行性分析通过评审，公司高层领导者认可的情况下才能付诸实施。通过可行性分析，揭示了即将面临的各种问题及风险，使得公司内部对该项目有了一致的认识，在后来的资源申请上也更容易得到高层支持，更易于导致项目成功。那种只有一个想法，就开始实施的做法是绝对不可取的，可以是单兵做战，但决不是公司行为。
3.2.2需求分析
需求管理是软件开发中非常重要的部分，在一般的MIS型项目中，准确的把握需求往往是项目成功的关键。但需求管理也是个困难的过程，据我所知，太多项目的需求都没有良好的管理过程，往往导致项目后期的大量修改或者直接使项目失败。
需求的管理主要由产品经理负责，其中最终用户(end user)的实时参与是一个非常重要的因素。在需求采集阶段，我们主要采用了原型法，使用VB或者FrontPage建立最终产品的界面，然后把功能实现和界面一一对应起来，和用户进行讨论，并不断的修改界面。最终在基本达成一致后，对应原型写出需求规格说明书，在评审后纳入基线管理。
在后面的开发中，我们必须保证最终产品界面和原型基本一致，如有变更，则必须提交项目组和客户讨论。根据我们的经验，优秀的产品经理+用户参与+原型法=良好的需求说明。
在需求的制定过程中，产品经理必须和项目经理、开发人员、测试人员进行良好的沟通，使项目组全体都参与到需求分析中来，并共同确定需求的关键特性：
1.项目的范围：在需求分析中，首先必须明确项目的范围，去掉那些看似属于该项目其实不该在项目中的需求特性。特别是在一些MIS项目中，客户往往把一些属于他们的日常工作但不属于该项目的需求提交给项目组，这时就必须分清项目的范围，不要在项目中加入太多不应该做的东西，否则往往会导致项目范围无限扩大，最终只能是使项目失败。
2.需求的优先级：需求的优先级是非常重要的特性，只有在准确把握的需求优先级的基础上我们才可能规划外部里程碑(产品版本)和内部里程碑(开发的阶段性，后面会讲到)。通常是用户最关心，使用最频繁的功能应该属于高优先级，而那些不怎么重要或很少用到的功能应该属于低优先级。我们必须在产品的开始版本和项目的开始就把重点放在高优先级的需求上，而对于低优先级的功能可以在项目后期根据需要进行裁减或纳入下一个版本规划。
3.产品的易用性：产品的易用性反映在原型中，是原型法的一个非常重要的作用。很多产品的失败其一个重要原因就是易用性比较差，虽然它在功能上满足了用户需求，甚至可以说功能很强大。通过原型法，能让用户看到并模拟使用最终的产品界面，能在需求阶段通过修正软件界面来适应用户的偏好，从而在很大程度上提高了产品的易用性，使项目更容易成功。blog.mypm.net
4.其他需求特性：如性能要求、健壮性等。这些特性是产品的非功能性需求，也是项目成功的关键因素，特别是在一些大型的涉及重要领域的管理信息系统中。
需求分析是整个项目活动中的非常关键的部分，它的好坏往往决定了项目的成败。根据经验，需求分析所需的时间往往占整个项目时间的12%[1]。在需求分析中，需要防止的一个错误做法是太依靠一些所谓的分析方法，而使整个需求分析过程非常复杂，过多的图表往往使人眼花缭乱，而不能准确抓住问题的本质。一些分析人员往往对自己熟悉的简单的业务花大力气，而对不熟悉的则一笔带过，也是本末倒置的错误行为。在分析过程中，我们必须始终把握需求分析的目的是把模糊的流程搞清晰，把复杂的业务尽量简化，而不是相反。
需求的管理也是非常重要的方面。对需求分析完后的形成的规格说明需要进行专门的评审，并且需要客户和最终用户的参与，在达成一致后形成最初的需求基线。以后对需求的更改都必须在基线的基础上进行，并需要项目组各成员的一致确认，对需求进行严格规划评审的目的也在于在项目的后期能尽量减少对需求的更改，提高开发的效率。
需求分析完成后，项目组需要对项目的初步计划进行重新审定，一般都需要变更项目时间表和资源需求。需求分析的完成也意味着项目其他部分可以齐头并进，如概要设计、测试计划、用户说明书，这也在某个方面证明了需求分析的重要性-它是下面所有活动的基础和准绳。
3.2.3开发计划
软件开发中的计划性是非常重要的，一个没有良好计划的开发项目能够成功的机会非常小，除非有天才的程序员再加上好运气。开发计划的主要内容包括：项目进度安排、人力资源安排，风险管理策略等。
项目的进度安排和人力资源安排可能是开发计划中最重要的部分，也是最难以估计的部分。一般国内的中小软件公司对项目工作量和开发人员能力的量化程度不高，所以导致进度和资源安排不确切，有时候甚至是相差很远。目前一个最实际的办法就是根据以往项目的积累，但必须要求是同一领域的类似项目，这样才有较强的可比性。由于这些计划安排是预估粗略的，所以还必须在以后的项目各阶段完成后进行合理的变更，反应项目的实际需求。微软的办法是把进度估计的权限交给开发人员，由开发人员根据自己的经验进行估计，由于一般开发人员往往会高估自己的能力，估计的进度也会相应偏短，最后再做适当的延长[2]。这种办法有它合理的地方，在中国还需进行实践摸索。
对于进度的估计，我们有个经验公式，即您最初预估的时间再乘以2.5，可能是最后的完成时间。因为许多人在估计进度的时候，往往忽略了很多非开发时间，如与客户沟通的时间、项目组沟通时间、公司培训时间、假期等，所以我们在估计进度的时候，一定要全方位周全考虑，在尽可能的情况下宁愿把进度估计的长一点，免得在项目后期导致非常被动的局面。后面我们将具体讲到我们采取的阶段性的开发方法，这种方法的运用反映在进度估计时必须在各阶段间预留缓冲时间，以解决那些我们事先没有预料到的活动。如果进度表和要求的出货时间有冲突，宁愿砍掉一些不重要的功能，也不要盲目增加人手，这种做法可能会导致产品质量下降，最终得不偿失，详细说明请参考[4]。
风险管理是项目管理中非常重要的部分，并且要贯穿项目的始终。一些软件企业往往不是很重视风险管理，导致在项目的后期出现了很多预料之外的事情，使项目进度一拖再拖，往往质量也达不到预期要求。因此我们要特别重视风险的管理，具体方法留待后面专门详述。
3.2.4开发过程
在项目的开发过程中，我们采用了阶段式的开发过程，这也是微软公司所推荐的开发过程。在开发过程的初期，首要的活动是概要设计。概要设计的目标是简单、适用、能够覆盖所有的需求并能支持后面的阶段式开发。微软的应用方案解决模型是基于服务的三层(多层)架构，包括用户层，业务层和数据层，各层之间采用标准的接口进行通讯，至于该方法的具体使用，请参看相关书籍，在此就不在赘述了。
阶段开发过程不是传统的根据模块划分来依次完成各模块，最后再进行项目的整合，而是在每个阶段完成后，项目都可以推出产品，只不过该产品的功能比最终产品的功能弱一些。
阶段性完成项目比传统的开发方法最明显的优点是不必到项目的末期才开始整合产品，使产品模块之间协作产生的问题及早产生，也及早修正，从而项目的风险也大大减小。传统的开发总是在项目的后期才开始整合各模块，使产生的问题改正起来极为困难，成本也大大增加;前面累计的所有问题全部都拖到了后面来解决，也使后面剩下的工作量大大增加。项目往往看起来已完成了90%——大部分的功能模块都已完成，但剩下的10%总是完不成，项目进度一拖再拖，很可能还要再花90%的时间来完成剩下的10%。当然采用阶段性开发方法也有相应的代价，最大的代价可能是反复的整合、测试已经完成的模块，但采用相应的一些自动化工具可以减小这个代价。
一般在开始的阶段进行的是系统架构和最重要的功能，后面的阶段是相对不怎么重要的功能。这样的分配有利于最终用户在早期就能看到系统的大致模样，便于他们及早的对产品提出意见，并对相应的错误进行修改;也有利于项目组在项目后期时间很紧的情况下，去掉一些不重要的功能，把它们纳入下一个版本处理，确保产品的推出时间。迭代的顺利进行依赖于良好的架构设计，前面阶段的设计应该给后面要加入的功能预留出各种接口，并能使后面的工作在前面的基础上继续进行下去。
这种在开发阶段的迭代方式不同于整个项目的完全迭代开发，后者是项目的需求、概要设计、开发等全部是迭代进行，一次迭代要进行所有的项目活动。至于谁优谁劣可能在不同的情况下有不同的说法，需要根据项目和自身的情况合理采用。
还有就是迭代的次数也要根据项目的具体情况而定。不能太多，导致重复的工作量过大;也不能太少，使得该方法退化到传统方法。我们的项目(项目小组在10人左右，开发时间在5个月左右)一般分了四个阶段：架构完成、主要功能完成、其他功能完成、整合发行。实践证明，这样的实施比传统方法确实在很大程度上减小了项目失败的风险，再没有产生那种“似乎永远也做不完的感觉”。
这里举一个具体例子来更形象的说明该方法的运用。一个一般的MIS程序，第一阶段可以构建数据库结构和基于特定领域的核心平台服务(包括一些基本服务类)，并进行初步整合;第二阶段可并行同时开发系统各大模块的基本功能，并进行第二次整合;第三阶段可开发其他增强功能，也需要相应的功能整合;第四阶段进行整个系统的最后整合，并可进行相应的性能改进，使产品进入可发行状态。
3.2.5结项总结
很多公司在项目完成后往往忽视了最后的总结，没有把在上个项目中得到的经验教训进行分析，转化成公司的巨大财富。我们认为，项目的总结是整个项目的不可缺少的重要组成部分，只有通过详尽的充分的项目总结，才能使项目组的所有成员对项目的历程有一个清楚的了解，提高他们对软件项目的认识;才能真正地把以往的项目纳入公司的资源库，转化成巨大的财富。
我们的做法是在项目完成后首先由各个项目成员写出各自的总结报告，包括所从事的工作、任务的完成情况、遇到的问题及解决方案、对项目过程的意见和自己的想法等内容。项目负责人需要把整个的项目历程整理成一份文件，其中包括项目的介绍、项目进行的具体资料(如实际花费时间、源代码数、功能模块数量等)、项目计划与实际的比较等。
在上述完成后，全体项目参与人员举行项目结项工作会议，对各人所列举的问题及想法进行讨论，目的是得出好的经验教训，从而指导后面项目过程。会议可由分别针对的问题分为几个部分，如项目过程方面的、质量管理方面的、技术方面的等，整合后形成结项会议报告。
项目负责人最后把项目历程、资料、在结项会议中总结的经验教训等整理成一份总的项目过程文件，归档并分发到各成员和上层领导，并由项目经理向上层领导汇报，这时，一个完整的项目才真正告一段落。这些项目资料给以后的项目提供很好的模板和借鉴意义，并可以作为以后项目预估的依据。
3.3风险管理
微软公司认为，软件开发是一个风险驱动的过程，由此可看出风险管理在软件项目中的重要性。一个项目的风险有许多来源，如客户、进度、开发过程、人力资源等，忽视风险的后果可能是成本超支、进度推后，最严重导致项目失败。
MSF的风险管理原则是：
1.风险应该在整个项目的进程中一直被估计，并且作为项目决策的依据之一。
2.有效的风险管理过程覆盖了所有关键的人力、过程、商务及技术领域。
3.风险在纳入管理前必须被清晰的表述。
4.重要的风险必须优先被处理。
MSF风险管理过程包括以下阶段：风险识别、风险陈述、风险分析、处理计划、风险跟踪、风险控制、风险解除。
在中小企业的风险管理过程中，一般项目经理担任风险管理员的角色，但同时需要另外的资深开发人员辅助，一起完成风险管理的任务。他们负责维护十大风险清单(不一定非要列出十个)，并在项目进程中随时对风险清单进行更新。对风险的评级MSF采用的方式是：风险影响程度=风险的可能性×风险发生造成的损失，根据风险影响程度的大小对风险进行评级。项
在项目实施中，我们总结的一些高风险事件主要有：需求的不准确、项目时间表过于短促、开发一个从前没进入的领域软件、开发人员对工具的不熟悉、人员流动频繁、使用了外部软件中间件等。如果对这些风险不提前作出计划，可能会对项目的顺利进行造成极大的破坏，甚至直接导致项目失败。针对每一个风险，我们需要列出who, when, how, how much等事项，并对风险处理的结果进行追踪，最后决定是否已经解除风险或再进入风险处理循环。
一般国内公司的风险意识不强，没有很好的去规划处理风险。我们当时也是这样，往往要等到风险已经发生了，才意识到原来没有注意到这些问题。在风险的管理上，还需要更多的实践探索，首先应该从加强风险意识开始。
3.4质量管理
关于软件质量管理，现在已经得到了很多公司的重视，这里我想针对性地强调几个问题：
1.质量管理不单单是测试。一个容易犯的错误是把质量管理和测试等同起来，如果软件有问题就是测试没做好。其实质量管理包括很多内容，如技术检查、缺陷追踪、源代码追踪、单元测试、系统测试等。
2.质量管理不是在代码完成后才开始，质量管理应该贯穿整个项目始终，从需求、设计到编码、测试。我们往往只重视了后期对代码的测试，而忽略了对需求、设计的质量管理，而前者比较起来可能更为重要。因为处理一个在后期才发现的错误比处理一个前期发现的错误的成本要高几十倍。
3.使用缺陷追踪管理工具。我们的实践证明：使用缺陷追踪管理工具比以前单纯的使用文档传送方式的效率提高几倍，并在管理诸如优先级、防止遗漏等方面有更大的优势。
3.5其他
这里谈一些没有包括在上述内容里的经验教训，供大家参考：
1.项目管理工具。我们使用的是MS Project来管理项目过程，Project一个很好的优点是能把项目管理的内容自动发布到网站上去，这极大地方便了各阶层人员对项目状态的了解，有助于及时发现问题解决问题，对项目组成员也是个很好的激励方法。
2.项目团队中需要资深开发人员。我曾经经历过一个项目，项目负责人坚持用C++ Builder开发(可能是为了学习的原因)，但是公司没有任何一个人对这个工具非常熟悉，也没有进行相应的风险管理。结果在项目的过程中出了太多问题，使项目一直延期，在交付的时候都还存在很多问题。所以在项目团队中一定需要资深开发人员，特别是在项目的前期更是如此。
3.再次强调产品经理角色。必须牢牢记住：一个不管使用了什么先进技术、开发方法的产品，如果不能满足用户的需要，就是一个失败的产品。而产品经理角色的设立能较好满足这一要求。
4.在领域性较强的项目中，最好在基本的软件架构上(如COM或J2EE)实现一个该领域的基础开发平台，这样在以后的扩展上，在具体项目的实施上，都会极大的节省成本，软件的质量也有良好的保证。