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

敏捷开发:用户故事

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

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

为什么要缩放？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷开发:用户故事