软件项目工作量评估方法

工作量评估 1概述 我们认真地阅读了软件的相关需求文档和设计文档后，对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。工作量推算后组织主要项目干系人和相关专家进行工作量评审。 2常见的估算方法 2.1Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。  这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2.2开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试, 5-7%给组件和集成测试,18-20%给系统测试, 10%给接收测试（或回归测试等） 2.4类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据： 在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，功能点， 数据样式，例如实体，字段的数量, 屏幕或字段数量,测试对象的规模，例如KLOC 2.5 WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。 2.6 Delphi法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。 Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6， 直到达到一个最低和最高估计的一致。 2.7 PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E， 和标准偏差SD 3.估算前准备 针对以上方法，我司综合了以上多种评估方法，总结出了适合我司的评估方法： 1）对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素。 2）尽量寻找和本项目相近项目做参考，参考历史相近项目的实际工作量和项目进度情况。 3）尽量邀请有历史经验或者对项目熟悉的专家，参与项目工作量的评估，以提高工作量评估的有效性。 4）整理工作任务的关系和客户需求的优先级，寻找项目任务的关键路径，以保证项目周期的合理性和周期最短。 5） 确定项目评估工作的基线，以一名2年工作经验的开发人员为评估对象，选择了一个有10个字段的比较有代表性的业务表单，从开始到结束，精确统计了每个步骤需要的消耗的工时数。采用四舍五入法最终制作了如下的工时估算表： 6）确定技能系数，由于标准工时是按2年经验的工程师能力为基准，所以需要那工程师能力设置能力系数，工作3到6年的工程师，每增加1年工作经验则工时=标准工时*(1-0.1),6年以上一般按6年算。 终端开发标准工时（单位：小时） 说明：本表针对10个字段的界面进行估算 查询功能 添加功能 编辑功能 删除功能 界面（布局、美化、验证） 2 2 2 代码（业务逻辑、接口调试） 4 4 4 2 用户体验（界面适配、加载） 2 2 2 上传（多文件） 1 4 1 下载 2 第三方登录 6 地图集成（特殊功能另计） 2 分享 4 消息推送 2 每增加10个字段 增加50%工时 单元测试 按开发工时的30%估算           3.1 WBS分解原则 3.1.1 WBS的定义 WBS（工作分解结构）是Work Breakdown Structure的英文缩写，是项目管理重要的专业术语之一。WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。WBS总是处于过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。 WBS是由3个关键元素构成的名词：工作（work)--可以产生有形结果的工作任务；分解(breakdown)--是一种逐步细分和分类的层级结构；结构(structure)--按照一定的模式组织各部分。根据这些概念，WBS有相应的构成因子与其对应： （１）结构化编码 编码是最显著和最关键的WBS构成因子，首先编码用于将WBS彻底的结构化。通过编码体系，我们可以很容易识别WBS元素的层级关系、分组类别和特性。并且由于近代计算机技术的发展，编码实际上使WBS信息与组织结构信息、成本数据、进度数据、信息、产品数据、报告信息等紧密地联系起来。 （２）工作包 工作包（work package）是WBS的最底层元素，一般的工作包是最小的“可交付成果”，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如：管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动；包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本；过程中产生的报告/检验结果等等文档；以及被分配的工班组等责任包干信息等等。正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的基础。基于上述观点，一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。 （３）WBS元素 WBS元素实际上就是WBS结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关，必须面向最终产品或可交付成果的，因此WBS元素更适于描述输出产品的名词组成（effictive WBS，Gregory T. Haugan）。其中的道理很明显，不同组织、文化等为完成同一工作所使用的方法、程序和资源不同，但是他们的结果必须相同，必须满足规定的要求。只有抓住最核心的可交付结果才能最有效的控制和管理项目；另一方面，只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。工作包是最底层的WBS元素。 （４）WBS字典 管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与者（如承包商）接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。 3.1.2 WBS的主要用途 WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。 ● WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。 ● WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。 ● WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。 ● WBS防止遗漏项目的可交付成果。 ● WBS帮助项目经理关注项目目标和澄清职责。 ● WBS建立可视化的项目可交付成果，以便估算工作量和分配工作。 ● WBS帮助改进时间、成本和资源估计的准确度。 ● WBS帮助项目团队的建立和获得项目人员的承诺。 ● WBS为绩效测量和项目控制定义一个基准。 ● WBS辅助沟通清晰的工作责任。 ● WBS为其他项目计划的制定建立框架。 ● WBS帮助分析项目的最初风险。 3.1.3WBS的创建方法 创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。WBS的创建方法主要有以下两种： ● 类比方法。参考类似项目的WBS创建新项目的WBS。 ● 自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。 创建WBS时需要满足以下几点基本要求： ● 某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。 ● WBS中某项任务的内容是其下所有WBS项的总和。 ● 一个WBS项只能由一个人负责，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。 ● WBS必须与实际工作中的执行方式一致。 ● 应让项目团队成员积极参与创建WBS，以确保WBS的一致性。 ● 每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。 ● WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。 ● WBS的工作包的定义不超过40小时，建议在4-8小时。 ● WBS的层次不超过10层，建议在4-6层。 3.1.4WBS的表示方式 WBS可以由树形的层次结构图或者行首缩进的表格表示。在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中，具体的模版样式参见WBS模版样式。 3.1.5 WBS的分解方式 WBS的分解可以采用以下三种方式进行： ● 按产品的物理结构分解。 ● 按产品或项目的功能分解。 ● 按照实施过程分解。 3.1.6 项目组内创建WBS的过程 项目组内创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的部门主任都必须考虑该项目的所有方面。 项目组内创建WBS的过程是： ● 得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。 ● 召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。 ● 分解项目工作。如果有现成的模板，应该尽量利用。 ● 画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。 ● 将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预 算、分配负责人员或组织单位。 ● 验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。 ● 建立一个编号系统。 ● 随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。 3.1.7 WBS的检验标准 检验WBS是否定义完全、项目的所有任务是否都被完全分解主要依据以下标准： ● 每个任务的状态和完成情况是可以量化的。 ● 明确定义了每个任务的开始和结束。 ● 每个任务都有一个可交付成果。 ● 工期易于估算且在可接受期限内。 ● 容易估算成本。 ● 各项任务是独立的。 3.1.8 WBS的使用 对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。 3.1.9WBS的实践经验 最多使用20个层次，多于20层是过度的。对于一些较小的项目4－6层一般就足够了。 WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。 编辑本段WBS推广模式 W：即Web网站，企业用于在互联网上展示自身形象和产品宣传的一个平台，凭借网站企业可以让互联网上更多的用户和浏览者了解和认识企业，以便达到更好的宣传，主要面向客户、业界人士或者普通浏览者，以介绍企业的基本资料、帮助树立企业形象为主；也可以适当提供行业内的新闻或者知识信息。这种类型网站通常也被形象的比喻为企业的"WEB Catalog"。是每一个外贸公司对外贸易不可缺少的形象代言。 B：即B2B电子商务平台，主要面向供应商、客户或者企业产品（服务）的消费群体，以提供某种直属于企业业务范围的服务或交易、或者为业务服务的服务或者交易为主；中国最权威的互联网信息中心统计，目前有20%左右的企业已经意识到电子商务的重要性，其中2007年做推广的企业有80%左右的都是通过B2B推广的。Alibaba、Tradett、GlobalSource、Made-in-China、Tradekey、ECVV、EC21、Worldbid等国际知名B2B是大多企业主要推广平台。 对于外贸来说,B2B是一个强有力的工具,毕竞并不是所有的人都能碰到一个能让你参加广交会,参加法兰克福展的老板或公司的. 那么, 使用/利用B2B就将是公司动作过程中一个很重要的部分。 S：即SEO，搜索引擎优化，为近年来较为流行的网络营销方式，企业网站经过特定的方式进行SEO之后，可以增加特定关键字的曝光率以增加网站的能见度，提高企业网站在搜索引擎中的排名，从而提高网站访问量，最终提升网站的销售能力或宣传能力的技术。 3.2 deadline的使用 Deadline是在期限，软件领域deadline的概念就是从传统的印刷媒体中得来。然而，不能仅因为目前在软件领域尚无通用的deadline概念，就以为该摒弃这个概念，或以为它没有价值。 就工作的规划和并行处理来说，deadline是极其重要的。如果没有预计的完工期限，所有团队都必须连轴工作，同时也会大大减少交付次数。而且如果不明白deadline的真正含义，那么deadline可能会让人感到沮丧，甚至产生相反的效果。 问题及解决 以下是根据我司的经验总结出来的，在公司中与deadline最为相关的问题，以及最有可能解决问题的办法。 1）对deadline的理解因人而异 A：“下周才是deadline，我还有大把的闲余时间！” B：“为什么要担心这个？没关系的，deadline什么的当不得真。” A：“但我不想被炒鱿鱼啊！” 这组对话就很形象地展示了对同一个deadline，A和B两人在理解上有着巨大的差异，这也会导致整个团队在努力实现deadline时出现困惑与挫败感。 事实上，deadline必须要有号召力，每个人都得知道deadline重要的原因，他们必须明白错过deadline会对整个圈子有什么样的影响，包括对其他团队的、对客户的或者对公司整体的影响。 更重要的是，那些达成的deadline需要热烈的庆祝，而这一点常被忽视掉。比起责备那些错过deadline的员工，建立起为达成deadline庆祝的企业文化才是上上之策。 2）在项目的生命周期中过早设定deadline 向一个各方面都属于未知状态的项目要求一个deadline简直后患无穷，也让项目涉及到的员工压力很大，为项目立起了失败flag。所以，先深呼吸，耐心等两天，让大家完成探索工作。虽然搜集信息花费了时间，但之后我们却能给出有意义的评估，这些信息会帮助我们设定更加准确的deadline。 3）deadline更新频度不够 在新问题出现时，开发人员并未调整或重新评估deadline，某个开发人员没能立即提出问题，而是等到deadline才告知他人，于是其他开发人员也受此牵连，而整个团队也会因为要赶工另一个deadline而倍感压力。 设定deadline不应当是为了强迫员工超额负荷，把人当牲口用，而应用以设定外部对项目的预期，让计划呈现可预期性。Deadline必须尽可能准确地反映现实情况，否则一旦出现信任危机，这个概念也就失去了传递可预期性的功能。当然，我不提倡每小时或每天更新deadline的行为，但也许每周更新，或至少按标准计划的节奏来更新是个不错的主意。 更新deadline并不拘于延长时间，也可以缩短周期。至于具体怎么做，又或者兼而有之，都得工程师和产品团队商榷后确定。 4）未将所有“已知工作”都纳入考虑范围，仅考虑到了有趣的那些 在设定这个deadline时，相关人员对要完成的工作以及要投入的时间缺乏完整的理解。 在设定deadline时，我们应当确保将所有已知的挑战都涵盖在内，是否会因某个已知原因而浪费一些时间，比如说度假、公司断网、因为生日派对宿醉而迟到. 另外我们是否可能遗忘了某些不起眼的任务？这个项目打算写多少测试？如何将这玩意儿发布到生产环境中？跟着这些问题放慢脚步，仔细思考下整个过程以及可用的资源。这样做会让设定deadline简单得多，同时这样设定出的deadline也更经得起考验。 关于评估：令人不适，但却是必要的 工程师所设定的deadline很大程度上是通过评估形成的，也就是说团队中的每个人都要习惯犯错，犯很多错——将自己知道不对或是没信息的地方说出来，可能会很困难。 我们必须达成共识，尽可能准确地作出评估，并随着时间评估地越来越准确。评估是一项技能，反复使用会熟能生巧。初期可能会让人不适，但这是我们需要做到的。 评估任务 在定下大型项目的交付时间前，我们应当将整个项目拆分成小的任务，每个任务应当能在约五个工作日内完成。 以下问题对评估任务十分有用： ● 这个项目是新建的，还是之前就有的？ ● 这部分代码质量如何？ ● 我对这部分代码的熟悉程度如何？ ● 对涉及的编程语言熟悉程度如何？ ● 与其他代码段在哪里有接触或集成点？ ● 现有的测试覆盖率如何？ ● 这项工作是否涉及关键业务（写入路径、计费、负载均衡器、注册）？ ● 之前是否有人参与过这项工作？他们有何想法？ ● 有哪些问题需要做出权衡？ ● 这项任务的目标是什么？ ● 这项任务究竟是否需要完成？ 评估工程项目 工程项目通常被视为一个较大的任务，可以让多人并行完成。 下面这些问题有助于评估项目： ● 我们实际要在这个项目上花费多久时间？ ● 这个工程项目的目标是什么？ ● 是否有已知会安排的休息时间？ ● 所有要完成的任务有哪些？ ● 是否对其他团队有依赖，还是障碍性的？ ● 项目中是否有任务对其它任务产生障碍？ ● 该项目是否需要新的基础设施或硬件？ ● 该项目的完工标准是什么？ 完工标准 即便要知道某项工作是否完工都是很困难的，团队中不同角色可能会有不同的“完工”标准，因此我们需要指定某个项目的具体完工标准。 下面是典型完工标准的一些样例： ● 部署到生产环境； ● 全自动化测试； ● 与公司内部或第三方人员沟通； ● 在公司内部或外部进行了一定量的测试； ● 为生产环境编制文档； ● 完成对销售或推广团队的讲解； ● 发布登录页面； ● 分析并追踪； ● 操作运行手册与系统可观测性。 3.3需求变更管理 变更是无法避免的，作为一个合格的项目经理，我们应该有有效的方法来管理项目变更。 当项目的某些基准发生变化时，项目的质量、成本和范围等随之发生变化，为了保证项目目标实现，就必须对项目发生的各种变化采取必要的应变措施，这种行为就是项目变更。 项目变更产生的原因是多样的。以下是一些常见原因： （1）项目外部环境发生变化； （2）项目总体设计，项目需求分析不够周密详细； （3）新技术的出现、设计人员提出新的或者新的实现手段； （4）建设单位由于业务变化、机构重组等原因造成业务流程变化。 （5）其它原因 我们再来仔细分析一下，上面的案例中的做法，会出现怎么样的问题 开发人员在听到用户的口头抱怨后，就直接对系统软件进行了修改，解决用户的问题，显然是不符合流程的。下面列举三条不合理的地方： 首先，开发人员没有书面记录用户的变更需求，可能会导致对系统软件变更的历史无法追溯； 其次，没有认真评估用户的变更需求是否合理，这样可能会导致与项目现有的工作可能不一致，导致影响成本、进度或者项目质量； 再次，进行变更时，没有与其他项目相关成员进行沟通，可能会导致其他项目成员的工作不一致。 那么我们应该怎样来处理项目中出现的变更需求呢？最好的办法是建立一套正规的程序对项目的变更进行有效的控制。 简单地说，管理变更的程序包括以下几个步骤： （1）识别变更：分析项目中出现的问题是否属于变更需求，区分是否为变更需求的标准就是，某项工作是否不在项目工作基准中； （2）评价变更对项目的影响：如果属于变更需求，进行分析，变更会对项目成本、进度、质量等因素产生哪些影响； （3）设计变更的备选方案：列出几种可能的变更处理方案，比如说非常紧急的变更需求马上批准，而对项目影响较少的变更可以稍后再处理； （4）提出变更申请：正式提出书面的变更申请需求； （5）征求项目干系人的意见:所有与变更有关的项目干系人（注：项目干系人指所有与项目有正面与负责利益的人之和）都应该参与项目变更； （6）批准或否决变更:提交相关项目管理人员，批准或者否则项目变更； （7）追踪变更的实施情况:变更批准后，我们需求跟踪变更的执行情况，并且要记录在案。 3.4 寻找项目关键路径 3.4.1 项目关键路径定义 项目关键路径，在项目管理中，关键路径是指网络终端元素的元素的序列，该序列具有最长的总工期并决定了整个项目的最短完成时间。关键路径的工期决定了整个项目的工期。任何关键路径上的终端元素的延迟将直接影响项目的预期完成时间（例如在关键路径上没有浮动时间）。 2.4.2 如何寻找关键路径 活动定义、活动排序以及资源和历时估算的结果就构成了制定项目进度计划的基础。项目的进度计划既是回答每个活动的进度安排，而更重要的是得到有关项目整体的进度信息。制定项目进度计划的工具和方法有：甘特图，关键路径分析和PERT估计。 这是一种用日历形式来列出项目活动及其活动起止时间的项目图示方法。由于这种图形表示方法最初是由泰勒的同事亨利.干特所发明，所以又被称作甘特图。现在大多数项目管理软件都可以自动生成甘特图。 在项目的甘特图中，有几个特殊的符号需要关注： 任务（Task），用带状的水平横道来代表一个任务，所以有的时候甘特图又叫横道图。横道的起点和终点就代表了任务的起止时间，横道的长度就代表了任务的持续时间。 里程碑（Milestone），具有零历时的重要事件。在图中用菱形符号代表。 依赖关系（Dependency），指各个任务之间存在着一定的依赖关系，例如：结束－开始，开始－开始，结束－结束，开始－结束关系。 概要任务（Summary Task），是指的一些任务集合成一个更大的任务，通常代表了任务的不同层级。 由于甘特图在表示项目进度信息方面简单明了，所以是现在应用最广泛的项目进度表示方法。 关键路径分析也称为关键路径法（Critical Path Method），是一种用来预测总体项目历时的项目网络分析技术。所谓“关键路径”，是指当我们完成了项目进度计划后，在项目的网络图上，存在着若干条从项目启动到项目结束之间的路径，但是对其中一条（严格的来说，可能存在一条以上）路径上来说： ● 其上所有活动的时间之和就是完成项目的最短历时； ● 路径上任何活动的延误都会导致项目时间的延长； ● 如果我们想缩短项目历时，就必须缩短这条路径上活动的历时； 这条路径就是项目的关键路径。如下图： 图 - 2.关键路径 怎样确定关键路径呢？它实际是项目网络图中（历时）最长的路径。下面我们来下一个定义，一个项目的关键路径：是指一系列决定项目最早完成时间的活动。在关键路径上的活动都很“关键”，因为它们直接决定了项目的进度。每个活动都只有最少的浮动时间或时差。所谓浮动时间或时差是指一项活动在不耽误后续活动或项目完成日期的条件下可以拖延的时间长度。 现在所有的项目管理软件工具都将寻找一个项目的关键路径作为最基本的功能。它是运用某种运算法则来计算而得出项目关键路径信息的。该运算法则被称为正推法和倒推法，这个法则输出的结果就是项目的关键路径，当然也包括项目的总历时和项目中每个活动关于进度的“关键”信息。虽然今天已经很少需要手工计算来得到项目的关键路径了，但是仔细了解一下它的算法将会非常有助于更深刻地理解所得到各项信息的意义。下面我们就来看一下如何用正推法和倒推法来计算项目的关键路径。 正推法和倒推法主要是用来计算有关一个项目活动的： 最早开始时间（Early Start，简称ES），在条件具备的情况下，该活动可以开始进行的最早可能； 最早结束时间（Early Finish，简称EF）， 在条件具备的情况下，该活动可以完成的最早可能； 最晚开始时间（Late Start，简称LS），在不拖延项目进度的情况下，该活动可以开始进行的最晚可能； 最早结束时间（Late Finish，简称LF）， 在不拖延项目进度的情况下，该活动可以完成的最晚可能； 如下图所示，对每一个项目活动的这4个参数都是一个时间点。 图 - 3.        正推法和倒推法的活动参数 所谓正推法就是从项目的第一个活动到最后一个活动跟踪全部活动的先后关系，计算出每个活动的最早开始时间（ES）和最早结束时间（EF）。 所谓倒推法则是从最后一个活动开始向前追溯到第一个活动，计算出每个活动的最晚开始时间（LS）和最晚结束时间（LF）。 正推法的计算过程包括四步： 步骤一：设定项目的第一个活动的最早开始时间是从第一天开始，如图： 图 - 4.        关键路径正推法的步骤一 步骤二：计算第一个活动的最早结束时间，可以用第一个活动的最早开始时间加该活动的历时减1得出：EF = ES + 历时－1，如图： 图 - 5.        关键路径正推法的步骤二 步骤三：计算该活动的所有后续活动的最早开始时间（ES）： 后续活动的ES＝前导活动的EF＋1 图 - 6.        关键路径正推法的步骤三 步骤四：过重复步骤二、三，为项目中的每个活动计算最早开始时间（ES）和结束时间（EF），如图所示： EF = ES + 历时 – 1 ES = 前导活动EF + 1 图 - 7.        关键路径正推法的步骤四 但是这里有一种情况需要特别考虑，因为正推法是依赖每个活动的前导活动来决定的，所以如果一个活动存在多个前导活动的话，需要采用前导活动中EF最晚的那个活动来计算该活动的ES。 倒推法的计算过程也包括四个步骤，只不过这次你是从项目的结束时间开始。但这里要用到正推法的结果： 步骤一：因为你不能延误项目的完成时间，因此最后一个活动的最早结束时间EF等同于最晚结束时间LF。 图 - 8.        关键路径倒推法的步骤一 步骤二：计算最后一个活动的最晚开始时间，可以通过用最晚结束时间减去该活动的历时然后加1来得出。 LS = LF – 历时+1 图 - 9.        关键路径倒推法的步骤二 步骤三：每个活动必须在后续活动开始之前完成，因此可以为每个活动计算最晚结束时间。 LF = 后续活动 LS – 1 图 - 10.    关键路径倒推法的步骤三 步骤四：然后重复第二、三步骤，计算出每个活动的最晚开始时间和最晚结束时间 图 - 11.    关键路径正推法的步骤四 同样在计算过程中也需要处理一个特殊情况，由于倒推法是依赖每个活动的后续活动来考虑的，所以如果一个活动出现多个后续活动的时候，应该取后续活动中LS最早的那个来计算该活动的LF。 事实上在完成倒推法的计算之后，我们得到了每个活动有关进度的关键信息： 最后一个活动的EF（LF）就是项目可能的最早完成时间，也就是项目的最终进度； 活动的LS确定了我们需要给该活动提供资源的最晚时间，如果超过了这个时间则意味着可能的项目最早交付时间会被延迟； 项目中历时最长的路径就是项目的关键路径； 如果关键路径上的活动历时没有被延误，那么项目进度就不会有延误； 如果我们要缩短项目的历时，就要缩短该路径上活动的历时； 我们可以通过公式来计算每个活动的总浮动时间（Total Float）TF = LF-EF，又被称为总时差。它代表了在不影响项目总体进度的前提下，活动可以延误的时间段； 我们还可以通过公式计算每个活动的自由浮动时间（Free Float）FF（活动X）＝后续活动的ES - EF（活动X）- 1。它代表了该活动不影响后续活动而可以被延误的时间。上面所说的总时差是自由浮动时间的一种。总时差是每个活动历时可以延误的范围，并且可以不影响总体项目的进度，而自由浮动时间是指在不延误任何活动最早开始的情况下，项目活动可以延误的时间范围。 下面我们来看一个例子的推演，帮助大家更好的理解。如下图是一个小项目的网络图，已经完成每个活动的历史估算，我们需要确定利用正推法和倒推法求出个活动的ES-EF-LS-LF，以及项目的关键路径： 图 - 12.    例题-推算关键路径 正推法求ES-EF： 步骤一：活动A的ES=1，EF=ES+20-1=20，如下图： 图 - 13.    例题-推算关键路径正推法步骤一 步骤二：求出以活动A为前导活动的那些活动的ES以及EF。 ES = 前导活动的EF+1  EF = ES + 历时 - 1 如下图： 图 - 14.    例题-推算关键路径正推法步骤二 步骤三：重复步骤二，计算出所有活动的ES-EF。但对于出现了两个前导活动的活动E来说，由于B的EF晚于D的EF，所以其计算取B的EF。如下图： 图 - 15.    例题-推算关键路径正推法步骤三 然后我们用倒推法来计算LS-LF。 步骤一：设最后一个活动E的LF=EF。LS = LF – 历时 + 1。如下图： 图 - 16.    例题-推算关键路径倒推法步骤一 步骤二：计算那些以活动E为后续活动的活动的LF-LS。 LF = 后续活动的LS – 1    Ls = LF – 历时 + 1 如下图： 图 - 17.    例题-推算关键路径倒推法步骤二 步骤三：重复步骤二计算所有活动的LS-LF。其中活动A有两个后续活动B和C， TF=10     图 - 18.    例题-推算关键路径倒推法步骤三 现在我们就得到了这个项目的关键路径：A- B-E。对于每一个活动的进度要求信息也很清楚，我们可以看到每个活动的浮动时间。在关键路径上活动的浮动时间都为0，意味着这些活动不能有半点拖延。而活动C和D的浮动时间为10，所以只要延误在10以内就不影响项目的总进度。因此我们可以灵活安排活动C和活动D的资源，可以在这些活动即将开始的时候再安排资源。这些活动也可以在最早开始时间时开始，也可以延后10天才开始，但都不会影响项目的结束。在资源平衡过程中，我们也经常会用到总时差。 实际上，活动C和活动D有10天的浮动时间，并不是意味着每个活动都有10天的浮动时间，而是两个活动共有10天的浮动时间。我们习惯上将活动C的浮动时间扣除掉，即只有活动D有浮动时间。路径CD的浮动时间仅为10天。 但是活动C的总时差和活动D的总时差是有差别的。换句话说，就是活动C允许偏离进度的时间和活动D允许偏离进度的时间是有差别的。 如果活动D在第31天开始，这是活动D的最早开始时间，由于活动D有10天的延误时间，那么该活动在第60天结束，那么会不会影响项目的结束呢？回答是：不会。 现在，我们假设活动C 可以准时在第21天开始，并且最晚要在第40天时完成。如果这样的话就不会影响项目的进度。但由于活动C的进度发生偏离，那么会影响项目D不能在最早时间开始和最早时间结束。如果在中，被安排到活动D的资源的使用时间段为：第31天到第40天。在第40天的时候，这些资源将被撤走，安排到其它的项目中。因为活动C的进度延误将会导致活动D的资源出现短缺，因而活动D也会出现延误，并最终导致项目的延误。因此活动C间接地导致了项目的延误。 在这里我就可以看到总时差和自由浮动时间的区别，例如： FF（活动C）＝31（后续活动最早ES）-30（EF（活动C））- 1 = 0 FF（活动D）＝61（后续活动最早ES）-50（EF（活动C））- 1 = 10 因此活动D有10天的自由浮动时间，而活动C没有。 关键路径重要概念 总时差与自由时差的区别 总时差是指在不延误项目完成日期或违反进度因素的前提下，某活动可以推迟的时间。总时差=LS-ES=LF-EF 自由时差是指在不影响紧后活动最早开始的情况下，当前活动可以推迟的时间。自由时差=(后一活动)ES-(前一活动的)EF-1 所以总时差影响总工期，自由时差影响紧后活动。 如何计算ES,EF,LS,LF 前推法来计算最早时间 某一活动的最早开始时间（ES）=指向它的所有紧前活动的最早结束时间的最大值。 某一活动的最早结束时间（EF）=ES+T（作业时间） 逆推法来计算最迟时间 某一活动的最迟结束时间（LF）=指向它的所有紧后活动的最迟开始时间的最小值。 某一活动的最迟开始时间（LS）=LF-T（作业时间） 计算关键路径的步骤 1. 用有方向的线段标出各结点的紧前活动和紧后活动的关系，使之成为一个有方向的网络图（PDM） 2. 用正推和逆推法计算出各个活动的ES,LS, EF, LF，并计算出各个活动的自由时差。找出所有总时差为零或为负的活动，就是关键活动 3. 关键路径上的活动持续时间决定了项目的工期，总和就是项目工期。 进度压缩的方法 ● 增加人手，聘请更有经验的人员，或找兼职人员 ● 加班 ● 并行 ● 重新估算后面的工期 ● 加强沟通，减少变更 ● 加强控制，避免返工 ● 外包 ● 加强沟通，先完成关键需求 ● 增加资源有时可能压缩工期有限 ● 降低要求或减少项目的范围。 4. 编码工作量估算 本次评估的是《IAS网络优化系统》。为了更准确的估算出软件的工作量，我们对每一个软件功能模块所需工作量给出了三个估计值，分别是： 1）悲观工作量（Epi）：这是一个最保守的估计，可能在编程人员技术不熟练，对业务理解不够，或有其他影响其正常工作的因素存在的情况上发生。 2）正常工作量（Eni）：这是一个正常的程序员可能付出的工作量估计。 3）乐观工作量（Esi）：这种情况可能在程序员技术相当熟练，对业务相当了解，且以前可能有类似项目开发经验的情况下所需的工作量。 针对每一项功能模块，其最终的工作量估算值按以下公式计算： Ei = （Epi + 4 × Eni + Esi）/ 6 下面的表1是对IAS网络优化系统终端的编码阶段的工作量估算，表2是对IAS网络优化系统平台端的编码阶段的工作量估算。 表1：IAS网络优化系统终端 序号 功能名称 悲观工作量（人.小时） 正常工作量（人.小时） 乐观工作量（人.小时） 工作量(Ec1)（人.小时） 1 登录 20 16 7 15.17 2 站点结构核查 30 24 16 23.67 3 小区性能测试 24 18 12 18 4 楼层遍历测试 24 18 12 18 5 外泄测试 24 18 12 18 6 切换测试 24 18 12 18 7 电梯测试 24 18 12 18 8 无线参数测试 24 18 12 18 9 信令信息查看 20 16 7 15.17 10 测试结果呈现 30 24 16 23.67 11 系统设置 20 16 7 15.17 12 图片采集 30 24 16 23.67 13 建筑物详情核查 30 24 16 23.67 14 新增测试功能 30 20 12 20.33 15 CQT测试 30 20 12 20.33 16 楼层遍历测试 30 20 12 20.33 17 小区道路DT测试 30 20 12 20.33 18 无线参数测试 30 20 12 20.33 19 测试记录管理 20 16 7 15.17 20 信令信息查看 20 16 7 15.17 21 GIS地图管理 20 16 7 15.17 22 图片采集 24 18 12 18 23 站点搜索 20 16 7 15.17 24 基准设置 20 16 7 15.17 25 仪表状态 30 24 16 23.67 26 天线工参测量 20 16 7 15.17 27 数据管理 20 16 7 15.17 28 照片管理 20 16 7 15.17 29 系统管理 20 16 7 15.17 30 工单管理 30 24 16 23.67 31 预约录音 30 24 16 23.67 32 现场照片上传 20 16 7 15.17 33 生成测试LOG 20 16 7 15.17 34 小区性能测试 20 16 7 15.17 35 投诉信息管理 20 16 7 15.17 36 回复模板自动生成 30 24 16 23.67 37 无线参数 20 16 7 15.17 38 设置 30 24 16 23.67 合计 928 714 407 698.57             表2：平台工作量清单 序号 功能名称 悲观工作量（人.小时） 正常工作量（人.小时） 乐观工作量（人.小时） 工作量(Ec1)（人.小时） 1 登录 20 16 8 15.33 2 项目进度统计 20 16 8 15.33 3 站点数据管理 20 16 8 15.33 4 测试记录管理 30 24 16 23.67 5 测试报告管理 20 16 8 15.33 6 测试LOG管理 20 16 8 15.33 7 GIS地图管理 30 24 16 23.67 8 log回放软件 20 16 8 15.33 9 系统日志管理 20 16 8 15.33 10 用户管理 20 16 8 15.33 11 合作单位系统对接模块 14 10 5 9.83 12 楼宇数据管理 30 24 16 23.67 13 测试记录管理 30 24 16 23.67 14 测试报告管理 30 24 16 23.67 15 测试LOG管理 14 10 5 9.83 16 GIS地图管理 24 20 10 19 17 系统日志管理 20 16 8 15.33 18 用户管理 20 16 8 15.33 19 合作单位系统对接模块 30 24 16 23.67 20 log回放软件 20 16 8 15.33 21 天线工参数据管理 20 16 8 15.33 22 单位管理 20 16 8 15.33 23 测试数据管理 20 16 8 15.33 24 系统设置 20 16 8 15.33 25 地图浏览 20 16 8 15.33 26 工单流程管理 30 24 16 23.67 27 工单计时提醒 20 16 8 15.33 28 测试结果查看 20 16 8 15.33 29 测试日志下载回放 30 24 16 23.67 30 测试人员实时定位 30 24 16 23.67 31 现场数据实时GIS展示 20 16 8 15.33 32 关键KPI查询 20 16 8 15.33 33 全网告警GIS展示和查询 20 16 8 15.33 34 专业统计报表 20 16 8 15.33 35 全网工参管理 20 16 8 15.33 36 基础信息管理 22 16 12 16.33 37 勘站记录管理 14 10 5 9.83 38 系统管理 20 16 8 15.33 39 GIS地图管理 20 16 8 15.33 40 站点结构核查 20 16 8 15.33 41 小区性能测试 20 16 8 15.33 42 楼层遍历测试 20 16 8 15.33 43 外泄测试 30 24 16 23.67 44 切换测试 30 24 16 23.67 45 电梯测试 30 24 16 23.67 46 无线参数测试 30 24 16 23.67 47 信令信息查看 20 14 7 13.83 48 测试结果呈现 10 6 5 6.5 49 图片采集 30 24 16 23.67 50 建筑物详情核查 30 24 16 23.67 51 新增测试功能 20 14 7 13.83 52 CQT测试 30 24 16 23.67 53 楼层遍历测试 30 24 16 23.67 54 小区道路DT测试 20 14 7 13.83 55 无线参数测试 30 24 16 23.67 56 基准设置 24 16 10 16.33 57 仪表状态 20 14 7 13.83 58 天线工参测量 20 14 7 13.83 59 数据管理 24 16 10 16.33 60 照片管理 24 16 10 16.33 61 生成测试LOG 24 16 10 16.33 62 小区性能测试 30 24 16 23.67 63 投诉信息管理 24 16 10 16.33 合计 1424 1110 645 1084.76             上述两块工作的编码阶段的工作量合计为： Ec = Ec1 + Ec2 = 698.57 + 1084.76 = 1783.33(人.小时) 5软件生命期工作量估算 为便于估算，我们假定《X软赠券电脑发放管理系统》和《X软联销资源管理系统》均按照瀑布模型开发。 瀑布模型将整个软件生命期划分为计划与需求、产品设计、详细设计、编码与单元测试、集成与测试、移交等六个阶段，各阶段所占工作量如表3所示。 表3：瀑布模型阶段分布百分比 序号 阶段（端点） 工作量% 1 计划与需求 12 2 产品设计 17 3 详细设计 23 4 编码与单元测试 24 5 集成与测试 19 6 移交 5       根据上表，编码与单元测试阶段仅占全部工作量的24%，因此《X软赠券电脑发放管理系统》和《X软联销资源管理系统》的工作量估算值应为： E = Ec / 24 % = 1783.3 / 24 % = 7430.4（人.小时） 根据我国的实际情况，每周休息2天，每年还包括三个长假，因此，每个月的工作日假定为20天，每个工作日工作8小时。按此假定，上述工作量换算成人月数应为： E = 7430.4 / (20 × 8) = 46.44（人.月） 6.工作量评审 工作量估算出来后，有项目经理组成相关干系人和专家对工作量进行评审。评审会上按评审项逐一对工作量进行评审。 我司工作量评审内容主要是参照下表： S/N 评审大类 评审项