我们都知道软件开发有风险。我们在用不确定的一套需求并在非常紧密的时间表内创造着新事物。在这之上，我们还不得不担忧未知的依赖性、突发的市场变化以及人员的轮换！We all know that software development is risky. We’re creating something new, with an uncertain set of requirements, in an often-tight timeframe. On top of that, we have to worry about unknown dependencies, sudden market changes, and personnel shifts!
那么这也难怪许多人相信没有某种方式的风险管理策略，他们闪亮的新项目，还有声誉，很快就会受害。这就是困惑点。如Scrum和看板的敏捷框架根本没有显式地提到风险——因此敏捷组织应该在敏捷框架之上实施一套正式的风险管理流程吗？回答是以前，考虑一下。It’s no wonder then that many believe that without some sort of risk management strategy, their bright and shiny new project will tarnish quickly, along with their reputation. And this is where the confusion sets in. Agile frameworks like Scrum and Kanban don’t explicitly mention risk at all—so should agile organizations implement a formal risk management process on top of their agile framework? Before you answer yes, consider this.
敏捷是风险管理AGILE IS RISK MANAGEMENT
我在写Essential Scrum（译者注：此书已有中文版《Scrum精髓》）一书时，我不断地问自己，“风险管理需要单独一章吗？”实际上我给出版商最初的大纲里有风险总结的章节。 book, I kept asking myself, “Do I need a separate chapter for Risk Management?” In fact the original outline I gave my publisher identified a Risk Summary chapter.
最后，我决定拿掉风险的概念，这样敏捷的基础是有关风险、随机性、易变性和可变性的讨论，这些内容已经交织在其他章节。关于风险管理单独一章，即使是风险总结的章节，可能都会给出错误的信息——敏捷开发需要一套严格定义好的、文档驱动的和重量级风险管理流程，因为在传统项目管理流程中通常都有风险管理的定义。但敏捷中没有。In the end, I decided that the concept of dealing with risk is so fundamental to agile that the discussion of risk, randomness, volatility, variability, and uncertainty was already woven into the other chapters. It also became clear to me that a separate chapter on risk management, even just a summary chapter, might actually send the wrong message—the message that agile development requires a formally defined, document-driven, heavyweight risk management process as is typically defined in traditional project management circles. It doesn’t.
事实上，我认为存在重量级风险管理流程，是一个公司未能拥抱敏捷精髓的指标。In fact, I believe the existence of a heavyweight risk management process is a good indicator that a company has failed to embrace the essence of what agile is.
我不是说在某些领域（如起搏器或其他救生设备）我们不用比其他领域（如创建简单的网站）更加关注识别风险和降低风险。我们应该关注的。然而，记住许多重要系统的风险可以通过正确应用敏捷原则内化的风险管理来解决。I’m not suggesting that in some domains (e.g., developing pace makers or other life saving devices) we shouldn’t put more of a focus on risk identification and mitigation than in other domains (e.g., creating simple websites). We should. However, keep in mind that many of the risks on mission-critical systems can be addressed using the risk management that is inherent in the proper application of agile principles.
最近我做了一个名为敏捷是风险管理的演讲详细描述了这个话题（还有这个系列博客）。你可以从这里下载演讲稿。I recently delivered a presentation entitled Agile IS Risk Management that explores this topic in detail (as well as the material in the rest of this blog). You can download that presentation here.
敏捷风险管理的三个方法THREE APPROACHES TO AGILE RISK MANAGEMENT
我已经识别出三种方法，为组织处理产品开发固有的不确定性提供坚实的基础，而不论是哪个领域。I have identified three approaches that give organizations a solid basis for dealing with the uncertainty inherent in product development, no matter their domain.
- 适当的时候，用最简方式采用最小的传统风险管理技术。当失败威胁生命以及有一个很好的理由相信风险管理有帮助时，组织可能就采用更多的传统风险管理技术。When appropriate, use minimal traditional risk management techniques in the simplest possible way. When failure threatens lives, and when there is a good reason to believe it would be helpful, organizations may employ more traditional risk management techniques than in other situations.
- 坚持核心的敏捷原则会避免内在的风险或不确定情况的自我创造。换句话说，以敏捷的方式工作（译者注：只按照敏捷的方式做事而不理解敏捷原则），我们只是可以避免确定的情况。例如想要避免固定价格合同的风险，那么就不要签订固定价格的合同！Adhere to core agile principles to avoid the self-creation of inherently risky or uncertain situations. In other words, by working in an agile-like way, we can simply avoid certain situations. For example, if you want to avoid the risks of fixed-price contracts, then don’t enter into fixed-price contracts!
- 运用敏捷原则可以使开发流程强韧以及偶尔对不确定事件的反脆弱性。换句话说，采用敏捷避免了伤害以及不需要重量级风险管理就可以从不确定性中受益。是的，刚刚我说的是风险（我更愿意称之为不确定性）有其益处，我们可以也应该拥抱风险。（我从塔勒布的《反脆弱》一书中借用了强韧和反脆弱的概念。在后续的博客中我会定义并使用这些名词。）Apply agile principles to make the development process robust and at times antifragile to the disorder of uncertain events. In other words, use agile to avoid the harm and reap the benefits of uncertainty without the need for a heavyweight risk management process. Yes, I just said that risk (I prefer to call it uncertainty) has an upside that we can and should embrace. (I also borrowed the concepts of robust and antifragile from the book, Antifragile: Things that Gain from Disorder, by Nassim Taleb. I will formally define and apply these terms in a future blog post.)
很好的讨论这三个方法对一篇博客来讲太长了，那么我会写一个系列博客来说明不确定性以及这三个方法。下一篇博客会定义不确定性的心智模型，这为其他话题的讨论提供了基础。Since a good discussion of all three approaches would be unreasonably long for a single blog posting, I will create a series of blog postings to address the topic of uncertainty and to detail these three approaches. The next blog in this series will define a mental model for uncertainty that will provide a foundation for discussing the other topics.