《谈某项目中的问题与解决方案.doc》由会员分享，可在线阅读，更多相关《谈某项目中的问题与解决方案.doc（8页珍藏版）》请在三一办公上搜索。
1、浅谈某项目中的问题与解决方案袁志军2007/07/24摘要 当前，在整个软件行业的激烈竞争下，项目的成败将关系到软件企业的生存与发展，项目需要建立在自我不断创新和高质量满足客户要求的基础上。建立这种基础的前提就是要具备很强的对“需求、问题或机会”的识别能力以及提出相应解决方案的能力。因此如何随时识别项目中各项风险和问题，对整个项目的实施过程中的风险进行预测，进而对各种风险进行跟踪预防、规避，转为问题后妥善的解决这些问题，成为项目成败的关键。选择适当的软件开发模型能清晰、直观地表达软件开发全过程，明确规定要完成的主要活动和任务，用来作为软件项目工作的基础。我们公司很多的项目都选用瀑布模型，瀑布模
2、型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，其特点是每个阶段有明确的开始和结束点,一个阶段的输出为下一阶段的输入条件。它很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程缺乏灵活性，不适应实际的开发过程。我们所使用的实际上是渐增模型。渐增模型是在瀑布模型基础上加以改进而来的增量模型。它是以瀑布模型为基础，按功能增量方式进行增量开发 。项目背景某项目是个WEB系项目的典型：工期紧，开发人员能力弱的项目。项目生命周期为渐增模型。项目过程阶段为项目启动阶段、式样理解、编码C
3、oding、Debug）、UT、画面集成、系统验收及维护、项目结束。项目要求2006年12月24日上线，为保证上线前ITF公司的结合测试和系统测试，我们必须于12月10日完成UT和初步的结合测试交货。由于时间仓促，式样设计没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，11月10日给出经过Review的版本。项目规模：25人月。项目的各个阶段都有一些不同的问题存在，对其进行分析并提出解决方案，希望能为以后的项目提供帮助。一项目前期：它包括建立项目组织、对项目进行估算、制订相关的计划、系统可行性调查分析、营业上的沟通、技术上的学习培训等准备工作。典型的工作产品：项目任
4、务书，项目工程计划报告书。也就是用分阶段的生命周期计划严格管理。这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。为了更好的控制好项目，某项目导入CMMI,它很好的规范和定义好了软件开发和管理的过程，为项目的成功提供了在作计划是往往会碰到：1没有完整的基本设计或详细设计；2人力不足； 3.人员能力弱 等问题；由于这些问题的存在，想要完全按照瀑布模型来实施就会很困难；在某项目中式
5、样设计由于时间仓促，没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，到11月10日给出经过Review的版本。没有完整的基本设计式样理解就不完全，式样理解阶段就没结束，而瀑布模型规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，所以编码开发就不能完全进行。如果等到式样理解完全结束在进入开发的话，就会增加开发、测试的风险时间不够；因此采取了渐增的方式：开发从11/1日开始，11/1日11/10日安排对新人的培训，根据一期的经验和能确定的稳定的式样先进性部分画面的开发，开发完毕后进入测试阶段；11月10日拿到经过Review的式样版本，11/10进行式样理解，
6、11/13日开始未开发的画面，开发完毕后进行测试； 设计开发式样理解测试设计开发式样理解测试时间进度符合使用渐增模型的开发模式。这样既能完成一部分页面的开发测试，同时新人在10天的培训中能力得到了提升，为后面页面的开发提供了保障。1.1式样不足：先找稳定的部分进行或和客户商讨找出相对稳定的模块先着手，把计划排在前面，不稳定的排在后面；先推动项目，去发现存在的问题，并且进行理解和讨论，不产生Rework的工作都可以安排先做起来，比如培训预算等；和客户确定接受物的日程，清楚什么时候能够拿到达成公式的稳定的资料；设定假定的条件，在假设的基础上的进行评估，如果假设变了，在重新评估；通过各种方法，尽可能
7、促成假定条件得到满足。 1.2人力不足：开发只有参与过10月版的开发人员7名（含一名PJL），测试2名，另外一名PM，根据10月版开发的经验，当时的人力缺少开发5名（其中需要一名技术支持），测试2名，测试经理一名。 先把这个问题列入风险管理票中，写入可能的预防措施和补救措施并进行跟踪：预防措施：提升现有成员的作业能力；和事业部长或公司的领导进行沟通，是否有调整资源的可能性，争取能得到自己想要的人力资源，并告知如果人力不足可能导致的问题；某项目中经过公司内部调整，增加4名开发人员，但都缺乏实际项目开发经验需要进行相关的培训，测试人员Pending，调入技术部张晓洲进入项目，项目得以按时启动。1.
8、3人员能力弱：这是项目中不可避免的问题，公司最近引进了很多新人，必须让他们加入项目，在项目中锻炼他们，提升他们各方面的能力。能力弱的人员可能难以完成交付给他们的工作，甚至其工作效率可能比你想象还要低。要认识正视这个项目组人员问题。否则，随着能力弱的人员的工作的失败，整个项目很可能延误。措施：前期的培训一定要有，特别是项目的规范和所要使用的技术，某项目中11/1日11/10日就安排对新人的培训，让他们熟悉编码规约，Webpump的使用等；把能力弱的人员指定SE或SubLeader来带，然他们来负责控制这些人员的质量和进度。二.项目中期2.1 式样理解如何才能做好式样理解呢？在式样理解阶段，下面成
9、员应该遵照式样理解计划和制定式样理解指南进行，如与计划和不符的应该及时与leader进行沟通，作为项目的管理者，也需要了解式样理解的状况以便及时调整；在式样理解阶段开始前最好就建立好QAMS的帐户或问题回答票，以会议的形式严格要求，避免问题的遗忘；尽量的站在客户的角度去理解式样；对式样理解进行review，并对重要的画面进行重点理解评审，保证式样理解的质量，尽早的发现问题。在某项目中式样理解开始时东京QAMS迟迟没见好，式样理解中发现的问题没有及时记录，共享性也不足。在11/2日的周会上发现了该问题，决定用excel暂时管理问题，统一发给东京，共通性的问题以mail的形式通知全员。但也许因为这
10、个原因，一开始对QA要求的不严格，导致开发人员过于依赖式样，开发阶段提出的式样问题不多，大部分问题在进入测试阶段后才发现。2.2编码如何提高开发质量？任何软件开发项目中，质量不仅仅拥有发言权，而且对项目的成败拥有表决权甚至最终的否决权。质量不仅仅会对软件开发项目本身的成败产生影响，而且会对我们软件企业的形象、商誉的褒贬带来冲击和震荡。质量是指项目满足明确或隐含需求的程度。定标：首先定义作业范围的交付物标准来明确定义作业成果物的质量，包括质量的各种特性及这些特性需要满足的要求；还可能对项目的过程质量做出明确规定，包括软件开发所规定的流程、开发的规范和BUG率的标准，以及有效执行这些过程的证据；还
11、可能对项目的顾客应对质量作出规定，包括应对顾客的态度、速度以及方法。以会议的形式让你的项目成员了解要达到的质量目标所需要努力，通过项目努力，完成的工作产品以及其过程满足客户要求的程度，把目标量化。某项目在综合管理计划中明确指出了目标值：对重要画面（20%）进行重点的理解评审；开发人员在画面编码结束时，要自己按CD CheckPoint对代码进行自检；通过利用Night Build检查代码的规范性；画面编译通过，开发人员自己构建基本case，并且保留纪录，按照基本case进行调试，调试通过算完成，leader对debugcase和执行情况进行抽样检查；各开发Leader对Member的代码rev
12、iew率50%；对UT Case的review率50%；Bug检出标准:标准值：8个，最低值：6个，最大值：15个；目标明确，给提高质量打下了基础。选择：指定项目成员中质量意识，开发质量高，技术能力高的成员去带动相对低的成员，在实际工作中去影响他们，言传身教的提升相对较弱的成员。管理：采取一些的方法来确保质量：检查、监督；验证：就是要用数据证明开发人员是不是在正确的制造产品。注意这里强调的是过程的正确行。确认：就是要用数据证明开发人员是不是制造了正确的产品。注意这里强调的是结果的正确性。review：最好是subLeader以上的成员来担当。某项目中要求开发人员自己构建基本case，并且保留纪
13、录，按照基本case进行调试，调试通过才算完成该画面；一开始的计划是PJL主要review新人，有过一期开发经验的人相互review，从进展的结果来看，程序员之间相互review几乎没有效果，因为他们总是着重于自己的画面，review流于形式，只是单纯的为了完成计划而已，质量得不到保证。交流和沟通。设计(式样)管理组内人员的交流和沟通；项目成员间的交流和沟通；与客户的交流和沟通都是必不可少的。要求你的项目成员在任何交流或沟通的场合里都能敞开心扉，完整地表达自己的观点。通过交流沟通会发现项目隐藏的问题和风险。某项目中通过相互的交流和沟通发现由于设计人员在细节方面考虑的不够，有部分的共通类存在问题
14、，会对项目的开发造成很大的影响，于是要求东京设计担当人员于11月13日至11月17日到南京进行式样讲解和式样答疑，就在这一周时间内，式样变更频繁。消除了设计上和式样上的缺陷，为项目的成功打下了基础。端正态度，树立正确的编码观念。提高项目成员的质量意识。让他们从思想上认识开发质量的重要性。很一些开发人员认为只要页面出来编码完就行了，甚至单一的认为自己已经按照式样书开发完了，测试是测试人员的事情。事实证明不是，编码只是开发的第一步，还有很重要的一步那就是DEBUG。BEBUG可以发现代码中的缺陷，如果做的不好，BUG率就会偏高。有统计结果显示：大部分错误是在编码阶段造成的; 错误发现的越晚，改正它
15、要付出的代价就越大，要差2到3个数量级，给项目增加了成本。并且如果还有开发计划的话，要完成SCHEDULE又要对应BUG的话，加班就很可能难免了。另外，过高的BUG率会让LEADER降低对此成员的信任，同时此成员的自信心也会受到影响，进而可能会对项目的成功造成阻碍。对此，也可以采取一些方法，例如：可以让开发的成员把所要开发的画面和式样书打印出来，然后要求其对照式样一一DUBUG，DEBUG完一项就打勾，直到完成，然后交由LEADER确认。慢慢的让成员养成DUBUG习惯，把大量的编码问题扼杀在开发阶段。某项目中要求就明确要求出DEBUG报告书（C0 Managerment01 Engineeri
16、ngMng06 CDDebug報告書）。持续提高开发人员各方面的技能。开发人员的技术能力提高了开发出来的代码的质量也会得到提高，公司的实力才会得到提升。软件开发技术日新月异，客户的需求变动不居，所以所有成员都应持续的学习和提高，这一点相信大家都有共识。本公司的技术推进组也根据公司的营运目标制定技术培训课程、根据计划对相关人员进行培训；事业部的日语培训，并根据相应的情况制定了相应的奖惩措施。这就进一步保证了公司的整体实力在迈向一个新的台阶。2.3.BUG对应:如何对应好测试出的问题？首先开发人员要摆正对测试人员的态度。要理解虽然开发和测试在某种程度上是对立的，但是从项目的角度来说是统一的，都是为
17、了保证项目的成功，为公司盈利。测试人员是在帮助开发人员发现编码中的缺陷，完善开发的程序。其次BUG的对应应该也要注重方法：BUG再现。有时可能是由于版本环境等问题造成的，一看到BUG不加再现的就去修改的话，很可能会造成时间的浪费，而且可能会改出新的问题；BUG修正。再现了BUG后，针对问题点进行修改，修改是要切忌改出新的问题；BUG验证。只是对所修正问题的品质保证，必不可少；BUG修正的SOURCE上传CVS.填写回复QA票。 做到以上五步，就大大的减少了BUG回归的可能。2.4如何提高项目成员的战斗力？在项目作业过程中宣扬团队精神。消除个人表演主义，集合众智，趋向成功。当我们以团队的形式工作
18、时，要比以孤军奋战的形式来得更加富有成效。团队的协同工作比个人竞争更能激励项目成员。软件开发过程中必须消除单打独斗的个人主义，催生团队精神。为了实现共同的目标，为了发挥团队的集合力量，而相互合作、相互支援的精神状态。团队精神应该包括下述要点：自我激励。基于一种成功、成就、成长的意愿而自我激励、自我督促、自我提升。在工作中不仅仅执行上级的命令，更重要的是积极地参与，起到决策与辅助决策的作用。换位思考。站在其他项目组成员和项目管理者的立场上思考问题，避免产生误解，创造和谐互动的作业氛围。熟悉团队内其他成员的工作，保证工作协调顺利进行，避免因为自己的作业质量或者作业进度影响到团队的质量和作业效率。合
19、作推断。决定团队作业效率的关键因素可能不是团队成员的能力，而是精诚合作的态度。假设别人会积极主动地进行合作为前提来决定自己应该采取的行动，即以合作和开放的心态来回应别人的行为，以此形成一个“善的循环”。某项目中手纸画面承接着很多其他画面的借口，担当者主动召开关联者会议，互相讨论来决定参数命名和参数在画面间的流动。力量整合。团队的存在意义在于团队的整合力量远远大于每个成员单独力量的总和，能得到一种相乘效果，即超越个人力量之和。项目组成员的角色就在于，从团队整合力量的角度出发来整合众人的力量。责任驱动。项目开发流程的终断、项目进度的迟缓、项目问题的浮现、项目质量的脆弱等并非与团队某位成员毫不相干，
20、因为团队意味着共同承担最终责任，共同享受最后荣光。在项目责任面前，每人肩上都有份量，因此必须彻底消除“与我无关”的态度。伙伴关系。软件开发团队成员之间需要基于共同成功的目标而相互支持和帮助。具体而言，每位成员在工作中要积极地参与项目的各种活动；团队成员比较熟悉团队内其他人员的工作，以保证工作协调进行；在其他成员需要的时候，主动提供支持。团队精神，在某项目中一直贯穿项目的始终。例如：项目中由于设计将画面和业务层分开，画面设计与类设计中间缺少接口设计书，开发的时候也将开发业务类和画面系分开，造成画面系的人不了解画面的业务逻辑，开发类的人不知道具体方法是由哪些画面调用；为此项目成员之间自发召开与自己
21、画面相关的人员进行相互沟通，相互通力合作解决担当任务之间的磨合问题。某些开发人员能力偏弱，独立解决问题比较困难。PJL和subleader经常会去帮助开发人员解决问题，让画面按计划提交测试，保证测试的顺利进行。项目的管理者姚茜也多次在项目会议上要求项目的成员发扬团队精神。这为项目的成功奠定了坚实的基础。待添加的隐藏文字内容32.5如何来预防项目成员的流失？ 古人云：“凡事预则立、不预则废”，从团队培养的角度来说，只有具有持续吸引力的团队才是最稳固的团队，凝聚技术性人才的真正动力，在超越了收入这一层次的时候，技术素养的培养更具有吸引力，这就必然要求技术部门的管理者要能够有一个相对长远的技术规划，
22、一方面能够让企业在技术手段上能够立于不败，另一方面能够使团队的每一个成员感受到吸引力和进步感，这样，既能够稳定技术结构，又能够稳定人员结构。我想，这也是技术部门是否能够留住一流技术人才、软件企业是否能够持续发展壮大的一个根本原因之一。三项目后期：项目后期的要点？开发和测试要密切的配合开完成画面集成和测试，确保系统验收的成功；对各功能模块的功能单元进行语句覆盖、分枝覆盖或其他等级的跟踪执行以验证程序实现的正确性。或者编制单体测试程序以验证程序实现的正确性。并将软件作为一个整体与硬件运行环境结合起来，验证并保证工作产品正确地实现并满足了系统要件定义书所确定的客户的功能性需求和其他需求（性能目标、安
23、全性、信赖性、扩充性、移植性、多语言对应等）。建立项目后期维护体制实施项目后期的维护。对项目进行评价以及相关资料进行汇总管理。项目的成员都应该自我总结在项目中的经验，并以书面的形式提交个人总结报告。项目总结报告已提交后，要确定日期召开项目总结会议，对项目的数据度量、管理、技术、配置等方面进行全面的总结和回顾，会后，对项目数据和所有项目总结报告进行汇总分析，形成项目总结报告。阿基里斯为古希腊英雄，因浸泡过冥河之水而刀枪不入，最大的弱点就是脚踵，结果在特洛伊之战因此被杀死。要克服这最致命弱点，就需要充分了解构成这一弱点的诸多问题，并寻求解决之道。项目也如似，软件开发项目过程中的问题太多了，但是我们
24、可以把以前项目中常见问题，从预防的角度而言，可以把已知的可能导致项目失败的“祸根”或引起项目失败的“原因”-风险列出来，识别潜在的问题-确认这些风险是否有可能会影响我们项目的进展，并记录每个风险所具有的特点。然后量化它-评估风险和风险之间的相互作用，以便评定项目可能的产出结果的范围。再对策研究-确定对机会进行选择的步骤及对危险作出应对的步骤。最后用对策实施控制-对项目进程中风险所产生的变化作出反应。虽然不可能排除所有风险，但是我们可以避免特定的风险事件；减缓或减少风险发生的影响和概率,勇于接受不可避免的风险产生的后果,及时的跟踪采取措施，将影响降到最低，从而保证项目的成功，为我们的企业盈利。参考文献1 PMBOK2项目开发章程拟订：EPG组 32006_002_某某通販S（SN）项目计划书
