项目管理 | 存在发布风险的2个案例

案例一：
【案例背景】
我们的迭代周期是2周，每双周迭代结束周的周二为发布窗口，发布完成，迭代结束。其中一个需求被评估一个迭代可以完成，但是接受此需求的同学是入职4个月的新同学，对系统一些复杂功能的了解还不够深入，导致评估不到位，周四早会reivew进度时，评估到开发进度延期，于是申请了周末1天的加班。总共14个接口，周末只完成了7个接口的联调，周一还剩下7个接口未完成联调，所以余下7个接口的联调和自测，周一一天需要完成，并且第二天需要回归和预发验证。
从以上现状看，按照常理是测试通过发布的可能性很小，但是恰恰遇到一个新加入团队的测试，不靠谱的评估为测试通过，当天发布上线，第二天产品接受到来自现场的问题，于是再次验证部分功能，发现3个较为明显的线上问题。

【结论】
发布前一天还在联调和测试的需求，务必终止发布，如果此时测试下定论可以发布，项目经理也必须要抽检一下测试质量，确保没有显而易见的缺陷，才能同意发布上线。

案例二：
【案例背景】
类似上述案例一的情况，一个需求评估下来，需要一个迭代周期才能完成，周五上午提测，周五完成了一部分的功能测试，周一完成一轮功能测试，但是功能测试未通过，还存在较多必须修复的3级问题。周二继续BUG修复和回归测试，问题持续不断的被发现和验证，功能测试一直未通过，临近8点，才完成所有BUG的验证。这种情况下可以发布吗？

【结论】
不行，修复了一系列的BUG之后，如果没有再次进行核心场景的回归，很难保证说BUG修复没有引起新的问题，发布是存在风险的。不可以同意发布。