本文章转载于搜狗测试
周六送福利已经进行三期了，现已到尾声，大家还记得我们约定的四个阶段吗：
“项目进度”尾篇：不慌不忙应对突发状况
引言
前几个周六，我们了解了怎么做项目计划，但是执行过程中，除了在项目前期尽可能的预估并屏蔽所有风险以外，总不可避免的仍然会出现计划变更，突发风险，突发任务，该怎么处理呢？该怎么处理呢？该怎么处理呢？（重复三遍以形容我心乱如麻）
项目中，接触计划变更，突发风险的第一线人员是模块负责人，因此，模块负责人对突发状况的处理直接关系着进度能否合理delay，抑或连滚带爬的保持正常，以下主要从两方面对这个问题进行讨论
① 当模块负责人意识到计划变更以及风险
② 项目负责人接到突发任务
项目计划变更和突发风险
执行项目期间，进度和质量是整个测试组的最重要的两个指标。模块负责人在执行任务的过程中，如有对项目进度产生影响的问题（影响项目进度的问题），应该第一时间主动进行推进，并将推进结果同步项目负责人
模块负责人说坑：怎么判断什么是影响项目进度的问题？
小编曰：分三个阶段来说
第一， 一轮测试执行时，虽然时间充裕，也应把握前紧后松原则，如遇到下面的问题，应引起足够的重视并立即进行推进，千万不能等着，否则到后期只能是压缩测试时间（若推进无果时，可反馈给项目负责人）。另外，对于影响进度的问题则第一时间同步项目负责人，以便及时调整计划
①阻塞模块负责人继续执行任务的（有其他任务可以置换的略过）
例如：未提测的；阻塞bug导致不能继续执行的；没有需求文档的；没有设计图的，……
②有风险可能导致模块负责人执行任务不顺利的，会拉长测试周期的，
例如：分批提测（因为分批测试完后，还需要时间将分批的功能进行联调测试）；bug修改影响范围很大的……
③任务进行三分之一时，实际进度和预计进度不符（说明delay原因与后期的方案安排）
第二，回归测试执行时，测试人员对于bug的判断角度和产品可能不一样，但是bug是否修改是以产品为准，因此，对于不能准确把握的“是否修改的问题”应第一时间与产品同步，如需修改，再及时同步给项目负责人，以便及时调整计划
第三，回归测试阶段应属于稳定阶段，严格把控此阶段修改的bug带来的影响，如影响范围较大的，引发新问题的，应该第一时间告知项目负责人（bug修改范围太大可能导致回归范围变大，已经完成的入口测试重新回归），再向项目组人员同步
突发任务
模块负责人的突发任务一般来自于项目负责人，项目负责人说：好不容易和大家核对好各自的任务，刚才开发（产品）说要修改个逻辑，然后。。。又被打乱了
小编曰：
执行项目期间，由于各种原因，可能临时插入其他任务
例如：紧急修复线上问题，后台优化接口等等。当项目负责人接到如下任务时，建议从以下3方面着手
1. 先了解需要提测的是什么事情
2. 了解提测这个功能的目的（解决什么问题？为什么突发而不是顺延进行排期）
3.如是早有计划的任务，和对方约定，提前多长时间告知测试以便测试同学排期
4.和对方咨询事情的优先级，并和手头上的事情的优先级做对比
5.评估优先级后，想出后续的解决方案并和leader同步；如不能确定优先级的，则和项目组人员（产品leader，开发leader）进行确认，再同步leader
①如果可以插入该临时任务，需要和项目组人员同步正在执行的任务会出现相应的delay，并同步更新进度列表并公示项目租
②如果顺延该临时任务，则需要和项目人员同步该任务的预计执行时间是哪天，以及完成时间是哪天
结语：如果是正常版本的迭代，可将第一个版本在执行期间出现的突发状况一一记录，在第二个版本前期排粗略计划时提前进行规划也是减少突发的一种方法
写在最后
祝大家周末愉快~
