对软件研发项目管理的深入探讨模板

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