在今年早些时候的有影响力的敏捷领导者研讨会上，我主持了有关扩展以及您如何思考的会议。 我介绍了该主题，并解释说“缩放”可能不是答案。 我的经验是，当人们使用框架进行更大的努力时，他们会遇到以下意想不到的副作用：
- 框架动作通常需要更多的经理型人员来控制其他人的动作。
- 该框架产生的吞吐量更少，而不是更多。
一位参与者问：“但是我们要扩大规模怎么办？”
“不得不？” 我问。
“我们的经理认为这是摆脱当前问题的唯一途径。”
好的。 请注意，管理层定义了此问题的解决方案，而不是考虑整个系统。 或者，管理层没有考虑他们如何到达那里。
我问参与者，经理们在决定扩大规模之前是否进行了追溯或对根本原因进行了任何调查。
他说他不确定，但是他怀疑他们不确定。
我问是否有任何团队成功地在团队级别使用了敏捷方法。 不，他们都没有。
我的第一次扩展经验
我放学后的第一份工作是为国防部开发大型电信系统。 我们实施了无线，广播，相当于网络研讨会的各种方式。 早在1977年。
当我开始该程序时，我们有数百人参与该程序。 我们只落后了10-12人年。 有一次，大约一两个月的时间，我问老板：“为什么我们现在不雇用这些人，而当他们有用时，他们就可以“补足”时间？”
他叹了口气。 “我们尝试过。 这就是为什么你们所有的新毕业生都在这里。”
六个月后，我建议：“让这个计划让150人受益。 我所做的就是撤消他们做错的工作。 他们没有所需的信息。 如果我可以选择这个团队（我任命了大约十二个人），我会更快得多，而且我们一个人工作。”
我的老板向后靠在椅子上。 “其他人会怎么做？”
“没关系。 付钱给他们不上班。 我们会更快。”
我的老板不喜欢那样。 即使我向他显示了一些延迟，他也不喜欢。
我没有延迟成本或流量效率的说法 。 我不知道如何绘制周期时间。 我知道，如果我们不必移交，我们会更快。
甚至在1977年，我们就按功能集工作。 是的，垂直切成薄片。 我们继续进行整合。 我们取得了进步。 而且，在我在那里的18个月结束时，我们现在落后了30个人月。
我们在切换和周期时间延迟方面都存在缩放问题。 当然，我们当时使用纸张来管理我们的需求，但是我们仍然无法使信息保持最新。
我现在看到的扩展问题
通常，管理层决定需要扩展，因为他们希望“事半功倍”。 如在更少的时间。
或者，管理层推迟了该项目的启动，因此他们想“花些时间”。
有一种不使用扩展即可解决这些问题的简便方法：使用一两个小组来解决排名积压的订单。 确保您以“ 多少 ”而不是多少来考虑积压。
“太多时间”通常是管理抖动的结果。 或没有看到延迟。
然后是实际的大努力问题。 我们也许不可能开发出电信系统12人。 那还没回来 也许现在还没有。 十二个人没有足够的领域专业知识。 但是，我们可能会将人数限制在50至60之间，而我们的完成速度会更快。
但是，我从事大型程序的开发，这些程序的团队很小，我们的控制人员很少，控制点也很少。
这是我将伸缩作为答案，敏捷方法或其他方式时遇到的问题：
参加该计划的人可以在以下情况下组织自己：
- 团队了解领域。
- 团队了解客户的问题。
- 他们可以自己部署/释放。
- 他们（或了解客户需求的人）对工作进行排名。
这些团队可以使用小型世界网络方法来管理和交付工作。 （我在“ 敏捷和精益计划管理”中做了解释 。）
我向这些同事提出了这些想法。 他说：“管理层永远不会这么做。 他们仍然想控制事情。”
敏捷扩展是解决谁的问题的答案？
当我听说扩展框架时，我想知道谁是客户。 我非常确定，框架是想要敏捷方法结果的经理的答案。 但是，这些管理人员通常不想以敏捷方法改变自己并改变文化。
更多的控制器和更多的控制点不会创建敏捷文化。 或者，往往是产品达到管理层想要的结果。
当我听到“我们必须扩大规模”时，我想知道“我们”到底是谁。 我想知道他们想要从扩展中获得什么。
敏捷的“扩展”很少能解决组织的问题。 通常，它正在除垢。 帮助经理可视化周期时间可能是第一步。
不久前，我写了一系列有关敏捷扩展的文章。 您可能想要阅读它。
翻译自: https://www.javacodegeeks.com/2019/06/when-agile-scaling-answer.html