谈某项目中的问题与解决方案

对担当过的项目做了分析

浅谈某项目中的问题与解决方案

袁志军 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．编码

如何提高开发质量？

任何软件开发项目中，质量不仅仅拥有发言权，而且对项目的成败拥有表决权甚至最终的否决权。质量不仅仅会对软件开发项目本身的成败产生影响，而且会对我们软件企业的形象、商誉的褒贬带来冲击和震荡。质量是指项目满足明确或隐含需求的程度。

①定标：首先定义作业范围的交付物标准来明确定义作业成果物的质量，包括质量的各种特性及这些特性需要满 …… 此处隐藏：6445字，全部文档内容请下载后查看。喜欢就下载吧 ……