讲座6.软件工作量估算_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
讲座6.软件工作量估算
上传于||暂无简介
大小：1.67MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢测试工作量估算是测试计划的基础工作之一_解决方案网当前位置:& &&&全程软件测试之测试需求分析与计划（二）全程软件测试之测试需求分析与计划（二）本文收集于网络，只用于方便查找方案，感谢源作者，如果侵权请联系删除全程软件测试之测试需求分析与计划（2）
测试工作量估算
在确定了测试需求、明确了测试范围之后，就需要明确测试任务，估算测试工作量。基于质量需求和测试的工作量、测试环境、产品发布的设想时间等要求，就可以确定测试进度和所需的测试资源，或者基于现有的测试资源来决定测试的日程表。
在传统开发模式中，测试工作量估算是测试计划的基础工作之一，但在敏捷开发中，虽然也强烈建议有一个测试计划，但其测试计划简明扼要，主要是列出测试目标、测试边界、测试点、主要的测试风险和注意事项等。其测试任务在迭代计划（如Scrum的Sprint Planning）会议中和开发任务一并考虑，可以采用Scrum估算扑克牌的方式来完成估算，这样测试工作量估算主要依赖个人经验、团队沟通等完成。即使是采用这种方式，对下面内容了解之后，有一个科学估算的基础，在敏捷开发中依旧会发挥作用。
工作量的估计
测试的工作量是根据测试范围、测试任务和开发阶段来确定的。测试范围和测试任务是测试工 作量估算的主要依据。如何确定测试范围已在上一节做了充分的讨论，可以根据产品需求规格说明来决定。测试任务是由质量需求、测试目标来决定的，质量要求越 高，越要进行更深、更充分的测试，回归测试的次数和频率也要加大，自然，测试的工作量要增大。处在不同的开发阶段，测试工作量的差异也挺大。新产品第一个 版本的开发过程，相对于以后的版本来说，测试的工作量要大一些。但也不是绝对的，例如，第一个版本的功能较少，在第2、3个版本中，增加了较多的新功能，虽然新加的功能没有第一个版本的功能多，但是在第2、3个版本的测试中，不仅要完成新功能的测试，还要完成第一个版本的功能回归测试，以确保原有的功能正常。
在一般情况下，一个项目要进行2～3次回归测试。所以，假定一轮（Round）功能测试需要100个人日（man-day），则完成一个项目所有的功能测试肯定就不止100个人日，往往需要200～300多个人日。可以采用以下公式计算：
W ＝ Wo + Wo ? R1 + Wo ? R2 + Wo ? R3
W为总工作量，Wo为一轮测试的工作量。
R1，R2，R3为每轮的递减系数。受不同的代码质量、开发流程和测试周期等影响，R1、R2、R3的值是不同的。对于每一个公司来说，可以通过历史积累的数据获得经验值。
测试的工作量，还受自动化测试程度、编程质量、开发模式等多种因素影响。在这些影响的因素中，编程质量是主要的。编程质量越低，测试的重复次数（回归测试）就越多。回归测试的范围，在这3次中可能各不相同，这取决于测试结果，即测试缺陷的分布情况。缺陷多且分布很广的话，所有的测试用例都要被再执行一遍。缺陷少且分布比较集中，可以选择部分或少数的测试用例作为回归测试所要执行的范围。
在代码质量相对较低的情况下，假定R1、R2、R3的值分别为80%、60%、40%，若一轮功能测试的工作量是100个人日，则总的测试工作量为280个人日。如果代码质量高，一般只需要进行两轮的回归测试，R1、R2值也降为60%、30%，则总的测试工作量为190个人日，工作量减少了32%以上。
自动化程度越高，测试工作量就越低。由计算机运行的自动化脚本效率很高，能使执行实际测 试的工作量大大降低。但是在很多情况下，测试自动化并不能大幅度降低工作量，因为测试脚本开发的工作量很大。也就是说，将总体的测试工作量前移了，从测试 执行阶段移到测试脚本设计和开发的阶段，总体工作量没有明显降低。同时，由于自动化脚本可以重复使用，而且机器可以没日没夜地运行，回归测试就可以频繁进 行，如每天可以执行一次，这样任何回归缺陷都可以即时发现，提高软件产品的质量。
工作量的估计是比较复杂的，针对不同的应用领域、程序设计技术、编程语言等，其估算方法是不同的。其估算可能要基于一些假定或定义。
（1）效率假设，即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度、窗口的个数、每个窗口中的动作数目。对于容量测试，主要依赖于建立测试所需数据的工作量大小。
（2）测试假设，目的是验证一个测试需求所需测试的动作数目，包括估计的每个测试用例所用的时间。
（3）阶段假定，指所处测试周期不同阶段（测试设计、脚本开发、测试执行等）的划分，包括时间的长短。
（4）复杂度假定，应用的复杂度指标和需求变化的影响程度决定了测试需求的维数。测试需求的维数越多，工作量就越大。
（5）风险假定。一般考虑各种因素影响下所存在的风险，将这些风险带来的工作量设定为估算工作量之外的10%～20%。
工作分解结构表方法
要做好测试工作量的估算，需要对测试任务进行细化，对每项测试任务进行分解，然后根据分解后的子任务进行估算。通常来说，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮动幅度，来确定实际所需的测试工作量。比较专业的方法是工作分解结构表（WBS），它按以下3个步骤来完成。
（1）列出本项目需要完成的各项任务，如测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。
（2）对每个任务进一步细分，可进行多层次的细分，直到不能细分为止。如针对测试计划，首先可细分为：
确定测试目标；
确定测试范围；
确定测试资源和进度；
测试计划写作；
测试计划评审。
“确定测试范围”还可再细分为功能性测试范围和非功能性测试范围的分析。“测试计划评审”可以再分为测试组内评审、项目组评审、公司质量保证小组评审和最终批准。
（3）列出需要完成的所有任务之后，根据任务的层次给任务进行编号，就形成了完整的工作分解结构表（如表2-5所示）。
WBS除了用表格的方式表达之外，还可以采用结构图的方式，那样会更直观、方便，如图2-5所示。
当WBS完成之后，就拥有了制定日程安排、资源分配和预算编制的基础信息，这样不仅可获得总体的测试工作量，还包括各个阶段或各个任务的工作量，有利于资源分配和日程安排。所以，WBS方法不仅适合工作量的估算，还适合日程安排、资源分配等计划工作。
工作量估计的实例
结合Google日历的功能点可以看出，测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各阶段的时间安排。根据Google日历的功能计算，测试用例数为6×60 = 360例（以平均每个大模块60个用例来算）。除了测试用例数，还要考虑以下因素。
根据测试团队和项目的具体情况来算，如2.3.3节中的几个假定：效率假设、测试假设和应用的维数等。
测试平台、环境的不同组合，包括操作系统、浏览器、通信协议、防火墙、代理服务器等的组合。
回归测试频率和重复次数。
自动化测试的水平。
其他特定的因素，增加10%～20%的余量。
在Google日历的测试中，做如下假定和分析。
所有人员为中级软件测试工程师的水平。
每个测试用例设计时间为20分钟，包括评审、输入到用例管理数据库中等所用的时间。所以测试用例设计的时间为120小时，即15个人日。
70%的测试用例可以进行自动化测试，30%为手工测试。即自动化测试用例数为252例，手工测试用例数为108例。
每位工程师每天可开发10个测试用例的测试脚本，包括调试。所以测试脚本开发的工作量为26个人日。
要进行两次的回归测试，R1、R2值为70%、40%，则单平台下手工运行的测试用例数为108×(1＋70%＋40%) ＝ 227例。
对操作系统没有影响，而且不考虑SSL的支持，只考虑浏览器IE6.0、IE7.0、Firefox1.5、Firefox2.0和代理服务器的影响。作为交叉组合，共设为4种。
也没有必要在4种组合上运行所有的测试用例，两种主要组合运行100%的手工测试用例，另外两种组合运行50%的手工测试用例，即测试用例数为原来的3倍，所以手工运行的测试用例数为227 × 3 ＝ 681例。
假定每个测试工程师每天可以运行60个测试用例，即每个测试用例的执行要用5分钟，运行测试用例要用5个小时，另外3个小时用于处理缺陷报告和邮件、与开发人员沟通等。所以手工测试用例执行的时间为12个人日。
自动化测试的运行都在晚上进行，工程师需要时间分析测试结果、修改脚本适应新的变化、做缺陷报告等，估计要5个人日。
这样就估算出了功能测试的基本工作量，即15＋26+12+5=58个人日。
对系统测试的工作量，可以按照同样的方法进行，所不同的是系统测试几乎是由测试工具完成的，工作量主要集中在环境构建、测试数据准备和结果分析等上面。表2-6给出了Google日历所要的测试工作量。
测试资源需求
分析测试范围之后，所需要的测试资源就比较清楚了。测试的资源需求，包括人力资源和软、硬件资源。人力资源，侧重如何组建测试团队——项目测试组，而软、硬件资源，对于不同的项目差异很大。这里只讨论一般的操作方法，设计测试环境的建立，将在第7、第9章进行详细介绍。
如果将测试资源进行较为详细的分类，可以归纳为如图2-6所示。
1．人力资源需求
在完成了测试工作量的估算之后，软件测试项目所需的人员数目就能够基本确定了。软件测试项目所需的人员和要求在各个阶段是不同的。
（1）在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。
（2）在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。
（3）在测试中期，主要是测试的执行，测试需求的数量取决于测试自动化实现的程度。如果测试自动化程度高，人力的投入则不需要明显的增加；如果测试自动化程度低，对执行测试的人员要求就比较多了。
（4）在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。
2．测试环境资源
把建立所有必要的测试环境所需的计算机软件资源和硬件资源合称为测试环境资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源包括操作系统、第三方软件产品、测试工具软件等，具体如下。
硬件：交换机、路由器、负载均衡器（Load balance）、服务器、客户端PC、摄像头、特殊的显示卡和声卡、耳机、麦克风等。
支撑的系统软件：Linux操作系统、Web服务器（如Apache）、中间件（如Tomcat、WebLogic）、数据库系统软件MySQL/Oracle等。
测试工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。
测试里程碑和进度安排
软件测试贯穿软件产品开发的整个生命周期，从产品的需求分析审查到最后的验收测试，直至软件发布。从测试实际的前后过程来看，软件测试的过程是由一系列不同的测试阶段组成的，这些阶段主要有：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。在软件测试项目的计划书中，需要给各个阶段制定一个明确的开始和结束时间，这就是通常所说的日程进度表（schedule）。项目进度安排，实际上取决于测试工作量和现有的人力资源。当人力资源充足时，测试周期短；当人力资源较少时，测试周期就会长。
里程碑一般是项目中完成阶段性工作的标志，即用一个结论性的标志来描述一个过程性任务明确的起止点，进度安排就是确定里程碑的起止点。一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。里程碑具有很强的时序性，还具有下列特征。
里程碑也是有层次的，在一个父里程碑的下一个层次中定义子里程碑。
不同类型的项目，里程碑可能不同。
不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
在软件测试周期中，建议定义下列6个父里程碑。
（1）M1：需求分析和设计的审查。
（2）M2：测试计划和设计。
（3）M3：代码（包括单元测试）完成。
（4）M4：测试执行。
（5）M5：代码冻结。
（6）M6：测试结束。
每个里程碑再划分为子里程碑，如果项目周期很长，还可以对每个子里程碑进一步划分为更小的里程碑，以利于更有效的控制，如表2-7所示。
在本书一开始的引言中，以Scrum为例，简要阐述了敏捷测试流程。而在敏捷测试项目中，如何明确测试的里程碑呢？万变不离其宗，敏捷测试也需要从测试计划到测试设计、再到执行，只是测试设计和执行的界限不那么分明，测试设计和执行往往交替或并列地开展。在敏捷测试中，甚至可以不需要测试用例，而是针对Use Case 或User Story直 接进行验证，并进行探索性测试。而节约出来的时间，用于开发相对稳定功能的自动化测试脚本，为后期的回归测试服务。自动化测试脚本将代替测试用例，成为软 件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合上述考虑，敏捷测试的实际操作流程如图2-7所示，简单有效。
在这样的流程中，大框架也没有什么不同，而且各项测试件（测试计划、需求、自动化脚本等）的评审还是需要的，只是没有明确的评审阶段，测试是一个持续的质量反馈过程，阶段性不那么突出，但还是可以设定一些控制点，即里程碑：
（1）测试任务定义；
（2）测试计划制定和评审通过；
（3）测试需求或测试点（或测试场景）列表明确和评审通过；
（4）验收测试结束。 ——————本文节选自《全程软件测试（第2版）》
上一篇：下一篇：
File: 3:03:37如何处理项目预估量与实际工作量相差较大的情况?
做项目过程中，特别是在项目经理资历和经验不足时常会出现项目预估量与实际工作量之间相差较大，比如预估工作量远小于实际工作量，而且所预定的人手远远不够完成当前工作，一时之间又找不到合适的有经验的人来完成工作，而当前参与工作的人已经处于超负荷工作状态，此种情况各位有什么行之有效的方法来解决吗？
按投票排序
所以我说，不是人人都能做项目经理的，这是个靠经验和执行力吃饭的技术活。技术、经验、执行力缺一不可。我们来看看你目前的困境：项目经理能力不够胜任；人手不够，超负荷工作；工作量大；时间紧迫，不能按照预期完成工作；又是一个资源、工期、质量（潜在的）的矛盾问题。我想起了一个合作过的外包团队：项目经理是承担项目部分代码工作的资深管理；有一个可以对客户开放的项目进度管理平台，客户和项目成员随时可了解项目进度和目前可交付物；严格按人工时收费；开发人员绝不加班，理由是不能保证充沛的精力做第二天的工作，这样人工时的计算将不准确；拒绝没有能力承接的项目。回来看问题，用一个不能胜任的项目经理是最大的失误，这是很多野路子项目的一贯做法，认为项目经理不是技术活，就做做计划做做报表，这种项目经理在团队里没有权威，申请不到资源，谈不上协调。如果发生了以上情况还不能让你做出改变，那么我觉着就让项目死吧，没救了。换项目经理，或者BOSS和技术总监加入项目管理团队，来弥补项目经理的能力不足：正确评估项目现状；必须实现最重要的几个功能；每个功能的工作量评估；对于不确定的项目最好的方法是小周期迭代式开发；项目的里程碑和检查点；预估风险。再来看目前的人手，是否能够满足以上功能的开发？是否有资金扩充人员？由于有些开发不能做到并行，扩充人员是否能达到效果？工期是否有可能延期？项目管理团队共同来做出决策，然后坚决执行和定期检查和调整。员工超负荷工作，疲劳战术做不出高质量的产品。我在实际工作中有个经验分享一下：用最好的程序员写最核心的代码，能保证BUG最少，后期维护的代价最小。检查一下你的人员配置是否最高效。
项目预估量与实际工作量相差较大，并不是造成项目整体延迟的主要原因，只要估算的工作足够准确，但并不需要很精确，仍然有方法能够保证项目如期完成。不同的项目类别，不同的项目规模，不同的交付要求，项目的不确定性等级等采用的项目管理方法都会有所不同，并没有一概而论的方法。仅就一般而言（假设-项目团队能力足够，仅仅是时间资源及任务安排存在挑战）造成项目拖延主要有以下原因：1、不良的多任务工作，虚耗大量的时间；2、稽延效应，任务早完成并不会使项目提前完成，而任务延迟将会使项目整个拖延；3、过度管理，例如，过度精细的项目计划、过多的会议/汇报，而造成注意力分散、时间浪费；4、单个任务中预留过多的安全时间；5、关键资源受限等等。而针对以上问题，可以采取的举措是：1、考虑约束资源，基于约束资源进行排程，并找到整个项目的关键链；2、压缩具体关键链上的任务的预估时间，将时间作为整个项目的缓冲；3、项目经理注意力聚焦在关键链的进度状态，对于发生在关键链上的障碍及问题及时投入资源解决，确保整体流畅；4、看板管理，避免团队成员的多任务及过度管理等。另外，好的项目计划及项目经理，能够在项目“验尸”时候解释死因。你需要基于计划记录一路走来的历史，问题的记录、争议的记录、决策受质疑的时候当时做的决议等。
把需求拆分成小的需求，这样估算的偏差会减小；把需求的任务拆分为更小的颗粒，估算的偏差会减小。还有：对需求理解的正确性、实现思路在编码前的评审....
1. 把deadline推后；2. 把要实现的feature list砍掉一般，只留下必要的；3. 保留12个人以下的团队，超出了就分组；4. 每一次大的迭代周期不要超过半年。在你不是很有经验的情况下，工作量预估的原则是：在你估计的较宽松情况下能完成的基础上，翻一倍。为了避免以后预估工作量出问题，要把前后每一个环节都想到，并且留有机动时间。如果团队已经负荷很满了还不能按时完成工作，这个时候大家需要鼓励，千万不要使用添油战法。
项目预估不准是很正常的事情，特别是项目越大开发周期越长，最后偏差的程度就会越大。 我的建议是把项目尽可能的细分成若干小项目，三天到一周的工作量， 这样可以及时发现进度预估的错误，并且及时调整（要加班也是每周周末加了）
挖坑之前让你自己，还有让你的上级明白一点，在质量、成本、时间中，你只能同时拥有两样。如果大坑已经挖成，且预计无法填上，还是爬出来，洗洗干净走吧。
根本没有这样的解决方案！！！
从问题上看有这几个前提条件:预估工作量远小于实际工作量人手远远不够,且都已经处于超负荷工作状态找不到合适的有经验的人
问: 行之有效的解决方案
请问，如果在没有新的人手添加的情况下，能够按时地将项目完成，那么就不存在“预估工作量远小于实际工作量”这种情况了。这个不是前后矛盾吗！因此，必须将前提条件进行修改。从前提条件看，第三种条件是最好解决的问题，其他的条件都已经无法改变了。我的建议是，立即调用一名优秀的项目经理进入项目组，充当救火队员，辅助（或者接替）前项目经理的工作。我对优秀项目经理的定义是必须既懂项目管理又懂技术，而且这两样都必须很强。
救火队员进入项目组后，第一件事就是必须查明项目不能按时完成的原因。以我几次救火的经验看，主要有以下几个情况：需求理解错误。别人让你盖个烟囱，结果你挖了口井。这样的错误，对项目来说是灾难性的。项目预估和实际偏差太大。盲目引入新技术。有些程序员特别喜欢“时髦”的技术。只要一有什么新的技术开始流行，他就想把它引入项目中去。整个项目组，只有他一个人懂。而他自己本身能力有限，对新技术掌握不全面，一旦出现问题，无法通过互联网找到解决方案的话，就不知如何是好了。整个项目就卡死在这个瓶颈上。这时候，你就会听到这种人到处抱怨“xx技术（框架）实在是太烂了“。大家看看自己身边是否有这样的人呢。客户需求不断的变化。整个项目组成员都被牵着鼻子走。核心技术人员的离职。
以上这些原因都是由于前任项目经理失职所造成的。救火队员所要做的，就是将他未做好的工作，重新再做一遍。针对上面主要的5种情况，分别采用以下的处理方法。
重新进行需求分析。对项目的需求要有彻底的理解。当需求分析结束后，按照开发流程进行后面的工作，如系统设计，代码开发等。在这些过程中，尽量复用已经完成的功能模块。重新预估项目，重新制定开发计划。并将该情况通知老板。由你的老板来决定是调用更多的资源来帮助你，还是和客户进行沟通，延迟项目交付时间，还是最终放弃这个项目。帮助该程序员，看看是否能够解决这个技术问题。如果暂时无法解决，考虑将新技术从项目中去除掉，采用项目组成员都比较熟悉的技术来替代。审核项目中所使用的技术，必须保证是项目组成员都已掌握的技术。技术新不新，高级不高级并不是很重要。针对客户的不断变化的需要，项目经理必须强势。在客户提出新的需要时，你必须告之对方该需求对项目将会产生影响，项目的成本也将随之上升。因此，合同的金额必须增加，项目的交付日期也将延后。让客户自己选择，增加不增加该需求。千万不要答应免费做哦。救火队员就是新的核心技术人员了。此外，还有以下几项以供参考：每天上午，白板前，小组站立会议，大概20分钟左右。每个人报告自己的工作进度，目前碰到的困难，今天的工作计划。对于碰到困难的组员，看看能不能立刻给出解决方案。如果不行，救火队友在会议结束后，立刻过去辅导，可以pari program。有限度的加班，不要到达每个人的极限，这样团队坚持不了多久的。好的设计，可以让你以极小的代价来应付各种需要变化。一定阶段后，小版本发布。将部分功能演示给客户看。一般情况下，客户都会提出各种意见或者新需求。你需要告诉客户，这些变动将会延长项目交付时间。至于延长多少，我一般会多加个1周或者2周的时间。客户如果同意，那么你就为自己多争取了1到2周时间。这个方法，我可是屡试不爽哦。
以上问题其实涉及到项目管理中的项目计划，需求管理，风险控制，组间协调，系统设计等等，如果展开来说，恐怕要说一大堆了，这里就不再啰嗦了。
当救火队员是非常辛苦的，但是收获也是很大。它可以让你在公司里面迅速建立极高的威望。每当你进入一个在泥沼中挣扎的项目组时，你会从他们疲惫的面孔中看到惊喜，听到他们的欢呼。当你和他们共同努力完成项目后，你也会交到更多的朋友。
这个问题似乎显示了题主对项目管理理解的一个误区，不应该把重点放在出了这种情况怎么处理，应该着重关注如何避免问题中出现的情况，这才是项目经理的职责所在。真出现这样的困境实际上已经晚了，能做的只是一点补救措施。无论什么原因，预估的工作量如果远小于实际工作量某种意义上是项目经理的失职。不过话说回来既然问题是如何处理，理应包括事前处理和事后处理，所以说说如何避免也不算跑题。一个项目中的关键要素就那么几个：有多少工作，都有什么人来做，工作的期限是什么，公司愿意为此项目负担什么成本。对于一个正常的项目来说，抛开哪些讲政治、刷阴谋、有人背后拆台的事情不说。那么项目前要做的：1 评估工作量，了解工作内容。这个是项目经理的基本功，经验越多估算的越准确。要了解项目都包括哪些工作，大概都需要什么水平的人做。如果对工作不了解怎么办？那就找个经验丰富或者了解某一项相关工作的人帮着你估算。或者参考你们公司历史上做同类项目的实际工作量。如果一个这样的人都找不到并且我们公司从来没做过这样的项目怎么办？（那只能说你们公司很有勇气，什么活都敢接）根据你对自己智商的评估把工作量在你第一次估算的结果加上10%到80%不等。2 确定项目人员。这个要部门和公司充分沟通，越早确定项目人员越有利，对人员越了解越有利，包括什么人能挑大梁，什么人只能干粗活，什么人可能项目做一半就跑。如果实在缺人不得不招人的话，这样的新人最好不要太多。如果一个老人没有全招新人怎么办？（你们公司领导勇气非凡）把招来的人放在一起，至少用一周的时间做demo做演示，实际上是拿人做实验。看看到底谁能干活，能干什么活。你必须要了解项目成员水平，整个项目组必须有人要了解这些工作要怎么做。3 计算工期。注意这里是你计算的工期，不是客户要求的工期。用前面估算的（工作量/人员）×1.1或者1.2=估算工期。 为什么×1.1？这是你整个项目顺风顺水的时候突发情况会占用你的项目时间。如果前面算的都不准，那这里就比较悲剧了，稳妥的做法只能是再往后延。算完了以后你回过头看看客户实际要求的工期，如果差的太多干脆就别做了。公司非逼你做的话也可以，问问有什么相应的激励机制（多半是钱），重赏之下必有匹夫，咬咬牙还是可以做。如果什么额外的都不给呢？那……另请高明吧。项目中要做的：1 拆分工作项目经理的基本功，工作拆分、计量然后分配。水平高的人做有难度的工作，水平差的做重复劳动。按照项目工期从最后一天开始一点点的倒排，第一次任务拆分不要安排加班，直到所有工作在指定时间下都有专人负责为止。如果有人分配的工作做不来怎么办？那就培训或者给一些学习时间还是让他做。如果他就是学不会呢？那就调能做的人来。如果调都调不来呢？那就从外面招人。如果招都招不到呢？……那你还做这个项目只能说你活该。如果分配的工作可以做但是要超时呢？那需要适当安排加班。2 工作量发生变化这种情况很常见，各方面原因都有。一开始没做对造成返工怎么办？没说的，自己的问题重来吧，这个时间就是那×1.1里面0.1的。返工要反90%怎么办？说明之前根本误解了工作内容，项目基本等于失败只能补救。一个新人误操作把东西全删了怎么办？要看是否有备份，新人是否培训了。如果都有，那简单按项目纪律处理。都没有？老老实实加班找公司要人，把这个临时难关度过去。客户要加工作怎么办？和公司领导和销售商量，是否控制客户的新需求。如果控制？没说的尽力往回顶，你顶不回去叫销售来一起顶，都顶不回去叫老板一起顶。如果不控制？那就加人\延期\加钱，就算客户不给钱也要找公司要钱。3 人员变化有人做一半不做了跑路怎么办？谈心挽留之。如果还是跑呢？（早你就应该发现这样的人）尽量安抚找人来做工作交接，然后招人\调人。4 验收。工作拆分了也安排下去都有人做了就完了么？没完，你必须按期或者按检验点验收别人的工作。否则他说做了100%实际才完成10%最后你会欲哭无泪的。 我一个人验不过来怎么办？找质管\测试\监理什么的和你一起验。验收了，根据安排确实做不完怎么办？加人加班，没什么好说的。如果上述都做到了，还出现题目的情况怎么办？那以我的能力真帮不到您了。补救无论前面怎么说，总之现在就是出了灾难性的状态怎么办？其实补救的办法相当有限。尽全力要人，要不到人就招人。哪怕付出对新人的培训时间成本也要招人。拉上销售和领导努力和客户沟通尽可能的延期。如果不能延期就和客户沟通在这个时间点之前只上那些必须的工作，不是最紧急的工作往后延。总之全力压缩工作。向项目成员许诺，熬过这段放长假\大大的加班费\出国旅游。尽可能的保持积极性，避免跑路。但千万注意不要加班加出工伤，不要出人命。所有工作向项目成员的工作让路，他们不能被打扰不能分心。不允许任何人打断项目成员的工作直接与项目成员沟通，有事找项目经理，工作一律项目经理安排。
如果是远大于预估，说明项目预算，计划就有问题了。基于当前的情况重新估算所需人天。分析差异原因，合同中有不明确地方？范围蔓延？对风险预估不足？然后再考虑怎么解决，是否需要延期；不延期需要增加多少资源；项目是否有紧急备用金，可否启用；项目利润会有多大影响；实施方法是否可以变更；考虑好了，和老板客户去谈，做合同变更啥的。有问题早解决，明显加班加点也不行，就别这么赶了，别把人又逼走了。
感谢邀请！题主的困境主要是资源和需求的矛盾，楼上很多知友从it项目管理角度来回答，我从纯管理的角度来回答。1. 出现这种情况，久战不利，无论对项目质量，还是对士气，如果没有合适的人来参与，建议先关闭；2. 如果无法关闭，建议想方设法调动大家的积极性，坚持一下，比如适时的奖励，户外活动，吃饭唱歌，让大家有阶段性的休整，切勿持续疲劳作战，每个阶段都有一个兴奋点，打起来才有快感；3. 项目经理重新评估一下项目进度，工作量，向上级老大申请资源，或跟客户解释申请一下延期，当然此为下策。事后一定要有总结，主要原因还是项目经理不过关，如果是新手以后就别让他担任如此重要的项目，先参与进来，循序渐进地做，项目经理的水平决定了项目的水平，尤其是管理水平，不是说业务能力强，能分工协调就是好项目经理的，还得懂得调动成员的积极性，在艰苦的条件下打持久战，是一个优秀项目经理的特质。
说下个人的一些经验（仅限于互联网）做项目其实就是一个短期的产品实现过程按步骤说下：①确认项目目的②确认需求（定版后，如无必要不可修改）③确认需求中的必须诉求和非必须诉求④和产品、设计、前端、技术、测试等互相确认相对应诉求的工期（通常工期浮动在半个工作日左右）⑤根据确认的工期设立节点⑥根据节点，多跑动，勤快点总结一句话：列出所有能想到的有可能遇到的事情，并列出相应解决办法，根据时间节点去分配一般不会出现大的误差。
楼上都说的是互联网的，楼主没有说一定是互联网行业。我原来呆过的公司就是承包项目了，没人了马上招人就很好解决了，主要核心人员在就行。}