软件项目管理——计划、跟踪、风险、协作利晓1Copyright ©2004, Worthy Tech, Inc.
议题z项目管理基本原则z风险管理z估算zWBSz如何制定有效的项目进度计划（MSProject使用）z挣值分析z如何跟进计划的执行情况z项目中的角色及协作2Copyright ©2006, Worthy Tech, Inc.
项目进度近期显得尤为严重？zGene Bylinsky(1967)“所有的的编程问题都变成了救火”zFred Brooks（神秘的人月，1975）“大多数项目因缺乏时间而导致的失败是其他原因的总和”3Copyright ©2006, Worthy Tech, Inc.
为什么要快速地开发？典型项目的开发过程：1.开发人员估算进度2.为了使客户和管理层高兴而将进度缩短50%3.开发组简化需求（由于无足够的时间）4.开发组简化设计（由于无足够的时间）5.开发组开始编码和测试4Copyright ©2006, Worthy Tech, Inc.
为什么要快速地开发？6.开发组增加特性（它们在简化的需求中遗漏了）¾项目开始延期7.代码变得混乱而低效（因设计问题）¾项目又延期8.开发组在混乱的代码中修改Bugs¾项目又延期5Copyright ©2006, Worthy Tech, Inc.
为什么要快速地开发？经过多轮回合后9.开发组提交了软件，但超过了预算并且功能比预想的要少。。。。。。接近了开发人员在第一步估算的进度6Copyright ©2006, Worthy Tech, Inc.
无效工作z平均项目花费40-80%的预算于未计划的返工（缺陷修改）－－这就是无效工作z“窍干而不苦干”是大家最终接受的想法。7Copyright ©2006, Worthy Tech, Inc.
项目中存在的问题200%以上延期6%取消101-200%延期29%16%51-100%延期9%21-50%延期8%按时20%延期26%6%8Copyright ©2006, Worthy Tech, Inc.
开发的策略快速开发的四个策略：z避免典型的错误（通过学习和总结）z使用开发的基础z管理风险z采用面向进度的实践9Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z人员相关的问题（1）¾挫伤积极性¾人员素质低¾对有问题的员工失控¾英雄主义¾项目的后期加入人员¾办公环境拥挤嘈杂¾开发人员与客户之间发生摩擦¾不现实的预期¾缺乏有效的项目支持10Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z人员相关的问题（2）¾缺乏各种角色的齐心协力¾缺乏用户的介入¾政治高于物质¾充满幻想11Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z过程相关的问题（1）¾过于乐观的计划¾缺乏足够的风险管理¾承包人导致的失败¾缺乏计划¾在压力下放弃计划¾在含糊的项目前期浪费时间¾前期活动不合要求¾设计低劣12Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z过程相关的问题（2）¾缺少质量保证措施¾缺少管理控制¾太早或过于频繁的集成¾项目估算时遗漏必要的任务¾追赶计划¾鲁莽编码13Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z产品相关的问题¾需求的镀金¾功能蔓延¾开发人员的镀金¾进度计划变更后又新增功能¾研究导向的开发14Copyright ©2006, Worthy Tech, Inc.
项目中存在的典型问题z技术相关的问题¾银弹综合症¾过高估计了新技术或方法带来的节省量¾项目中间切换工具¾缺乏自动的源代码控制手段15Copyright ©2006, Worthy Tech, Inc.
我们公司典型问题排序z列出部门和项目中的问题z避免重犯同样的错误z公司总结这些问题避免重犯16Copyright ©2006, Worthy Tech, Inc.
个性问题z项目类型1：产品升级＋项目实施z项目类型2：新产品开发＋项目实施z项目类型3：产品实施＋业务开发17Copyright ©2006, Worthy Tech, Inc.
共性问题z项目初期较难制定计划z计划较粗，难以进行跟踪和落实z资源无法落实、较难满足z原因：需求不清、变动大、较难细化18Copyright ©2006, Worthy Tech, Inc.
项目和产品的努力目标z按期z保质z预算内z满足用户需求19Copyright ©2006, Worthy Tech, Inc.
目前项目的困境z合同任务多z时间紧z预算少/合同额不足z资源不足z项目范围不清20Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z管理原则¾确定产品的规模（包括功能、复杂度和其他产品特性）¾根据产品规模分配资源¾制定资源计划¾监控、引导资源保持项目方向不会偏离21Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z管理基本活动¾项目估算和进程安排估算项目规模的大小估算完成项目需要付出的代价基于估算制定项目管理计划22Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z管理基本活动¾制定计划项目估算和时间进度确定项目需要的人数、技能、何时加入、具体人选确定项目组的运作方式确定项目采用的生命周期模型管理风险确定项目策略（如何控制项目和产品的特性、是否需要外购组件等）23Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z管理基本活动¾跟踪进度、费用和质量等目标的检查方式9任务列表9每周例会（进度报告会议）9项目状态报告（进展报告、预算报告）9里程碑评审9管理评审24Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z管理基本活动¾度量收集进度、费用和质量等数据分析：生产率、Bug率目的：有效地决策下一阶段的进度、费用和质量25Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z技术原则¾需求管理¾设计¾构建¾软件配置管理26Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z技术原则¾需求管理收集需求编写需求说明依此跟踪设计、编码和测试随时管理需求变更27Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z技术原则¾设计主要设计风格基础设计概念性能和特性设计特殊领域的专项设计架构设计设计工具的使用28Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z技术原则¾构建编码规范数据相关概念特定数据类型的使用原则控制相关的概念代码打包规则单元测试和调试原则集成策略代码优化策略和实践特定编程语言的约束使用构建工具29Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z技术原则¾配置管理评估变更跟踪变更控制版本备份成果30Copyright ©2006, Worthy Tech, Inc.
解决这些问题的基本原则z质量保证原则¾控制易错模块¾测试¾技术评审走查代码评审正式评审技术总结31Copyright ©2006, Worthy Tech, Inc.
风险管理z“如果你不主动攻击风险，他们就会攻击你.”-Tom Gilbz风险管理始终被看作坏消息，提出人始终受到打击.z然而, 风险是还仍未发生的问题; 关键是‘仍未’.32Copyright ©2006, Worthy Tech, Inc.
风险管理的等级1. 危机管理–救火式，风险已造成灾难后才处理2. 失败处理–风险一变成问题立即处理（事后）3. 风险缓解–定出补救措施，但无防范措施4. 着力预防–考虑风险防范、避免发生5. 消灭根源–识别和消除可能风险根源z要向第4,5等级努力33Copyright ©2006, Worthy Tech, Inc.
风险管理过程风险管理风险评估风险识别风险分析风险优先级排序风险控制风险策划风险解决风险监控34Copyright ©2006, Worthy Tech, Inc.
风险识别z生成项目特定的风险条款清单，它们多半会在以下方面影响项目的成功：-进度拖延-成本超支-需求不能满足-有大量的缺陷-可维护性差-其它·z进行风险识别一般采用：-组织风险数据库-会晤、会议、脑力风暴(brain storming)-过去项目的经验-可能风险的检查单35Copyright ©2006, Worthy Tech, Inc.
风险数据库z一个全部项目均可使用的中心风险数据库帮助会非常大风险过去项目过去措施计划EA02007 ，OA02002用户素质的改变培训替代OA02002操作系统稳定性安装SP5EA02006，EA02005需求不清晰开发原型、阶段提交用户介入较少36Copyright ©2006, Worthy Tech, Inc.
风险类别(Infosys)16缺乏经培训的技术人才不满足性能需求27太多的需求更改不现实的进度38需求不清晰面对新的技术49人力缩减经营知识不足510Link failure/slow 强加给项目的外部决定performance……37Copyright ©2006, Worthy Tech, Inc.
风险分析z帮助确定风险可能发生的概率和可能的损失程度z可能用定量的方法：-%概率或可能度-想像中（notional）成本z建议在开始时使用高、中等、低评定等级38Copyright ©2006, Worthy Tech, Inc.
风险分析风险概率影响关键设计者转到另外项目中高在验收前用户素质改变高中不可能得到领域专家作分析高高平台（编译器，OS）有大非常低高量错误有较多的技术难点高高人员连续性低于平均水平高中开发过程不合适非常低低39Copyright ©2006, Worthy Tech, Inc.
风险排序z将风险排序以识别必须控制的风险z使用概率等和影响信息风险概率影响(impact)次序关键设计者转到另外项目中高5在验收前用户素质改变高中4不可能得到领域专家作分高高2析平台（编译器，OS）有大非常低高6量错误高高1有较多的技术难点人员连续性低于平均水平高中3开发过程不合适非常低低740Copyright ©2006, Worthy Tech, Inc.
风险控制z通过以下方法帮助我们降低风险影响：-风险策划-风险解决-风险监控z对策划，选择排序最前面的几个风险41Copyright ©2006, Worthy Tech, Inc.
风险策划z躲避（Avoidance)-选择另一种作法，这可能抵消一些我们早期的得益也可能产生另外风险z降低概率-找出风险的原因和减少/消除该原因z为事件发生作好准备-早期用最小成本以减少事件发生时的影响z回避(Evade)-当以上措施成本太高或有风险时42Copyright ©2006, Worthy Tech, Inc.
风险解决和监控z按计划执行活动z定期按计划监控执行z风险的动态性-定期地重新评估风险的优先级-定期地识别新的风险或优先级上升的风险43Copyright ©2006, Worthy Tech, Inc.
典型的风险类z技术z开发群组的技能z开发人力的可用性与连续性z用户/顾客的技能z需求的清晰性z需求的稳定性z过程成熟度和稳定性z竞争z用户、开发者动态性能（两者的关系）z界面z政治44Copyright ©2006, Worthy Tech, Inc.
项目10大风险列表分组讨论45Copyright ©2006, Worthy Tech, Inc.
风险计划zWhat, when, how, who减小减小提解解可影可能影响责出决决能响优先性的力的任日期日#风险描述性力级措施措施人期限期12346Copyright ©2006, Worthy Tech, Inc.
风险小结z概念要清楚。风险的一种定义：风险是不利事件发生的不确定性。所以，首先必须清楚风险是可能事件，可能发生，可能不发生。现在的风险可能是以后的问题。不讨论必然事件。z开始起步时，不强调用数字，而用模糊术语：“高、低”等描述风险出现的可能和风险发生后的影响程度。评估风险的方法主要是“脑力风暴”，即开会讨论集思广益，这样易于起步。z注意风险数据的积累，这对今后风险评估与策划很有好处。47Copyright ©2006, Worthy Tech, Inc.
估算、WBS、详细进度48Copyright ©2006, Worthy Tech, Inc.
估算的理解z大多项目延期25-100%甚至200%z过程改进可提高估算的精确率5-10%z进度经常受限于项目的目标和需求z进度应该迭代的精化49Copyright ©2006, Worthy Tech, Inc.
估算需考虑的因素（1）z是否提供X功能？z我们是否需要X功能的简单或复杂版本？z提供X功能的简单版本客户是否会在以后改变主意？zX功能怎样设计？复杂度不同有±10%差别50Copyright ©2006, Worthy Tech, Inc.
估算需考虑的因素（2）zX功能的质量和可靠性级别是什么？（±10%）z修改X功能的Bug所花的时间？（±10%）z将X功能与其他功能集成所花的时间？（±10%）51Copyright ©2006, Worthy Tech, Inc.
估算的难点52Copyright ©2006, Worthy Tech, Inc.
估算的方法zFPA（功能点分析法）zDelphi估算方法z基于快速设计的估算方法zCOCOMO估算法53Copyright ©2006, Worthy Tech, Inc.
估算的步骤1.估算产品规模（代码行或功能点FPA）2.估算工作量（人月）3.估算进度4.在项目进行中精化估算54Copyright ©2006, Worthy Tech, Inc.
WBS：工作列表z定义了项目的安排和成本结构z目标是以结构化的方式唯一定义和跟踪已存在的活动，并为新的活动留出空间z按阶段划分活动并赋于唯一的编号55Copyright ©2006, Worthy Tech, Inc.
制定WBS注意事项z尽可能按时间顺序组织z包括与时间不太紧密的活动¾配置管理、文书支持、QA等z重复性的活动置于较高的层次z涵盖所有的技术开发活动z涵盖所有非技术的活动¾培训、会议、对外支持、沟通等56Copyright ©2006, Worthy Tech, Inc.
WBS检查清单z需要的资源（设备、工具、服务）z需要的技能（培训）z有明确的、可识别的里程碑清单z考虑时间、成本和预算z明确定义了项目的假设z明确了不在控制范围内的工作相关性z明确的任务的责任人z已经考虑了风险较高的领域57Copyright ©2006, Worthy Tech, Inc.
WBS讨论和示例分组讨论58Copyright ©2006, Worthy Tech, Inc.
进度计划z理想的进度是能反映良好定义的项目要求z实际进度计划受制于外部的影响，经常是一厢情愿z软件进度的问题已有30年的历史59Copyright ©2006, Worthy Tech, Inc.
案例一zWord for Windows ¾249,000 代码行; 原计划开发365天¾现实进度调整从460 到660 到780 天¾实际开发了1887 days (5 年!)60Copyright ©2006, Worthy Tech, Inc.
案例二z某产品开发项目¾原计划从2月中到4月中，需2个月¾调整到6月中，共需4个月¾调整到7月中，共需6个月¾调整到9月中，共需8个月¾……61Copyright ©2006, Worthy Tech, Inc.
案例三z某实施项目¾合同计划：从1月到中，需2个月¾估算计划：从1月到8月¾乐观计划：从1月到5月中¾实际计划：8月中验收未通过＋13天的修改¾……62Copyright ©2006, Worthy Tech, Inc.
延期原因探究z为了赶在特定时间展示或销售产品z管理人员和客户拒绝接受合理估算，而按照他们认为的“最佳”状况制定计划z为了享受挑战和压力的刺激故意缩短进度z为了迎合客户缩短计划z为了获得资金而违心地缩短进度z高层经理、市场部或重要的客户需要在特定的时间内完成，而项目组无法说服他们z进度估算本身不够充分63Copyright ©2006, Worthy Tech, Inc.
延期原因探究一厢情愿不能代替精心的策划！64Copyright ©2006, Worthy Tech, Inc.
乐观计划的后果z开发人员低估20-30%z不充分的策划z丧失原则执行计划z简化需求和设计阶段的工作z项目组只关注进度而放弃的其他的任务z造成客户关系紧张z仓促结束－未充分测试、文档化较少65Copyright ©2006, Worthy Tech, Inc.
超负荷的进度压力z40%的错误是因压力而生z赌博心理：未经测试的工具和技术z开发人员的激励下降z创造力下降z筋疲力尽－低生产率z较高的人员流失率z忽略了长期的目标z忽略了培训和提高z增加了经理和开发人员的紧张气氛－对抗66Copyright ©2006, Worthy Tech, Inc.
战胜进度压力z掌握有原则的谈判技巧－双赢z将人从困境中解脱z关注共同利益¾真正提高开发速度¾增加成功机会¾援引以前类似项目的失败教训z提出对双方均有利的备选方案z坚持客观标准¾谈判不要仅限于估算本身¾坚持由专业人员参与估算¾坚持科学的估算过程¾顶住压力67Copyright ©2006, Worthy Tech, Inc.
完成有效地进度计划z使用MS Projectz将WBS列入Project中z定出项目的主要里程碑z用完整的细节充实第一个里程碑z用能得到的信息充实剩下的里程碑z将计划详细到天68Copyright ©2006, Worthy Tech, Inc.
完成有效地进度计划z为每个任务指定确定的人（责任到人）z为任务和人员建立关联z分析计划与目标的差距z调整关键路径的资源z增加风险储备z项目组及相关人员审核计划z批准计划69Copyright ©2006, Worthy Tech, Inc.
责任到人1.有能力且希望做2.有能力且准备做3.有能力但不准备做4.通过培训或指导后有能力做5.没有能力70Copyright ©2006, Worthy Tech, Inc.
项目组及相关人员审核计划1.了解项目的目标和愿景2.工作量分配的合理性3.安排的任务完备性4.对分配任务的质量和要求达成共识71Copyright ©2006, Worthy Tech, Inc.
Project 使用分组讨论72Copyright ©2006, Worthy Tech, Inc.
Project使用步骤z创建WBSz创建摘要任务z时间管理¾输入任务工期摘要任务不输入工期里程碑任务工期，输入零工期周期性任务已明确时间的任务：直接输入开始和结束日期¾任务依赖关系¾识别关键任务¾关键路径分析¾资源日历z成本管理¾资源工作表：资源、单位成本¾为任务分配资源¾基准计划、实际成本和实际时间¾挣值分析73Copyright ©2006, Worthy Tech, Inc.
挣值分析z综合了范围、进度计划和资源，测量项目绩效的一种方法z比较了计划工作量、实际挣得多少与实际花费成本，以决定成本和进度绩效是否符合原定计划。z每个任务的成本特性：¾预算：计划工作的预算成本(PV、BCWS)¾实际成本：已完成工作实际成本(AC、ACWP)¾挣值：已完成工作预算成本(EV、BCWP)74Copyright ©2006, Worthy Tech, Inc.
挣值分析-术语2000术语96术语PVBCWS计划值应该完成多少工作计划工作预算成本Planed ValueBudgeted Cost of ？Work ScheduledEVBCWP挣值完成了多少预算工完成工作预算成本Earned ValueBudgeted Cost for 作？Work PerformedACACWP完成工作实际成本Actual 实际成本完成工作的成本是Actual CostCost of Work 多少？PerformedBACBAC完工预算全部工作的预算是Budget at 多少？CompletionEACEAC完工估算全部工作的成本将Estimate at 是多少？Completion75Copyright ©2006, Worthy Tech, Inc.
评价工作绩效z工作绩效好坏的尺度(>0)¾成本偏差（CV）=EV-AC¾进度偏差（SV）=EV-PV z效率指示器：工作项的成本与进度计划绩效(>1) ¾成本绩效指数（CPI）=EV/AC¾进度绩效指数（SPI）=EV/PV z完工估算（完成全部工作所需的成本）¾EAC=总预算/CPI or EAC=AC+(总预算-EV)/CPI 76Copyright ©2006, Worthy Tech, Inc.
挣值分析-举例z【例子】：某项目中的某可交付成果，成本总预算是13万元，要求10周内完成。该可交付成果包括3个工作包，成本预算分别是：工作包1：2万元；工作包2：10万元；工作包3：1万元77Copyright ©2006, Worthy Tech, Inc.
挣值分析-举例78Copyright ©2006, Worthy Tech, Inc.
挣值分析-举例zCV==-1 (CV<0,成本绩效差)SV=-11= (SV<0,进度绩效差)zCPI=EV/AC= ©2006, Worthy Tech, Inc.
挣值分析-举例80Copyright ©2006, Worthy Tech, Inc.
挣值分析-练习z一个12个月的项目，获得如下数据：¾PV(BCWS):23,000元¾EV(BCWP):20,000元¾AC(ACWP):25,000元¾BAC：120,000元z问题：¾1.成本偏差、进度偏差、成本绩效指数、进度绩效指数？¾2.项目进度的如何？进度提前还是落后？预算是否超出？¾3.估算完工的总成本(EAC)?比计划好或差？¾4.完工将花多长时间？81Copyright ©2006, Worthy Tech, Inc.
挣值分析-举例PVEVACBAC23,00020,00025,000120,000CVSVCPISPIEV-ACEV-PVEV/ACEV/PV-5,000-3,00080%87%EACEAS计划工期PSBAC/CPIPS/SPI12月150,月82Copyright ©2006, Worthy Tech, Inc.
如何跟进计划的执行情况83Copyright ©2006, Worthy Tech, Inc.
检查当天的工作1.根据计划检查完成情况2.检查应该开始的工作3.检查正在进行的工作可能出现的情况：z没有偏差z发现了可以修正的偏差z发现了无法修正的偏差84Copyright ©2006, Worthy Tech, Inc.
意外事件处理发现了可以修正的偏差，调整：1.功能性2.交付日期3.工作量（或成本）4.质量85Copyright ©2006, Worthy Tech, Inc.
意外事件处理发现了无法修正的偏差：1.等待：希望计划的预测较实际的长2.汇报：向上级或客户说明一切3.否则面临名誉扫地的威胁86Copyright ©2006, Worthy Tech, Inc.
告诉人们正在发生的事情状态报告（每周）1.上周计划完成情况2.本周的计划3.问题及偏差4.人员工作状况5.变更情况87Copyright ©2006, Worthy Tech, Inc.
项目经理的一周1.设定目标（周一）2.检查计划执行情况3.参加各类会议4.协调解决问题：•人员、客户、资金、设备•技术、质量、配置管理、过程、规范化5.调整计划6.完成项目状态报告（周五）88Copyright ©2006, Worthy Tech, Inc.
谢谢!
