敏捷开发:用户故事_敏捷经济学：宏伟的幻想

敏捷开发:用户故事

每个人都在谈论扩展敏捷性。 SAFe，LeSS和其他产品的认证似乎已成为当务之急。

但这不仅仅涉及认证，对吗？让我们探讨扩展的需求来自何处，以及扩展时遇到的问题。无需认证。

为什么要缩放？

规模需求从何而来？它来自大公司（可以支付证书的大预算。但是我离题了）。大公司有大型项目，有多个团队，有成千上万的人在工作。

从经济角度讲，这意味着成本越来越高，并且由于发货晚而导致收入延迟。对市场变化的React缓慢，这再次损害了企业的盈利。

公司生病了，他们正在寻找治疗方法。

但是，有这种神奇的治疗方法吗？

众所周知，逻辑与我们的决策方式有关。但是故事和信仰的影响更大。

进行扩展任务时，我们需要了解，我们在世界上有两种信念，更不用说迷信了。

有一种解决团队绩效的已知方法。它被称为敏捷，可归结为一系列过程。
这种治疗有效。
有一种方法可以“扩展敏捷性”？从团队级别到组织级别。
可以教这种方式。
升级成本很高，但值得。

当然，这些信念在我们的现实中存在两个问题。

首先，有“敏捷”的通用定义。大多数组织都不知道敏捷在工作时的样子（或在什么时候不起作用）。他们认为敏捷来自媒体，顾问和专家。（是的，包括我在内）。有足够的噪音让每个人都在做，所以显然它必须起作用。

然后是过程。不难想象如何扩大流程。但是过程与影响之间没有因果关系。这只是新流程带来的希望。事实是，组织转型是一个漫长的过程，任何“证明”？任何过程的运作都是轶事，而且非常具体。它可以被复制，您可能会在其他地方结束。

最后，采用scrum的组织（大部分）做得不好（大部分）。但是，人们认为该飞行员已经成功，并且已经为下一步做好了准备。尽管对成功飞行员的定义有什么定义，但这些飞行员注定会成功。毕竟，您通常会从最有干劲的人那里开始试点。

问题是，在现实世界中，如果您幸运地成功地实施了有助于一个团队敏捷性的流程，那么“仅实施流程”就无法消除多个团队的复杂性。而且，如果您占多数，则您的团队并不真正敏捷，放大可能真的很危险。

因此，我们知道组织为什么要扩大规模，是什么导致他们相信成功之路已经铺好。那就是需求部分。当然，有很多供应商都在卖药。

这是否意味着缩放注定会失败？不必要。

我们将继续讨论扩展规模。

翻译自: https://www.javacodegeeks.com/2016/05/agile-economics-delusions-grandeur.html

敏捷开发:用户故事