软件项目管理的10项最佳实践

软件项目管理的10项最佳实践 实践演练 课程内容 1 未有项目之前 认识项目的相关方2 如何让项目计划更象 项目的 计划3 y f x 软件估算方法和估算技术4 Reconcile 估算与项目计划之间的关系5 实用就好 给项目选择生命周期模型 6 三位一体 度量在项目监控中的应用7 项目报告 到底需要写些什么呢8 关于风险 风险的描述 风险的持续跟踪和监控9 项目群和项目组合管理之一 管理些什么10 项目群和项目组合管理之二 百川归海 问题练习 1 项目与其它任务 操作的根本区别是什么 2 一个项目的最核心的相关方3 以下那项最不可能为项目的目标A利润B成本C进度D质量4 关于项目估算说法正确的是A估算1000功能点 就要完成1000项功能B高估的危害远远小于低估C软件规模与工作量之间是线型的关系D增加人力资源可以灵活调整项目进度 冷笑话 1 ProjectManagerisaPersonwhothinksninewomencandeliverababyinOnemonth 2 DeveloperisaPersonwhothinksitwilltake18monthstodeliveraBaby 3 OnsiteCoordinatorisonewhothinkssinglewomancandeliverninebabiesinonemonth 4 Clientistheonewhodoesn tknowwhyhewantsababy 5 MarketingManagerisapersonwhothinkshecandeliverababyevenifnomanandwomanareavailable 6 ResourceOptimizationTeamthinkstheydon tneedamanorwoman they llproduceachildwithzeroresources 7 DocumentationTeamthinkstheydon tcarewhetherthechildisdelivered they lljustdocument9months 8 QualityAuditoristhepersonwhoisneverhappywiththePROCESStoproduceababy 9 TesterisapersonwhoalwaystellshiswifethatthisisnottheRightbaby 10 HRisapersonwhothinksthatadonkeycandeliverahumanbabyifgiven9months 问题练习 5 评审项目计划的目标 A执行性B资源平衡C一致的理解和承诺D项目成员熟悉6 以下哪项是质量保证范畴A单元测试B集成测试结果分析 识别缺陷 更新测试用例 规避重复问题C测试人员参与需求文档评审 保证需求文档可测性D计划明确 深入回归测试7 编码进度延迟20 是什么原因造成的A工作量投入不足B工作量估算偏小C工作产品质量差 返工D以上答案都不正确8 工作任务书 SOW 多选A技术需求B项目交付件C项目目标D项目的验收标准 问题练习 9 以下风险说法正确的是 多选 A风险只在计划时进行中识别与分析B时间窗不影响风险优先级别判断 但会影响风险的规避措施与应急计划的制度C每一风险都要制定规避措施与应急计划D风险的规避措施和 或应急计划需要纳入项目的WBS中作为一项任务统一监控10 分析和审核中 裁剪正确的 多选 A关键过程不可裁剪B由项目经理确认C经常被裁剪是无效的 可以废弃D新定义是否检验 调查数据 FromStandish2010 Isitmyself 1个失败的项目典型的生命周期 Stage1 Exciting兴高采烈阶段启动计划Stage2 Disenchantment恍然大悟阶段执行监控Stage3 SearchfortheGuilty寻找罪证阶段执行监控Stage4 PunishmentoftheInnocent惩罚无辜阶段控制关闭Stage5 Nothingbutdustandearth 尘与土阶段 魔鬼数字 1发布之后缺陷修改成本是设计时40 1000倍2压缩进度最多只能25 不可更高3开发和维护成本与代码行成正比4软件工具只能对效率和质量提高5 35 5编码工作量最好不超过15 但一般比较好的公司20 25 6需求开发工作量至少12 7重要组件若25 以上需要重新修改 则应重新开发更好8检视 走读 同行评审可以发现60 以上的缺陷9亚太1500多个IT企业调查 返工的成本达61 10软件开发之营业务组织而言 维护12 左右 魔鬼数字 11员工离职不到40 是因为待遇问题12工作环境对工作效率影响Top25 团队 最后25 团队 2 6前者的工作空间是后者的1 7倍13问题复杂25 解决就花100 14二八原则80 的软件成本是由20 的构件80 的错误是由20 的构件引起的80 的资源 执行时间 磁盘空间和内存 是由20 的构件消耗的80 的进展是由20 的人来完成的 项目5大过程 启动过程 策划过程 监控过程 执行过程 关闭过程 项目机会收集初步分析与筛选分配资源以启动项目需求开发可行性分析立项决策评审 No 1未有项目之前 一如何认识项目的相关方 认识相关方 识别相关方 识别他们的期望值 Stakeholders相关方CustomersManagers经理Users普通用户Favored感兴趣的Disfavored不感兴趣的Ignored可以忽略的IT InfrastructureITIT人员InterfacingSoftware Systems Devicesandtheirowners相关的系统 设备以及他们的责任人当心 当 用户 与 客户 不是同一拨人的时候 人 项目的主角 Stakeholders相关方 干系人对项目执行结果负责或受项目执行结果影响的小组或个人 可以是 项目组成员 供应商 客户 最终用户以及PMO 质量管理等支持部门RelevantStakeholder利益相关人是指在项目计划中指定参与具体活动的干系人 认识相关方 识别相关方 识别他们的期望值 UserClases用户分类Frequencywithwhichtheyusetheproduct根据使用频度Applicationdomainexperience根据业务领域知识Computeruseexperience根据用户体验Accessprivilegeorsecuritylevel根据使用权限Userlevel PreliminaryorPowerUser根据用户等级 相关方和项目启动阶段的关系 认识项目的相关方是项目启动阶段的最重要任务 对项目的成败影响很大 赞助人 PM 项目团队 相关方 重要性 ACase PAS 无线个人接入系统 VS 依星 系统 启动阶段决定了我们是否做了正确的事情 如果做了错误的事情 后面做得在好也是徒劳 认识相关方 的一般流程 1 识别项目的相关方2 考查各个相关方对于本项目的期望 要求和 或约束2 1 制定一份待考察问题提纲 列表2 2 为不同的相关方制定不同的考查方式 访谈 调查问卷 原形演示 业务逻辑捕捉 观察工作习惯 用户深度参与的workshop 等2 3 根据上述制定需求开发计划 分配资源并实施之3 将考察结果文档化以备用 Caution 如果您的公司是产品开发类型的 最关键的文档 产品版本路标规划所包含的内容产品的愿景产品分析市场分析竞争对手分析技术分析产品策略市场策略技术发展策略产品的演进路标版本路标计划X y版本的特性列表w z版本的特性列表n m版本的特性列表 技术为业务服务业务为战略服务 研发模式的跨越式变革 研发模式 从 客户要什么 我们做什么 应激性开发模式转变成为具备规划能力的前瞻性开发模式世上最难的两件事情 一是把别人兜里的钱掏出来放自己兜里 二是把自己的的思想放到别人的脑袋里 产品规划被要求同时具备这两项质素 客户要什么我们做什么 我们说服客户 你需要这个 我们为客户规划好 你需要这个 基于相关方的期望值确认项目的可行性分析 理解项目的复杂度技术可行性业务可行性管理可行性精细化项目的所有目标必须要规格化的文档来表达初步评估工作量 进度要求 成本预算以及其他风险可以包含概念性开发 内部原型开发等工作以使决策更有依据关于成本预算 开发成本 维护成本 销售成本与机会成本综合上述所有要素可行性分析报告 可行性分析要素 技术 经济 社会环境 人 可行性分析 沙盘演练1 请定义 根据你的项目场景 分析项目的相关方 并根据此制定1份需求开发计划 明确 1 1项目有哪些相关方 1 2定义向每一个相关方考查的问题重点为 维度 1 3确定考查方式要求 3 1在30分钟小组讨论和完成任务 3 2在5分钟的时间分享结果 项目5大过程 启动过程 策划过程 监控过程 执行过程 关闭过程 调整目标选择生命周期模型制定项目过程制定项目计划计划评审项目开工会 No 2如何让项目的计划更象 项目的 计划 首先 项目的4大要素 Good Fast Cheap pickanytwo Scope Schedule Cost Quality Scope Quality Schedule Cost范围 质量 成本与进度 什么东东会成为项目的目标 每一个项目至少会有4个主要的目标范围 创造某些东西 产品 服务 过程 成本 在某一个确定的预算结构内完成进度 在某一个获得认可的进度内完成质量 完成后被验收时候所应满足的条件和标准BrainStorming 4大目标中为什么没有 利润 除了这4个主要的目的 还可能包含有其他的目标培养人才拓展客户关系构建可供重用模式 平台 构件 设置项目目标时的原则 目标必须满足 Specific有针对性的Measurable可测量的Ambitious有挑战性的Realistic可实现的Time bound有时效的 而且还要有清晰的职责分析 识别项目目标的方法 BSC因果关系图 Financials财务 Customers客户 BusinessProcesses客户 Learning Growth学习成长People Systems Technology Vision Strategy 识别项目目标的方法 1 为了使相关满意 我们必须达到的财务指标是什么 2 为了达成财务指标 应该满足客户的哪些需求 3 为了能够满足客户及相关方的需求 我们需要优化哪些业务流程 4 为了能够达成上述所有的目标 我们需要从人员上和技术上学习什么 创新什么 从项目的业务目标出发 带着相关方的眼睛 从业务目标出发方向度量指标的分解 示意 带着相关方的眼睛 重要 战略 不是形而上的 而是与每个人的日常活动息息相关的 财务指标 满足客户需求 业务流程优化 人员的学习与成长 VisionandStrategy愿景与战略 沙盘演练2 继续上一个演练的结果 根据项目已经确定的相关方 定义 1 1项目的关键成功目标 1 2项目的关键成功要素与行动项 要求 3 1在30分钟小组讨论和完成任务 3 2在5分钟的时间分享结果 No 3y f x 软件估算方法和估算技术 估算 估算的了解估算的目的 一定是为了估得越准确越好吗 WhatisEstimate Estimation Estimate估算 Tocalculateapproximately theamount extent size position orvalueofsomething 近似的计算 事物的数量 程度 规模 位置与价值 Toformanopinionabout evaluate为形成意见和 或评价 EnglishDictionaryEstimation估算 Theactoraninstanceofestimating估算的活动 实例Theamount extent position size orvaluereachedinanestimate估算出的数量 程度 规模 位置与价值Anoptionorajudgement意见或者判断 第一步 关于规模的估算 规模反映工作产品的数量属性 Sizeisthevolumeofwork 例子如下集成电路逻辑门数量软件代码行功能点系统工程需求的数量与复杂度估算规模的目的规模是估算工作量和进度的主要输入如果没有规模很难估算出令人信服的工作量和定制合理的计划不清楚项目和组织的生产率不清楚过程是否有效 为什么不宜直接从工作量的估算开始 规模工作产品数量的多少是客观的 不论什么样的人去做其数值不会变化工作量衡量了投入到工作中的人力耗费 工作量的大小不仅与规模相关 而且与人的技能 所采用的过程 工具等都相关 规模的估算方法之间 FPA 功能点分析 功能点分析 FPA 是衡量软件规模的一个标准方法 应用在基于客户观点的商业应用软件开发与提升项目上功能点属于软件规模的间接量测项 是根据应用系统的外部与内部特性 以及应用系统的性能来估计的 功能点在确立之后 可以输入到统计参数式软件成本估计方程式及模型中 以估计软件的成本功能点被认为最适于管理信息系统 MIS 与数据库开发等应用软件系统规模的估计与度量功能点与计算机程序语言 开发方法论 技术或项目团队能力无关 FPA过程 识别数据功能及判断复杂性 需求规格 识别交易功能及判断复杂性 FPC 计算未经调整的功能点数 为14个通用系统特性 GSC 评等 计算数值调整因子 VAF 计算功能点计数 FPA 数据功能点 内部逻辑文件 ILF 数据功能点 外部接口文件 ETF 内部逻辑文件 ILF 是一群可被使用者识别 逻辑上相关 在应用软件边界内维护 以及过程外部输入维护的数据外部接口文件 EIF 是一群可被告使用者识别 逻辑上相关 在应用软件边界维护的资料ILF EIF的功能点数量取决于下列两种数据的数目 DataElementTypes DETS 数据基础类型用户可见的字段RecordElmentTypes RETS 记录基础类型用户可见的由DET组成的子组 数据功能点 外部输入 EI 交易功能点 外部输出 EO 交易功能点表示系统为用户提供的用来处理数据的功能 外部查询 EQ 工作量的估算 COCOMO ConstructiveCostModel 构造性成本模型 是一种精确的 易于使用的基于模型的成本估算方法COCOMOIICOCOMO81UniversityofSothernCalifornia 其他的企业级估算模型 A公司实例 WebPage估算模型B公司实例 eWU模型 No 4Reconcile 估算与项目计划之间的关系 EstimationorSomethingElse 我们要准备好2 1版本 以便于在5月份的展览会上进行演示 我们一定要在下周做好这个版本的发布准备 这是政治任务 必须要在7月1日以前完成这些功能 以便于满足节假日销售季节的需要 我们必须要将下一版本的成本控制在200万元人民币以内 因为可以提供的最大预算额度只有这么多 如果估算知识采用非定量方法获得的 主要是一群管理人员认定而几乎没有什么数据支持 就很难为它做出有力的 可信的辩护 FredBrooks Estimation GoalandCommitment 目标描述的是期望达到的业务目的 期望达到某个目标 或者某个目标是强制性的 并不意味着它是可以达到的 承诺 Commitment 是许诺在特定的日期之内以特定的质量水平交付规定的功能承诺可以与估算相同 可能比估算更激进 也可能比估算更保守不要假定承诺必须与估算是一样的 它们可以互不相同最终呈现在计划里的 既不是纯粹主观的目标 也不是纯粹客观的估算 而是二者的平衡 承诺 Estimation GoalandCommitment ACase主管 你认为这个项目需要多长时间 我们要在3个月之内为展览会准备好这个软件 我不能给你更多的人手 你必须依靠现有的资源来完成工作 这时我们需要的功能特性清单 FeaturesList 项目负责人 好的 我先去做一下估算 4小时以后 项目负责人 我们估算这个项目需要5个月主管 5个月 你刚才没有听清我说得吗 我说的是要在3个月之内为展览会准备好这个软件 Somedoubts是交付100 的功能更重要 还是为展览会准备好一些东西更重要 如果一旦发现无法在展览会之前交付所有的特性 是应该准备好在展览会时交付已经完成的部分 还是把交付的日期推迟到展览会之后 Features有没有优先级 所以 3个月 是目标 还是估算 当某人要求你提供估算值的时候 要确定他是期望你进行估算还是期望你给出如何达到某个目标的计划 结论 估算和计划的关系 估算不是计划 计划也不是估算估算要客观 不能受目标左右计划是 客观的估算 与 主观的目标 之间的平衡 是基于估算如何达成项目目标的过程 是一系列 承诺 的集合如果估算与目标差距较大 计划中要考虑可行的方式减小或消除差距思考 如果在工作任务书中规定3个月完成项目 而估算之后发现要6个月才能完成 这时如何处理 工作任务书 工作任务书 制定项目计划 调整项目目标 项目计划过程是一个negotiation和balance的过程思考 项目四要素时间 成本 范围 质量哪个灵活性更大 质量 成本 时间 范围 ConeofUncertainty不确定性锥 开始的时候 很多不确定因素结束的时候 很少啦在进展过程当中 我们可通过不断的学习来改善项目的管理 FunctionalSize Uncertaintyin Staff Effort Cost Uncertaintyin NominalValues ConeofUncertainty不确定性锥 4 0 x 0 25x 估算偏差范围 计划 需求 概要设计 详细设计 重估算与重计划成 重估算 重计划贯穿项目生命周期始终根据重估算的结果调整项目计划是实施有效的 主动的项目管理 项目Project 资源未按计划就位 删剪需求 删剪不稳定的功能 增加需求 人员比预想的更加缺乏能力 部分资源转向支持其它项目 增加更多的需求 估算结果 20人月 实际结果 20人月 Re estimateandRe plan 重估算 重计划时需要额外考虑的因素新的需求 或者对原有需求的新的理解项目已经消耗的成本 工作量 进度新的解决方案 设计 例如 重用的使用新识别出的风险其他 项目的成功 计划 执行 No 5实用就好 给项目选择生命周期模型 毕竟 生命周期模型 Lifecycle 拿来用的 不是炫的 定义项目的lifecycle 选择项目生命周期模型瀑布模型增量模型迭代模型螺旋模型V模型 瀑布模型 需求 设计 构建 测试 实施 运行和维护 具有迭代的瀑布模型 需求 设计 构建 测试 实施 运行和维护 V模型 原型生命周期模型 最初的需求收集 快速设计 原型开发 原型评估 精炼需求 增量模型 需求分析 概要设计 详细设计 构建 测试 直到需求完全得到满足 战略规划 轮次1 轮次2 需求分析 概要设计 详细设计 构建 测试 快速应用开发RAD模型 需求计划 用户设计 详细设计 构建 Cut over 应用1 应用2 应用3 需求计划 用户设计 详细设计 构建 Cut over 需求计划 用户设计 详细设计 构建 Cut over RUP迭代模型 螺旋模型 沙盘演练3 给您的项目选择合适的lifecycle 并且综合运用前两个演练的结果 制定您的项目的WBS workbreakdownstructure 工作任务分解结构 小贴士 1 时间点和责任人可以暂时空缺 2 WBS应该同时包含 规定动作 和 自选动作 3 要求 1 30分钟小组讨论和完成任务2 5分钟的时间分享成果 No 6三位一体 度量在项目监控中的应用 思考 进度延期了50 如果想分析一下根源需要看哪些数据 规模 需求稳定度 工作量投入 进度延期 注意 采集数据的唯一目的是为了分析以及获取行动的依据无论数据代表什么或者如何表现 都必须使用某种方法来提取和 或解释隐藏在数据中的信息解释清楚数据的意义 这本身就是一个过程 过程分析 分析数据的唯一目的是为了采取相应的行动 分析 数据 行动方案 输入 过程 输出 三位一体 定义过程 控制过程 度量过程 改进过程 执行过程 No 7项目报告 到底需要写些什么呢 为什么要报告 项目干系人特别是关键干系人需要及时而又准确的了解项目状况项目组需要及时而又准确的想关系人提出反馈 IknowyoubelieveyouunderstoodwhatyouthinkIsaid butIannotsureyourealizethatwhatyouheardisnotwhatImeant 赞助人 PM 项目团队 干系人 项目的可视性 In Out 计划 报告 黑盒子项目 透明盒项目 In Out 报告内容 当前工作进展问题风险Sowhat 后续计划 案例分享 反面典型正面典型 沙盘演练4 综合运用前三个演练的结果 定义您的项目需要哪些度量项和度量数据以反提高项目的可视性 小贴士 可以参考我给出的模版 要求 45分钟小组讨论和完成任务 5分钟的时间分享结果 No 8关于风险 风险的描述 风险的持续跟踪和监控 风险的描述 Includes 描述造成损失的条件描述造成的损失或导致的后果例如 不完整的描述 A项目组将MySystem系统的web应用部分设计与开发部分 为了节省工作量 保证进度 图形界面功能直接使用开源的图形显示组件 使用开源组件有风险 质量没有保证 风险的完整描述 完整的描述 风险的基本情况描述 项目组将MySystem系统的web应用部分设计与开发部分 为了节省工作量 保证进度 图形界面功能直接使用开源的图形显示组件 发生条件 由于开源组件在商业上没有保证 在系统大数据量传输的条件下运行时可能存在稳定性的风险 可能造成的危害 故障 后果 图形无法显示 图形界面显示为乱码 图形显示缓慢并进而影响整个系统的运行效率 如果不加人为的干预 还会造成死机 扩展 在正常数据量的情况下 由于我们不清楚该组件是否做过兼容性测试 在不同的软件平台 操作系统与浏览器 上运行的时候可能会出现错行 错位的情况 风险的完整描述 cont 正样的描述 够详细了吗 怎样界定 大数据量 怎样定义 正常情况 正常情况 TPS TransactionsPerSecond 每TPS的计算方法为 50个浏览 30个登录和20个定购 在1秒钟内并发 数量小于等于100 大数据量 TPS达到正常情况的10倍或10倍以上 风险or问题 在进度方面存在风险与客户之前协调和沟通不畅GUI可能无法同其他系统兼容由于缺乏CSM工具 可能会导致跨多个时间段变更出错只有一个项目组成员熟悉原型生命周期方法有项目组成员辞职 这很不利于项目组士气我们已经提交给客户一个没有BUG的产品 我们的质量目标可能没有满足 但是每个人都认为确保产品质量是SQA的工作已经有许多意料之外的需求优化 我们不可能按时交付产品 风险的持续监控 案例共享 Tips 风险管理也是花费成本的 1 设施成本 例如 建立培训体系 购买工具 2 风险管理成本 例如 文档化新风险以及撰写风险状态报告所需的工作量 3 规避成本 例如 执行规避计划花费的成本 2 对适当的风险进行处理 直到他们完全被解决或变成问题3 作为一个有机整体 风险管理是软件项目管理的一部分4 风险可以作为项目计划的一部分 也可以单独进行维护5 风险存在于项目组的整个生命周期6 风险应当被持续评估并用于决策过程有效实施风险管理的要素 1 远见 或长远的观点 共同的源景和全局观 2 集成管理 团队合作 持续跟踪和公开交流 沙盘演练5 识别本项目TOP3的3项风险 并为它们制定规避措施和 或应急计划 要求 30分钟小组讨论和完成任务 5分钟的时间分享结果 No 9项目群和项目组合管理之1 管理些什么 人力资源协调与管理 有足够的人力做吗 IPD中的概念 管道管理请问 下面哪个人力资源占用情况更合理 有合适的人力做吗 人力占用率 A 时间 B IPD产品研发过程 以市场和客户需求作为产品开发的驱动力 将产品开发作为一项投资来管理 No 10项目群和项目组合管理之2 百川归海 归档技术资料 归档过程资产 我的观察 任何一