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

此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 浅谈某项目中的问题与解决方案浅谈某项目中的问题与解决方案 袁志军 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 确认 慢慢的让成员养成 DUBUG 习惯 把大量的编码问题扼杀在开发阶 段 某项目中要求就明确要求出 DEBUG 报告书 C0 Managerment 01 EngineeringMng 06 CD Debug 報告書 持续提高开发人员各方面的技能 开发人员的技术能力提高了开发出来的代码的质量也会得到提 高 公司的实力才会得到提升 软件开发技术日新月异 客户的需求变动不居 所以所有成员都应 持续的学习和提高 这一点相信大家都有共识 本公司的技术推进组也根据公司的营运目标制定技 术培训课程 根据计划对相关人员进行培训 事业部的日语培训 并根据相应的情况制定了相应的 奖惩措施 这就进一步保证了公司的整体实力在迈向一个新的台阶 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 2 3 BUG 对应 如何对应好测试出的问题 首先开发人员要摆正对测试人员的态度 要理解虽然开发和测试在某种程度上是对立的 但是 从项目的角度来说是统一的 都是为了保证项目的成功 为公司盈利 测试人员是在帮助开发人员 发现编码中的缺陷 完善开发的程序 其次 BUG 的对应应该也要注重方法 BUG 再现 有时可能是由于版本环境等问题造成的 一 看到 BUG 不加再现的就去修改的话 很可能会造成时间的浪费 而且可能会改出新的问题 BUG 修正 再现了 BUG 后 针对问题点进行修改 修改是要切忌改出新的问题 BUG 验证 只是对所 修正问题的品质保证 必不可少 BUG 修正的 SOURCE 上传 CVS 填写回复 QA 票 做到以上五步 就大大的减少了 BUG 回归的可能 2 4 如何提高项目成员的战斗力 在项目作业过程中宣扬团队精神 消除个人表演主义 集合众智 趋向成功 当我们以团队的形式工作时 要比以孤军奋战的形式来得更加富有成效 团队的协同工作比个人竞 争更能激励项目成员 软件开发过程中必须消除单打独斗的个人主义 催生团队精神 为了实现共 同的目标 为了发挥团队的集合力量 而相互合作 相互支援的精神状态 团队精神应该包括下述 要点 自我激励 基于一种成功 成就 成长的意愿而自我激励 自我督促 自我提升 在工作中不仅 仅执行上级的命令 更重要的是积极地参与 起到决策与辅助决策的作用 换位思考 站在其他项目组成员和项目管理者的立场上思考问题 避免产生误解 创造和谐互动 的作业氛围 熟悉团队内其他成员的工作 保证工作协调顺利进行 避免因为自己的作业质量或者 作业进度影响到团队的质量和作业效率 合作推断 决定团队作业效率的关键因素可能不是团队成员的能力 而是精诚合作的态度 假设 别人会积极主动地进行合作为前提来决定自己应该采取的行动 即以合作和开放的心态来回应别人 的行为 以此形成一个 善的循环 某项目中手纸画面承接着很多其他画面的借口 担当者主动召 开关联者会议 互相讨论来决定参数命名和参数在画面间的流动 力量整合 团队的存在意义在于团队的整合力量远远大于每个成员单独力量的总和 能得到一种 相乘效果 即超越个人力量之和 项目组成员的角色就在于 从团队整合力量的角度出发来整合众 人的力量 责任驱动 项目开发流程的终断 项目进度的迟缓 项目问题的浮现 项目质量的脆弱等并非与 团队某位成员毫不相干 因为团队意味着共同承担最终责任 共同享受最后荣光 在项目责任面前 每人肩上都有份量 因此必须彻底消除 与我无关 的态度 伙伴关系 软件开发团队成员之间需要基于共同成功的目标而相互支持和帮助 具体而言 每位 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 成员在工作中要积极地参与项目的各种活动 团队成员比较熟悉团队内其他人员的工作 以保证工 作协调进行 在其他成员需要的时候 主动提供支持 团队精神 在某项目中一直贯穿项目的始终 例如 项目中由于设计将画面和业务层分开 画 面设计与类设计中间缺少接口设计书 开发的时候也将开发业务类和画面系分开 造成画面系的人 不了解画面的业务逻辑 开发类的人不知道具体方法是由哪些画面调用 为此项目成员之间自发召 开与自己画面相关的人员进行相互沟通 相互通力合作解决担当任务之间的磨合问题 某些开发人 员能力偏弱 独立解决问题比较困难 PJL 和 subleader 经常会去帮助开发人员解决问题 让画面 按计划提交测试 保证测试的顺利进行 项目的管理者姚茜也多次在项目会议上要求项目的成员发 扬团队精神 这为项目的成功奠定了坚实的基础 2 5 如何来预防项目成员的流失 古人云 凡事预则立 不预则废 从团队培养的角度来说 只有具有持续吸引力的团队 才是最稳固的团队 凝聚技术性人才的真正动力 在超越了收入这一层次的时候 技术素养的培养 更具有吸引力 这就必然要求技术部门的管理者要能够有一个相对长远的技术规划 一方面能够让 企业在技术手段上能够立于不败 另一方面能够使团队的每一个成员感受到吸引力和进步感 这样 既能够稳定技术结构 又能够稳定人员结构 我想 这也是技术部门是否能够留住一流技术人才 软件企业是否能够持续发展壮大的一个根本原因之一 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 三 项目后期 项目后期的要点 开发和测试要密切的配合开完成画面集成和测试 确保系统验收的成功 对各功能模块的功能 单元进行语句覆盖 分枝覆盖或其