作者|MaartenDalmijn

譯者 | 王強

策劃 | 蔡芳芳

我必須承認：我從未見過有哪個大規模 Scrum 框架獲得了成功。不過這並不是說我已經見過了現實中所有的大規模框架。我非常懷疑世界上是否有什麼人對所有這些框架都有著深入而全面的經驗。

本文最初發佈於 Medium 網站，經原作者授權由 InfoQ 中文站翻譯並分享。

每隔一段時間我們就能見到新的大規模框架面世，感謝上帝，這個領域出新的速度好歹比 JavaScript 框架要慢一些。如果你就是那位對所有大規模框架都有實踐經驗的天選之子，請與我聯絡，我想向你學習。

儘管我已經熟悉了許多大規模框架，但沒有一次實踐經驗是正面的。多年來，在引入大規模框架的過程中我遇到了許多挑戰。我寫這篇文章是為了表達這些擔憂，並分享一種更好的方法幫助大家思考組織擴充套件的主題。

這個指尖陀螺的風潮我就一直沒搞懂

並不是只有我才對大規模框架持保留態度。當 Jeremiah Lee 發表了他揭穿

Spotify

模型有效性的帖子後，我真的鬆了一口氣。到頭來總算有人提供了具體的證據，告訴大家為什麼這個框架那麼受歡迎、廣告打得那麼好，可就是沒啥用。

Jeremiah 的帖子和我對 Spotify 模型的個人體驗是一致的。我個人見到它被採用就有幾次了，但我從未見過它產生了什麼積極的影響。

它也不是唯一一個受到嚴厲批評的大規模框架。Stefan Wolpers 證實 Scaled Agile Framework（SAFe）實際上在從業者中具有負的淨推薦值。簡而言之，這意味著在 SAFe 環境中工作的專家會積極阻止其他人採用它。竟然會這樣！

我曾在多家使用各種大規模框架的公司工作過。所有這些框架都引入了不必要的複雜性，讓事情變得更糟。我所看到的只是一大堆佔據上風的繁文縟節，而實際問題卻被掩蓋了。大規模框架往往不會解決問題，而只是在保護現狀。它們具有破壞性，讓人們懶惰成性，使組織走上平庸之路。

於是我提出了以下問題：

為什麼大規模框架在實踐中往往不能解決它們承諾解決的問題？

好吧，我不相信這個問題有一個單一的、簡潔的答案。但我確實相信有幾個重要的因素加在一起可以解釋，為什麼許多大規模框架在設計層面就註定要失敗。

1

堅持讓框架成為所有問題的預設解決方案

採用大規模框架後，組織的注意力就要從解決我們遇到的問題轉移到遵循框架規則上。這裡面的邏輯是，如果我們在引入大規模框架後仍會遇到問題，那麼我們在實現框架的時候一定做錯了什麼事情。

我們相信廣告詞，自然也就認為框架提供的解決方案肯定是有效的。我們並沒有追根究底，保持好奇心，而是死盯著一個問題：“我們在實現大規模框架的時候做錯了什麼？”因此，我們提出的所有解決方案都侷限在框架裡面。我們忽略了一種可能性，那就是這個框架可能並不足以解決我們的問題。

公平地說，許多 Scrum 團隊都面臨著同樣的問題。他們關注的並不是如何才能更好地交付價值，而是如何更好地執行 Scrum。可是 Scrum 的執行從來都不是重點所在。請記住，大規模框架之類的 Scrum 都只是達到目標的一種手段，而非目標本身。

Scrum 的目標是幫助你找出交付價值最高的產品的最佳方式。你最應該關注的是價值的交付，而非死死遵循 Scrum 的規則。

根據我的經驗，隨著時間的推移，我們對大規模框架的規則也會越來越駕輕就熟。但是，無論我們多麼遵守和忠實於那些規則，我們打算處理的問題都沒有得到妥善解決。

事實上，事情似乎總會變得更糟。由於官僚主義日益盛行、靈活性不斷縮減，新的問題不斷出現，原本的問題卻一個都沒解決。大規模框架承諾的是提供一種解決問題的捷徑，就像是你在減肥時採用的那種流行健康食譜：你只需按步驟一步步來，就可以保證成功——真要是有那麼容易就好了。

大規模框架往往承諾為懶惰和絕望的人們提供神奇的解決方案：用不著思考，照我們說的去做，一切都會變好的。

這與 Scrum 本應遵循的機制完全相反。Scrum 遵循以下格言：“我們不會告訴你該做什麼，但我們會讓你清楚地看到那些痛點，然後你需要自己來搞定它們”。

捷徑是不存在的。你需要透過嘗試、失敗並堅持遵循可以產生結果的路徑來弄清楚哪些東西才是有效的。你不應該盲目地遵循框架的配方，以為那些配方可以取代常識。

2

複製貼上大規模框架會阻止人們汲取經驗教訓

大規模框架（如 SAFe）越規範，它與 Scrum 基於經驗的核心理唸的衝突就越多。在一種情況下有效的方法可能在另一種情況下毫無作用。你只能不斷去嘗試各種事物，並評估它們是否真的有效，才能解決這個問題。

問題是大多數大規模框架捆綁了許多不同的實踐。這是一錘子買賣。當你實現整個 shebang 時，你怎麼知道哪些東西才是真正有效的，哪些又是無效的呢？

想象一下，淋浴間某處開始漏水。結果你並沒有花時間弄清楚漏點在哪裡，而是決定更換淋浴房下方的地板和所有管道。大動干戈完之後漏水問題依舊。你到底有沒有補上原來的漏點呢，還是說你又搞出來了新的漏點？你同時改變了這麼多東西，誰能知道到底是怎麼回事。

這正是引入大規模框架時會發生的情況。當你一次引入如此多的更改時，就很難確定哪些是有效的，哪些不起作用。當你遵循經驗方法時，你會一點點嘗試更改並留下那些起作用的東西。否則，這種方法就不是基於經驗和證據的實證方法。使用許多大規模框架時，你只是在根據直覺而不是具體的證據來調配你的流程雞尾酒。

應對淋浴房漏水的問題時，我們應該在動工之前先找出漏點的位置，然後實施你認為可以解決或改善問題的最簡單方法。這樣，你就可以定位你面臨的是哪些問題，然後就能確定你的解決方案是否真的有效。這種方法的另一個好處是你只會留下最簡單的方案，而且不會引入不必要的複雜性。

實現功能豐富的大規模框架時，你會很難從失敗中學習經驗教訓。你同時實現的更改越多，就越難確定哪些進展是順利的，哪些進展遇到了障礙。到最後你會保留許多冗餘實踐，這些實踐中還經常會隱藏新的問題。

3

Scrum 的最大要點在於它是故意不完整的

Scrum 的全部意義都在於讓你自己來發明交付價值的規則。這裡麵包括了在組織的發展過程中你將遇到的所有擴充套件問題。如果你不能自己解決擴充套件問題，也許你就不應該使用 Scrum。這足以證明你無法處理 Scrum 背後的流程框架哲學。

SAFe 帶有自己的 Scrum 變體，ScrumXP，它可能更適合你。無需多想，一條條遵循 SAFe 的理念走下去即可，一切都會好起來的——至少這是它們的承諾。

Scrum 要求你新增自己的個人風格，並透過交付價值所需的流程來豐富完善這種風格。如果你沒有能力做到這一點，那麼請不要使用 Scrum，它是不會給你幫助的。

4

是否所有大規模框架都提供了一個懶惰且破壞性的自助套餐，讓你的擴充套件之路走向失敗呢？

現在，我並不能說自己已經有了所有大規模框架的實踐經驗，自然也沒法斷言所有大規模框架都是懶惰和破壞性的，就像那些流行健康食譜一樣。有一些大規模框架試圖走上正路，LeSS（LargeScaleScrum）就是一個例子。正如首字母縮略詞暗示的那樣，它是輕量級的，並承認永遠都不會有什麼萬能靈藥。

下面這條 LeSS 原則就說明了這一點：

事半功倍——（1）在經驗流程控制中：用定義較少的流程學習更多經驗。（2）在精益思想中：以更少的浪費和開銷獲得更多的價值。（3）在擴充套件方面，以更少的角色、元件和特殊小組獲得更多的所有權、目的和樂趣。

你可以去了解實現各個大規模框架時可能遇到的不同問題，從中選擇正確的方法。如果你決定使用某個大規模框架，請在使用任何重量級方法（例如 SAFe）之前先選擇一種輕量級方法，例如 LeSS。

你可以逐漸引入這種輕量級方法的各個部分，並評估它是否真的產生了你期望的改進，否則就改進或放棄它。LeSS 就是本著這種精神建立的——儘可能消除不必要的複雜性。

你可以去了解各種大規模框架，並挑選出那些可能解決你所面臨問題的具體部分。每個大規模框架都有其優點和缺點。就像減肥一樣，對別人有效的方法可能對你就無效。甚至有人透過賽百味節食方法就減掉了 111 公斤。但你可以將他人的經驗為我所用，從中找到你自己的方法去適應你的獨特情況和問題。

這做起來並不容易，但你從中可以期待的回報遠遠大於複製貼上樣板解決方案所帶來的收益。根據你的獨特環境和需求去定製價值交付流程，從而交付最大價值。你新增的所有複雜性都必須發揮作用。如果你一次新增太多更改，你將永遠無法弄清楚每個更改到底有哪些貢獻。

作為這種極簡主義方法的具體示例，可以參考我多次介紹過的 Feature Teams，但不需要實現 LeSS。我確實受益於 LeSS 框架提出的，關於如何引入 Feature Teams 的最佳實踐。在實現了 Feature Teams 之後，我們的很多問題都消失了，也就沒有必要再引入 LeSS 的其他部分。

用統計和經濟學家 Ernst F。Schumacher 的話來說：

“只會小聰明的人們都會讓事情變得更大、更復雜、更暴力。這需要一點點天賦——以及朝著相反方向前進的巨大勇氣。”

大多數大規模框架就像本文開頭圖片中的指尖陀螺一樣：它們看起來漂亮而閃亮，當你看到有人在玩指尖陀螺時，你會迫不及待地想要玩一把。但是當你終於買了一個陀螺，並第一次用手指旋轉它時，你就開始後悔了。你不禁想知道：“我怎麼又交了一次智商稅呢？”。

原文連結：

https：//medium。com/serious-scrum/why-most-scaling-frameworks-are-a-fad-that-will-blow-over-c05d2c24f879

TAG: 框架大規模Scrum問題less