浅谈某项目中的问题与解决方案袁志军2007/07/24[摘要]当前，在整个软件行业的激烈竞争下，项目的成败将关系到软件企业的生存与发展，项目需要建立在自我不断创新和高质量满足客户要求的基础上。

建立这种基础的前提就是要具备很强的对“需求、问题或机会”的识别能力以及提出相应解决方案的能力。

因此如何随时识别项目中各项风险和问题，对整个项目的实施过程中的风险进行预测，进而对各种风险进行跟踪预防、规避，转为问题后妥善的解决这些问题，成为项目成败的关键。

选择适当的软件开发模型能清晰、直观地表达软件开发全过程，明确规定要完成的主要活动和任务，用来作为软件项目工作的基础。

我们公司很多的项目都选用瀑布模型，瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，其特点是每个阶段有明确的开始和结束点,一个阶段的输出为下一阶段的输入条件。

它很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中用户很难参与进去，只有到开发结束才能看到整个软件系统。

这种理想的、线性的开发过程缺乏灵活性，不适应实际的开发过程。

我们所使用的实际上是渐增模型。

渐增模型是在瀑布模型基础上加以改进而来的增量模型。

它是以瀑布模型为基础，按功能增量方式进行增量开发。

[项目背景]某项目是个WEB系项目的典型：工期紧，开发人员能力弱的项目。

项目生命周期为渐增模型。

项目过程阶段为项目启动阶段、式样理解、编码Coding、Debug）、UT、画面集成、系统验收及维护、项目结束。

项目要求2006年12月24日上线，为保证上线前ITF公司的结合测试和系统测试，我们必须于12月10日完成UT和初步的结合测试交货。

由于时间仓促，式样设计没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，11月10日给出经过Review的版本。

项目规模：25人月。

项目的各个阶段都有一些不同的问题存在，对其进行分析并提出解决方案，希望能为以后的项目提供帮助。

一．项目前期：它包括建立项目组织、对项目进行估算、制订相关的计划、系统可行性调查分析、营业上的沟通、技术上的学习培训等准备工作。

典型的工作产品：项目任务书，项目工程计划报告书。

也就是用分阶段的生命周期计划严格管理。

这一条是吸取前人的教训而提出来的。

统计表明，50%以上的失败项目是由于计划不周而造成的。

在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。

这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。

为了更好的控制好项目，某项目导入CMMI,它很好的规范和定义好了软件开发和管理的过程，为项目的成功提供了在作计划是往往会碰到：1．没有完整的基本设计或详细设计；2．人力不足；3.人员能力弱等问题；由于这些问题的存在，想要完全按照瀑布模型来实施就会很困难；在某项目中式样设计由于时间仓促，没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，到11月10日给出经过Review的版本。

没有完整的基本设计式样理解就不完全，式样理解阶段就没结束，而瀑布模型规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，所以编码开发就不能完全进行。

如果等到式样理解完全结束在进入开发的话，就会增加开发、测试的风险—时间不够；因此采取了渐增的方式：开发从11/1日开始，11/1日～11/10日安排对新人的培训，根据一期的经验和能确定的稳定的式样先进性部分画面的开发，开发完毕后进入测试阶段；11月10日拿到经过Review的式样版本，～11/10进行式样理解，11/13日开始未开发的画面，开发完毕后进行测试；符合使用渐增模型的开发模式。

这样既能完成一部分页面的开发测试，同时新人在10天的培训中能力得到了提升，为后面页面的开发提供了保障。

1.1式样不足：先找稳定的部分进行或和客户商讨找出相对稳定的模块先着手，把计划排在前面，不稳定的排在后面；先推动项目，去发现存在的问题，并且进行理解和讨论，不产生Rework的工作都可以安排先做起来，比如培训预算等；和客户确定接受物的日程，清楚什么时候能够拿到达成公式的稳定的资料；设定假定的条件，在假设的基础上的进行评估，如果假设变了，在重新评估；通过各种方法，尽可能促成假定条件得到满足。

1.2人力不足：开发只有参与过10月版的开发人员7名（含一名PJL），测试2名，另外一名PM，根据10月版开发的经验，当时的人力缺少开发5名（其中需要一名技术支持），测试2名，测试经理一名。

先把这个问题列入风险管理票中，写入可能的预防措施和补救措施并进行跟踪：预防措施：提升现有成员的作业能力；和事业部长或公司的领导进行沟通，是否有调整资源的可能性，争取能得到自己想要的人力资源，并告知如果人力不足可能导致的问题；某项目中经过公司内部调整，增加4名开发人员，但都缺乏实际项目开发经验需要进行相关的培训，测试人员Pending，调入技术部张晓洲进入项目，项目得以按时启动。

1.3人员能力弱：这是项目中不可避免的问题，公司最近引进了很多新人，必须让他们加入项目，在项目中锻炼他们，提升他们各方面的能力。

能力弱的人员可能难以完成交付给他们的工作，甚至其工作效率可能比你想象还要低。

要认识正视这个项目组人员问题。

否则，随着能力弱的人员的工作的失败，整个项目很可能延误。

措施：前期的培训一定要有，特别是项目的规范和所要使用的技术，某项目中11/1日～11/10日就安排对新人的培训，让他们熟悉编码规约，Webpump的使用等；把能力弱的人员指定SE或SubLeader来带，然他们来负责控制这些人员的质量和进度。

二.项目中期2.1．式样理解如何才能做好式样理解呢？在式样理解阶段，下面成员应该遵照式样理解计划和制定式样理解指南进行，如与计划和不符的应该及时与leader进行沟通，作为项目的管理者，也需要了解式样理解的状况以便及时调整；在式样理解阶段开始前最好就建立好QAMS的帐户或问题回答票，以会议的形式严格要求，避免问题的遗忘；尽量的站在客户的角度去理解式样；对式样理解进行review，并对重要的画面进行重点理解评审，保证式样理解的质量，尽早的发现问题。

在某项目中式样理解开始时东京QAMS迟迟没见好，式样理解中发现的问题没有及时记录，共享性也不足。

在11/2日的周会上发现了该问题，决定用excel暂时管理问题，统一发给东京，共通性的问题以mail的形式通知全员。

但也许因为这个原因，一开始对QA要求的不严格，导致开发人员过于依赖式样，开发阶段提出的式样问题不多，大部分问题在进入测试阶段后才发现。

2.2．编码如何提高开发质量？任何软件开发项目中，质量不仅仅拥有发言权，而且对项目的成败拥有表决权甚至最终的否决权。

质量不仅仅会对软件开发项目本身的成败产生影响，而且会对我们软件企业的形象、商誉的褒贬带来冲击和震荡。

质量是指项目满足明确或隐含需求的程度。

①定标：首先定义作业范围的交付物标准来明确定义作业成果物的质量，包括质量的各种特性及这些特性需要满足的要求；还可能对项目的过程质量做出明确规定，包括软件开发所规定的流程、开发的规范和BUG率的标准，以及有效执行这些过程的证据；还可能对项目的顾客应对质量作出规定，包括应对顾客的态度、速度以及方法。

以会议的形式让你的项目成员了解要达到的质量目标所需要努力，通过项目努力，完成的工作产品以及其过程满足客户要求的程度，把目标量化。

某项目在综合管理计划中明确指出了目标值：对重要画面（20%）进行重点的理解评审；开发人员在画面编码结束时，要自己按CD CheckPoint对代码进行自检；通过利用Night Build检查代码的规范性；画面编译通过，开发人员自己构建基本case，并且保留纪录，按照基本case进行调试，调试通过算完成，leader对debugcase和执行情况进行抽样检查；各开发Leader对Member的代码review率>50%；对UT Case的review率>50%；Bug检出标准:标准值：8个，最低值：6个，最大值：15个；目标明确，给提高质量打下了基础。

②选择：指定项目成员中质量意识，开发质量高，技术能力高的成员去带动相对低的成员，在实际工作中去影响他们，言传身教的提升相对较弱的成员。

③管理：采取一些的方法来确保质量：检查、监督；验证：就是要用数据证明开发人员是不是在正确的制造产品。

注意这里强调的是过程的正确行。

确认：就是要用数据证明开发人员是不是制造了正确的产品。

注意这里强调的是结果的正确性。

review：最好是subLeader以上的成员来担当。

某项目中要求开发人员自己构建基本case，并且保留纪录，按照基本case进行调试，调试通过才算完成该画面；一开始的计划是PJL主要review新人，有过一期开发经验的人相互review，从进展的结果来看，程序员之间相互review几乎没有效果，因为他们总是着重于自己的画面，review流于形式，只是单纯的为了完成计划而已，质量得不到保证。

④交流和沟通。

设计(式样)管理组内人员的交流和沟通；项目成员间的交流和沟通；与客户的交流和沟通都是必不可少的。

要求你的项目成员在任何交流或沟通的场合里都能敞开心扉，完整地表达自己的观点。

通过交流沟通会发现项目隐藏的问题和风险。

某项目中通过相互的交流和沟通发现由于设计人员在细节方面考虑的不够，有部分的共通类存在问题，会对项目的开发造成很大的影响，于是要求东京设计担当人员于11月13日至11月17日到南京进行式样讲解和式样答疑，就在这一周时间内，式样变更频繁。

消除了设计上和式样上的缺陷，为项目的成功打下了基础。

⑤端正态度，树立正确的编码观念。

提高项目成员的质量意识。

让他们从思想上认识开发质量的重要性。

很一些开发人员认为只要页面出来编码完就行了，甚至单一的认为自己已经按照式样书开发完了，测试是测试人员的事情。

事实证明不是，编码只是开发的第一步，还有很重要的一步那就是DEBUG。

BEBUG可以发现代码中的缺陷，如果做的不好，BUG率就会偏高。

有统计结果显示：大部分错误是在编码阶段造成的; 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级，给项目增加了成本。

并且如果还有开发计划的话，要完成SCHEDULE又要对应BUG的话，加班就很可能难免了。

另外，过高的BUG率会让LEADER降低对此成员的信任，同时此成员的自信心也会受到影响，进而可能会对项目的成功造成阻碍。

对此，也可以采取一些方法，例如：可以让开发的成员把所要开发的画面和式样书打印出来，然后要求其对照式样一一DUBUG，DEBUG完一项就打勾，直到完成，然后交由LEADER确认。