五个为什么是一项流行的根本原因分析技术。很多人在敏捷回顾中使用这项技术。对于敏捷团队来说这是一项适当的技术吗？我们有更好的替代方案吗？
John Allspaw 是 Etsy 技术运维高级副总裁，在他的博客《无休止的为什么》中提倡抛弃五个为什么这一方法。他说，使用五个为什么是迈向真实根本原因分析的良好开端，但是一直问一去就会怪罪到人的头上了。
为了充分地了解（这应该是回顾或者事后调查的目标），你需要多种不同的视角。你可以请大家谈谈自己的经历以获取这些信息。你现在正在问的“为什么”就是一种比较有效的方式。
问“为什么”的时候很容易让你得到“谁”（这通常与主题并不相干）怎么怎么样了的答案，或者把你带入建立奖励激励机制的“神秘的”之地。
问“如何”可以使你得到（至少部分）事件发生的条件，并提供给你丰富的运行数据。
在 ARMS Reliability 的博客中，针对五个为什么有以下批判意见：
- 有一种趋势是调查者更重视症状的解除而不是纠缠于低层次的根本原因
- 无法超越调查者当前的知识水平，无法找出他们尚不了解的原因
- 调查者得不到有效的支撑，帮他们问出适当的“为什么”
- 结果不具可重复性，不同的人针对同一个问题回答五个为什么时会得到不同的原因
- 倾向于把问题隔离成一个个单独的根本原因，然而每个问题可以抽取出许多不同的根本原因
- 用线性交流方式考虑通常是非线性的事件
第一个故事
第二个故事
人类出错可视为故障的原因
人类出错可视为是由组织内部更深入的体制缺陷导致的
大家应该对故障给出合理的解释
大家没必要解释做这些事情的理由
告诉大家要更加地小心仔细，避免问题
只有不断地找出组织缺陷才能使组织变得更加地可靠
John 分享了他在纽约 Velocity Conference 的教程中举的一个例子。
- 一次新的发布后客户的一个功能不好用了。为什么？因为一个特定的服务器宕掉了。
- 为什么服务器宕掉了？因为错误地使用了某个子系统。
- 为什么会用错这个子系统？因为那个工程师不知道该怎么用才是正确的。
- 为什么他不知道？因为他从未接受过培训。
- 为什么他没参加培训？他的经理认为新的工程师们没参加培训的原因是他和他的团队都“太忙了”。
这条因果链成功地归结到个人的原因，并未说明使类似于此类事件发生的多重条件。
John 说当我们问“如何”时，我们要的是叙述或故事。在这些故事中，我们了解大家是如何开展工作的。在《人类出错背后》一书中，针对人类出错给出两个故事，“第一个”故事和“第二个”故事截然不同：
John 在上面所说的这五个为什么的例子中，问出的问题限制了回答者，那么我们得到与第一个故事相类似的答案。如果我们问出更多、更好的问题，比如“如何”，我们就有机会得到与第二个故事相类似的答案。
John 的教程告诉了你为什么“五个为什么方法”并不是最优的，并给出了替代方案，那就是“五个如何”的方法。它包括四部分，每部分 45 分钟，可以点击以下链接查看。
第二部分 – 任务简报、因果关系、案例研究的用语以及团队对复杂度的处理
第三部分 – 动态管理、提示性任务简报、数据的收集和语境化、原因的构建
第四部分 – 泰勒主义、正常工作、车内软件缺陷的 **“根本原因”**、问答
查看英文原文： Limitations of the Five Whys Technique in Agile Retrospectives
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论