你是否曾经参与过范围或需求定义糟糕的项目？如果一个项目已经有大量的技术债务或者有你以前从未使用过的技术怎么办？如何处理团队、平台、时区、甚或是上述所有方面的依赖关系？作为一名敏捷教练，我会经常遇到所有这些类型的挑战。现代软件开发的现实是我们每天都会面对这些挑战，而及时降低风险的技巧使我们仍然可以以一种及时且可持续的方式为用户创造最大的价值。亲爱的读者，我听到了你们的问题，我们如何才能实现那个目标呢？我没有银弹，但我确实有一种系统方法，可以帮助你们更及时地处理风险。

风险和敏捷

为了能够准确地计划我们的工作，并能够在一个合理的时间段内交付工作，对于敏捷计划和评估（关于这点，任何类型的项目皆是如此），我们有多个类型的风险必须了解。根据我的观察，在任意一项工作中，最常见的风险类型通常可以归结为以下几类：

需求风险：例如，故事定义糟糕，工作范围/故事很大（通常，任何一个用户故事都有大量的验收标准），或者对客户价值/优先顺序缺少了解；

实现风险：例如，使用新的或不熟悉的技术，处理遗留代码库，缺少流程/自动化测试，或者其它技术债务；

依赖风险：例如，任何跨团队/产品/平台的依赖关系，跨（多个）时区工作，或者任何外部依赖关系，如客户、合作伙伴或者外包开发。

你说的好极了，现在我们有了一些常见的风险模式，但我们能用那些信息做什么呢？我们对风险有了很好的理解，但如果我们不能及早识别风险，然后落实某种规避计划，那么我们最终的状况将和现在一样保持老样子。接下来，我们需要落实一些方法，帮助我们在“发布计划（release planning）”过程中及早识别风险。

发布计划

（点击图片查看大图）

发布计划图——复制许可来自© 2011-2014 Scaled Agile, Inc. All rights reserved

计划多个迭代的概念并不复杂。大规模敏捷框架已经针对（但未提交）多迭代为我们了解工作设计了一个很棒的可视化系统，并且在凸显更高级别的工作风险方面做的不错。这个迭代映射的输出是未来五个迭代的工作的一个粗略的计划，该计划基于先前的速度和团队能力将故事映射到迭代，让我们对未来的迭代输出和可能获得的故事有一个不错的构想。

需求实现依赖（RID）风险

在这个迭代映射的过程中，我们可以推敲目标故事（在逻辑上最近开始的），识别需求风险、实现风险和依赖风险（RID）的风险级别，对于任意一个故事，均简单描述一下我们是否面临着或高、或中、或低的风险。这有两个影响：首先，它会影响评估，因为风险更大的故事自然会被估计得更大（高风险会降低产出）；其次，我们了解了风险级别后就可以设法降低风险。

在发布层面，我们可以基于识别出的风险类型——需求、实现或依赖——做许多事情：

针对需求风险，我们也许可以将故事分解成多个部分，保证工作优先级有良好的定义，而且这个优先级应该在整个过程中不断的进行完善（例如，使用MoSCoW系统，故事映射，或者获取一个功能优先级），并设法保证我们正在处理的用户故事定义良好——它们描述向谁交付价值，交付什么价值以及我们为什么想要交付那种价值了吗？它们是符合INVEST模型的好的用户故事吗？解决这些问题有助于消除需求风险。

针对实现风险，我们需要了解现有问题：我们正在处理大量的技术债务吗？如果是，在开始另外一项工作之前，我们要努力减少债务吗（在这种情况下，技术债务故事将在我们的待办事项列表上进一步上移）？对于新技术，我们需要引入“探究故事（spike story）”以便理解如何进行并做出最佳决策吗（在这种情况下，我们可以增加探究故事，并将实现风险高的故事向后推，直到风险降低）？

针对依赖风险，我们需要了解依赖的类型和产生的原因。为了降低依赖风险，可以使用另外一种方式划分工作吗？可以使有依赖关系的团队更高效地合作吗——例如，留出专门的时间用于团队合作？我们需要将某个故事进一步推迟，以便其前继故事能够得到专心处理并在我们开始工作之前完成吗？如果我们在等待合作伙伴或客户，我们如何保证能及时获得我们需要的东西？我们越早提出这些潜在的障碍，就越可能获得一个令人满意的解决方案。我们需要确保我们与合作伙伴和客户的合作尽可能的高效。

在发布计划阶段识别出所有这些风险可以为我们提供更长远的眼光，我们可以据此调整我们的计划，并引入降低风险的办法。然而，我们的工作性质不是静态的，需求自然会随着时间发展变化。在发布计划层面上做的这些工作是其中的一部分，但我们还需要比这个更经常地考虑风险。在迭代计划阶段考虑就太晚了，因为在那个阶段，我们实际上已经投入到工作中去（没有时间去降低风险了）。那么让我们进入待办事项梳理会议。

待办事项梳理

在迭代计划阶段，有几个我在敏捷团队中经常遇到的问题：

• 故事定义糟糕（尤其是验收标准）
• 故事有太多或太复杂的依赖关系
• 故事过大
• 故事难度增加（引入新技术或新增团队成员）
• 团队被过度使用（由于诸多因素的影响）
• 对于需要完成的工作糟糕的理解

准确指出这些问题背后的哪怕一个因素也是不可能的，但在计划之前检查需要完成的工作有助于我们面对这些问题中的一部分，即使不是全部。待办事项梳理是一个检查工作及减少这些问题的机会。

对于做这项工作的团队而言，待办事项梳理是一个发生在迭代中段某个节点上的一次会议。其想法是让团队展望就要进行的工作，并确保它已经准备好，可以添加到我们的迭代待办事项。我们如何知道工作什么时候准备好？当满足我们的就绪定义的时候。因此，在这个会议中，我们在一个相对细粒度的层面上检查每个故事，确保RID风险因素都是低（或者勉强是中等）风险的。

我遵循的工作流程大致是这样的：

1. 产品经理向团队粗略地介绍按照优先级顺序排序的待办事项（直觉上，大约一个半迭代的工作似乎是最理想的）；
2. 从优先级最高的故事开始，将RID风险等级分为高、中、低；
3. 对于任何高风险的故事，识别风险原因，然后努力降低风险（按照前文的描述）。对于风险无法降低的故事，要么引入一个任务项，并在下一个迭代开始之前执行，要么重新排定优先级；
4. 重复上述过程，直到所有故事满足DoR（如果它们很可能包含在接下来的冲刺中）；
5. 作为一个全面检查，确定故事大小（如果故事太大，那么可能有一些风险因素没有考虑到）。

RID工作流程图——Boost Agile

如果我们在开始迭代计划的时候遵循这个工作流程，那么团队不仅对将来需要完成的工作有一个很好的理解，而且对于我们而言，团队也会处于一个理想的状态。这使得产品经理对优先级更加确定，意味着他们可以就面临的任何问题与干系人、客户等等进行更加有效地沟通。遵循这个工作流程还能极大地增加计划的精确度，使团队在实现迭代承诺方面觉得更自信。简单的会议，巨大的收获。

下一步

希望现在你已经看到了对承担的工作进行风险评估的价值。虽然RID可能不是对每个团队而言都恰好合适（你对自己所面对的风险的理解应该比我更好），但有一个线程的过程，确保你只接收高质量、定义良好的工作加入待办事项，这有助于我们实现一个更加可靠且可重复的流程。

从团队的角度来说，高质量的工作意味着他们在实现迭代承诺方面更自信，处理质量差的工作所带来的挫败感减少了。从产品经理的角度来说，他们可以在与团队共同制定的计划中找到更多信心，对团队面临的风险有更多的了解，对与业务人员和其他干系人共事所必须的长远计划更有信心。最重要的是，团队和产品经理有一个共同的理解，这对培养一个高效团队是不可或缺的。

我们花了很多时间去思考，如何为开发团队提供支持，确保他们可以开发出高质量的产品，但没有花足够的时间去思考，如何为产品经理提供支持，确保只有高质量、高价值的工作才能达到团队。这是一个正确的前进方向，为什么不今天就迈出这一步呢？

关于作者

Jacob Creech是一名敏捷教练兼培训师。他是总部位于中国上海的Boost Agile的联合创始人。这是一个为亚太地区的组织提供支持服务的敏捷培训与辅导组织。他还是上海敏捷与精益创业用户组的创始人。作为一名生活黑客狂热分子，他总是在寻找（和创建）更快更高效的工作方式，而且他是生活全方位敏捷的支持者，其写作和应用敏捷的领域已经同“乒乓球与摄影（Table Tennis and Photography）”一样多样化。

查看英文原文：Getting RID of Risk with Agile

转自 http://www.infoq.com/cn/articles/get-rid-risk?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global