怎样才能尽早、尽快地学习？

敏捷建议团队应该快速失败从而从错误中快速学习。从失败中学习是一种途径，但是你还能从成功中尽早并尽快地学习，这可以通过做一些实验，或者通过一个知识获取计划。

在博客文章停止如此快速地失败中，Sami Honkonen 解释了为什么目标是不要失败而是要成功。

实际上，快速失败并不意味着你的目标是快速失败。快速失败非常容易。但是我们应该在尝试成功的上下文里快速失败。如果你根本没有尝试着去成功，那么你的实验根本就没有什么意义。

实验能够帮助你学习，提供成功的几率，正如 Sami 所描述的：

当我们学会有效处理错误的时候，错误就变成了一个工具。为了测试一个想法（或者一个想法中的某个假设），我们会设计一个实验并充满自信地认为这个假设是正确的，然后我们会试一试就好像已经知道了它会工作一样。如果它确实会工作，那非常完美。如果它不能工作，我们将从失败中学习。然后进行有组织地清洗和重复。

Jerry Neumann 声明说你不能从失败中学习，你仅能从成功中学习：

任何复杂的系统都过于复杂得让人难以从失败中学习。是的，你可以学习一些技巧，例如“不要将所有的金钱花费到华丽的椅子上”或者“不要雇佣你大学时的酒友作为业务发展的执行副总裁”。但是你还可以花费时间从每一个创业者过去曾经遇到的所有错误中汲取经验，即便如此，我还是会保证当你开始创建公司的时候，你还会发现各种各样的新错误…。

你应该花时间努力从成功中学习。我知道的那些成功的企业家都具有审查错误（任意错误）并从错误中找到哪些事情做的正确的能力。这些是他们关注的东西。

“我们从成功中学到的东西和从失败中学到的东西一样多，甚至我怀疑我们将学到更多” Bruce Nussbaum 说。在他的博客停止对失败的盲目迷恋中他提出了一个处理问题并进行学习的“游戏模式”：

失败通常会与问题的解决有关。这里有一个假设，那就是一个正确的问题只有一个正确的答案，如果你找不到这个答案，那你就失败了。但是如果你连问题是什么都不清楚同时又有很多方式可以处理这些问题呢？我更喜欢使用游戏模式应对这些挑战。在你玩的时候会有一些规则，但是它们会随着游戏的进行发生变化。玩一个游戏可能有不同的结果，胜利的方式也各不相同。如果有一些东西不起作用那你可以尝试另外一些。你围绕着它工作。这是失败么？我并不这样认为。

Michael Plishka 在他的博客帖子创新——它从未与失败相关中分享了自己对通过玩更快地学习的想法。他对从失败中学习的观点是：

正如 Nussbaum 在上一篇文章中所指出的，失败确实非常令人痛苦同时还可能是限制性的。术语失败有一个定局，那就是不可原谅的。当一座桥“失败”的时候，它会跌落，人们会受伤。当一个电源“失败”的时候，电流就会消失。失败是没有成功，我们并不能从空洞那里找到成功，它并没有携带任何信息。

他对从成功中学习的观点是：

成功（…）根本没有（…）任何教育意义，如果事情能正常工作，我们并不会想知道它们该如何工作。我们会像百灵鸟那样一起去快乐，认为一切都运行良好，直到事情出现了问题为止。

如果我们没有从失败中学习，也没有从成功中学习，那么我们该如何学习呢？Michael 这样写道：

我们从探索中学习，通过好奇心、笨拙的修补和实验。我们允许有“失败”和“成功”空洞的瞬间，没有学习和成长的可能。只有当我们退一步并且问“我正走向哪里？我将如何到达那里？这个事件对该旅程有什么帮助或者阻碍？”的时候，我们才有可能发生设计 / 创新。

Al Shalloway 提醒我们说，失败并不是目标，他在自己的博客文章我为什么会讨厌“快速失败”和“足够好”中建议要关注尽快学习。

无论你如何谈论它，失败都有消极含义。我们并没有打算失败，没有人以失败为傲，但是我们可能会以克服失败为傲。仅有的术语“快速失败”意味着我们并不想慢点失败——我们想要尽可能快地完成失败。事实是，我们真正的意思是要快速学习。如果我们偏离了轨道那我们要尽快地正确。我们甚至不会考虑失败的过程。抱着这样的态度，实际上我们永远都不会失败。快速失败并不是我们的目标，快速学习才是真正的目的。

你可以像 Alistair Cockburn 在他的报告如何“尽早学习、经常学习”，让我们降低风险中所描述的那样学习，而不是快速失败并从中学习，在这篇文章中他探索了如何在产品开发期间尽早地学习：

问题并不是学习不会发生在普通的方法里，而是学习来自于集成，同时还会在销售的时候再次发生。我们通常会要求团队成员在第一时间将各自的想法放到一起，让客户、用户、购买者可以在第一时间看到新的系统。

他提到，为了减少开发期间的奉献我们需要获取四个方面的知识：

• 要构建的正确事情是什么？
• 开发它需要消耗多少成本？
• 团队是否有足够的人员，他们如何才能最好地在一起工作？
• 他们技术理念的缺陷在哪里？

为了支持尽早地学习，项目计划中需要包含活动。Alistair 介绍了活动对项目计划的影响：

旧的风格依然会被频繁地使用，项目计划是构建系统所需要执行的那些任务的一个列表。这种类型的一个有效的、快速的、低成本的计划方法是“Blitz 计划”。这个传统的项目计划还提供了一个良好的起点，能够让我们提前清楚与系统开发相关的内容，提供成果的近似大小和困难。

较新的敏捷风格的项目计划会将所有的功能特性或者用户故事简单地放到一个单独的列表中，通常会把具有最高业务价值的条目放在列表的上面（看看上面的原因，这可能并不是放置它们的最优顺序）。

相对而言，获取知识的途径开始于对需要获取的四类知识的头脑风暴以及开始需要交付的特性集合，为此你需要付出百分之二百的努力。为了降低风险、传递至关重要的信息并且按照“最优”的方式开发产品，我们可以对工作分配的序列做一些巧妙的交叉。

为了尽早地、快速地学习你做了什么呢？

查看英文原文： How Can You Learn Early and Fast?