您知道敏捷中是如何尽早识别风险的吗？

“任何可能出错的事情，都将出错。”我们都听过墨菲定律的含义。我们很多人都曾经讲述过墨菲定律，但是很少会有人表现得对此而担心。

    为可能出现的问题做好准备的一个有用技巧是进行“预分析（pre-mortem）”。这是一个在项目或版本开始时召开的会议，干系人在会议中识别所有可能影响成功交付的问题。“预分析”这个名称来自于项目“后分析（post-mortem）”——一个在项目结束时召开的会议，干系人可以从刚完成项目的成功和失败中吸取经验教训。在项目结束时进行经验教训总结是件好事，但它只会对后续项目有益，对项目自身并无半点用处。“预分析”试图将这种学习行为转移到项目之初，要求干系人一开始就考虑在项目过程中可能出现的所有问题。对于敏捷团队来说，“预分析”是源于“冲刺回顾会议（sprint retrospective）”工作的另一种端，但其覆盖整个项目或版本，而不是单个冲刺。由于其与迭代回顾的这种关系，导致其有时被称为“未来展望（future spective）”或“预展望（pre-spective）”。

谁该参加？

    一个成功的预分析应该聚焦于任何可能影响项目成功的事情上。这就意味着您应该邀请任何可能有助于识别或解决这些问题的干系人。这往往意味着您的邀请人员不会仅限于开发团队、产品负责人、Scrum Master或敏捷教练，还应该邀请用户、项目发起人和其他相关团队的代表。此外，还可以考虑包括那些在产品一致性和完整性方面扮演重要角色的人员，比如架构师、设计人员和数据库工程师。

如何实施预分析

    通常情况下，由Scrum Master或敏捷教练来为敏捷团队主持和引导预分析会议。主持人在主持会议时应该采取三个步骤：首先，鼓励参与者列出项目可能面临的所有可能问题。这通常会导致列表中有太多事项，以至于无法有效地处理每一个。所以第二步是进行优先级排序，把问题范围缩小到Top10。在最后一步中，参与者要确定Top10问题的解决方案。接下来，让我们详细探讨每一个步骤。

第一步，头脑风暴出所有潜在问题

    预分析的第一件事情是：让会议参与者想象他们当前所处的位置与项目成功交付之间的每个障碍。如果有一个截止日期或目标日期，那么还要考虑达成这个日期可能会存在的障碍。第一个开放问题可能会是：“什么可能会阻止我们在未来90天内成功交付这个项目?”根据过去的预分析经验，我能列出可能导致延期的一系列潜在障碍，例如:

关键资源被从项目中调走了。
当我们有疑问时，客户不能快速响应。
新硬件设备无法在承诺时间点拿到。
四位新雇员的工作效率不像我们计划的那么快
飓风季节迫使我们办公室关闭一周
管理层并没有信守承诺，没有把我们排除于其他非关键工作之外。

    在极少数情况下，团队很难列出一份潜在问题清单。我发现有一个有用的方法是：让参与者想想他们正处于未来产品已经成功交付的时刻。然后，我会问：为了实现成功的未来，我们必须顺利进行哪些工作？

这会产生一份相同的清单。虽然只是换了一种不同的思考方式，但对某些团队来说却是有帮助的。

第二步，选出Top10

    主持人需要在某个适当时刻结束头脑风暴。我建议头脑风暴的时间不要超过一小时。在多数情况下，头脑风暴的时间会远小于一个小时。一个有经验的会议引导者知道什么时候创造力已经消失，会最后问几个结束提示问题，然后结束头脑风暴。有了完整的候选问题列表后，您现在需要将范围缩小至阻碍成功交付的Top10障碍。

有很多方法可以把完整列表缩小到10个。例如，您可以浏览列表，要求对每一项是否属于前十项进行表决。在第一轮投票后，看看有多少进入了“最想要的清单”，然后通过后续投票将其缩小到10个。

    我最喜欢的方法是浏览列表，并将问题项移动到三种类型上:

绝对不在Top10
可能在Top10
绝对在Top10

    如果面对面开会，通过把每一个问题项(写在卡片或便利贴上)移动到三堆上里，您就能很简单地完成这项工作。如果在线上开会，我喜欢使用任何看板类工具来完成这件事。我会为上面每个类创建一个单独列，然后大家一起将卡片移到这些列中，如下图所示。持续遍历所有的问题项，直到“Top 10”列或堆中只剩下10个问题。

如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的， 都可以加入我们
，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！

第三步，识别风险的触发条件并制定应对计划

    第三步，也是最后一步，是决定如何处理Top10问题。对于每个潜在的障碍，小组集体识别:

触发条件
缓解策略

    触发条件是启动风险缓解策略的信号。例如，上面确定的一个潜在问题是“新硬件设备无法在承诺时间点拿到”。触发这种情况的可能是以下任何一个：

截止9月18日，硬件还没有完成安装或不可用
供应商预计交货日期为9月4日或更晚
截止8月1日，采购订单仍没有提交

    以上触发条件要按严重程度进行排序，缓解策略应与触发条件的严重程度相一致。

例如，如果您在9月18日之前没有可用的硬件，这就会成为一个真正的问题。缓解策略可能是让IT组(或任何安装硬件的人员)在周末加班完成安装。

    另一方面，如果采购订单没有及时提交，缓解策略可以更简单点：直接用信用卡下单采购硬件并给与报销，或者支付加急运费。

监控风险

    仅仅识别项目中可能出现的问题是不够的，您必须密切关注这些问题是否真的会发生。这就是触发条件的作用。

识别触发条件是有用的：它简化了对这些主要风险的监控。与其去揣测是否该让某人采取行动，还不如事先就确定行动事项及其具体触发条件。

    为了进一步监控预分析中识别的风险，您还可以创建一个风险燃尽图，并每迭代更新一次。

您有何经验？

    您有何项目预分析的经验？您做过预分析吗？或许您称其为别的什么活动。您的预分析对识别和避免项目风险有帮助吗？欢迎在下面的评论区分享您的观点。

作者： Mike Cohn

翻译：李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训

原文链接：https://www.mountaingoatsoftware.com/blog/use-a-pre-mortem-to-identify-project-risks-before-they-occur