衆所周知，Scrum 是一種敏捷實踐，很多團隊在敏捷轉型時都採用了它，但是在我看來，Scrum 並不那麼敏捷，甚至它提倡的有些價值觀和做法是有悖于敏捷原則的，所以本文我會講講 Scrum 到底存在哪些問題？
首先需要說明的是，我在本文中提到的 Scrum 是由 Ken Schwaber 和 Jeff Sutherland 定義的，並遵循“ Scrum 指南”方法論。
最近，我所在的團隊開始採用 Scrum，並以兩週爲一個週期安排工作。親身實踐之後，我覺得 Scrum 本身就是個問題，在我看來，Scrum 在實踐中並不敏捷，也不靈活，有些人是 Scrum 的忠實追隨者，在實踐中堅持按照他們認爲的 Scrum 字面意思去做，嚴格遵守“兩週”這個時間。
“每日 Scrum”和“衝刺”
Scrum 是什麼？“Scrum 是輕量級的、易於理解的、難以掌握的。”我覺得難以掌握就是 Scrum 最大的槽點。我們來看一下它的基礎術語：“每日 Scrum”和“衝刺”。
在我看來，每日 Scrum 上，都是一羣職場老油條在互相推諉，希望對方能夠完成工作。相比來說，我更喜歡每日站立會，同樣是同步每天的工作以及之後計劃，但是方式卻沒有那麼激烈、咄咄逼人。
當你加班加到懷疑人生的時候，你的領導可能會告訴你“我們需要更快地衝刺”，然後以兩週爲週期，安排工作計劃，希望產出更多的產品。在我看來，這真的是一種偉大的管理方法，能夠最大限度地提高員工的加班時間，而更令人驚奇的是，我們並沒有任何一個聯盟來反對這個情況。我自己認爲，需要在一週 40 個小時的工作時間之外處理的事情都應該是罕見的緊急情況。
Done
“Done”也是 Scrum 中的一個關鍵術語。首先，“Done”的要求是“執行工作的人和檢查增量結果的人必須對‘Done’有一個達成共識的定義”。這個過程就會引發長時間的討論，而且“Done”的增量也是不好界定的。
“Done”和兩週衝刺結合在一起，常會發生這樣的對話：
“生一個孩子需要 9 個月時間。”
“你必須把這個過程分成兩週的增量，這樣我們就可以在每兩週的 sprint 評審會中展示那些‘Done’的。”
更經典的是：
“起草這份文檔需要 3 個月的時間，因爲我們需要在設計就緒時把它們加進去。”
“那麼你必須把整個文檔分成兩週的增量，以表明我們始終有一個完成的文檔，隨時可以交付。”
“但它要到最後才能交付，爲什麼要假裝？”
我完全同意每個任務都應該有一個“Done”的定義，但是定義應該是與任務相關的，確定實際做成什麼樣算是“Done”可能是需要完成的第一個任務。弄清楚什麼是“Done”並不容易，因爲可能客戶也不知道“Done”是什麼樣子。
Time Box
在 Scrum 實踐中，大家總是試圖想把所有的事情放在一個時間框中，以便能夠一起完成。雖然時間框的長度是可以更改的，但是大家普遍是會選擇兩週。這個階段遇到的問題是，事情完成的時間並不一定，以兩週爲週期可能並不適合，應該隨時發佈已完成的特性。
依我之見，Scrum 不是敏捷，它是一個爲期兩週的地獄瀑布。
Scrum Master
什麼是“Scrum Master”？Scrum Master 是 Scrum 團隊的領導者。在我看來，Scrum Master 實際上是剝奪了項目管理能力的項目經理。好的領導應該放權給團隊，但是當我們需要完成一些緊急的、意料之外的事情，項目經理有權力做出改變，把這些事情搞定。
而 Scrum Master，他只能“溫柔”地向管理層解釋，這個 Sprint 的工作已經確定了，不能改了，拯救這條船的機會將會出現在一週半後的 Sprint Review 會議上，在此之前，你的雙腳必須得忍受這些不舒服的海水。
Formal Events
Scrum 定義了四個正式的活動：“衝刺計劃”、“每日 Scrum”、“衝刺評審”和“衝刺回顧”。雖然我很喜歡這些基本概念，但我不喜歡大家同時花費大量的時間來進行這些活動。我不喜歡開會，更不喜歡無效率的會議。
爲了直接確定時間框，“衝刺計劃”提供了各種各樣的方法來計算某件事需要多長時間。這簡直就是在浪費時間，在事情還沒開始的時候，就在猜想未來兩週的工作計劃，而且還要爲了適應這兩週的時間框做出調整，實在是荒謬。我甚至聽說過，有些團隊爲了配平衝刺計劃會往裏面增加一些不太重要的任務。我認爲任務應該按照輕重緩急來安排，而不是按照時間來安排。
每天站立會真的是個好主意。但“每日 Scrum”則不是。
按既定的時間去評審正在做的事情是一個非常好的主意，但是要求每件事情在每次評審時都已“Done”不是一件好事情。
衝刺回顧，並不需要每次衝刺都做。當有一些事情想要特別弄清楚，決定下一步如何改善時，才需要做衝刺回顧。
Team
在 Scrum 中到處充滿着“團隊”的概念：一切都要由團隊掌控，團隊要同甘共苦。
我一直認爲應該要承認個人努力，做出努力的個人應該得到讚揚，而 Scrum 在很大程度上違背了這一信念。我相信團隊成員應該互相幫助，我也相信一個團隊作爲一個團隊是成功的。但是我不喜歡用表現好的團隊成員爲表現差的團隊成員遮羞。這麼做，無非是讓那些表現出色的團隊成員很快到另一家公司工作，而你手裏只剩下那些不思進取的團隊成員。
必須爲了降低團隊成員離開的風險（將總線因子增加到 1 以上）做些什麼，交叉培訓是種很好的方式，但它帶來的幫助也很有限。很多組織把細節塞進看板中，我聽說這麼做是出於這樣的原因是新人來了，他們可以知道該怎麼做。但把備註寫得清清楚楚也是要花費的時間的，你需要在兩者之間做出權衡，我個人就經常弄不清兩週前自己寫的一些備註。
我也反對每個團隊成員對所有事情都應該具有平等的投票權。如果我僱傭了一個有三十年工作經驗的專家和五個剛從大學畢業的人，我希望這個專家能提供專業的指導，而不是按那些新手的投票來做。我想我的結論已經很明顯了，我真的不喜歡“自組織”，因爲我看到“自組織”帶來了無休止的爭論。無論我在哪裏，看到的只是團隊以相當快的速度拆分重組，卻從未看到“自組織”帶來任何投資回報。
另外，我還想到了一點，Scrum 被刻意創立爲無領導的，因爲他們當時遇到的領導都很無能，沒有很好地發揮作用。我認爲我們只需要培養更好的領導者，而不是完全放棄這個概念。軍隊的建立完全基於領導者和領導力，在需要靈活的時候可以非常靈活，只要給予自主權就可以當場做出決定。或許作爲一個行業，我們應該更多地研究怎樣是一個好的領導者，而不是試圖發明一種方法，故意把領導者和領導力作爲一種要剔除的特性。對於我來說，這似乎完全就是拋棄了舵手。
可工作的軟件
Scrum 是基於每兩週發佈可工作的軟件。對於一些項目（Web 前端）來說，簡短、一致的節奏很有效。對於其他項目（如航空電子設備），它根本就行不通。我參與過的大多數項目都不符合這種模式。通常，每週展示一下進度是可以做到的，但我做過的項目卻極少有每兩週就可以交付的。“看，這是起落架，它現在已經能用了，你要交付嗎？”請注意，我喜歡儘早就有一版可工作的子系統，然後進行成熟完善，以及添加更多的子系統。而我認爲可工作的軟件模型的真正問題是，它忽略了計劃和文檔。充其量，也不過是有個類似於計劃衝刺的東西。如此，你會有兩週的時間來做計劃，然後你就可以把這些苦差事拋在腦後了。兩週後，沒什麼計劃，沒什麼文檔，只有編碼，編碼，編碼。雖然我堅信編碼是 最終 的設計步驟，但我並不認爲編碼是 唯一 的設計步驟。幾乎每個任務，我都希望在編碼之前看到一些設計。
在編寫代碼之後，你需要編寫足夠的文檔，以便在需要更改或重用代碼時，使修改者至少可以弄清楚從哪裏開始入手。事實上，對於“我們需要寫什麼文檔”，我有一個經典回答：如果你下次不能輕鬆地理解這段代碼，那麼就把你理解到的東西都寫入文檔。
事實上，我發現，沒有高層設計或架構是許多開源項目都存在的一個主要問題，因爲這一問題使用戶幾乎不可能弄清楚如何使用。文檔可能對每個 API 都有充分介紹，但僅僅如此你是不知道什麼時候爲什麼使用什麼 API 的。
Hack and Hope
使用 Scrum 經常會出現缺乏書面設計的情況，我把這種軟件開發方法稱爲“hack and hope”。它不是由一個預先想好的整體計劃來指導工作，而是由一個“衝刺計劃”來指導團隊摸索着做，並寄希望於能這樣走到最終。在這種工作方法中，你只需要考慮兩週左右的工作，沒有必要去思考幾個月後的工作。但最終需要某些資源時（例如資金、服務器、軟件、防火牆端口開放等等）你會突然發現，因爲沒有做充分的基礎設計，正常的審批流程卻成了阻礙。
替代方法：RAD Rapids 修訂版
我喜歡使用自己的方法，稱爲快速應用開發急流（RAD Rapids) 。它源自於 20 世紀 90 年代末的多種技術，甚至比敏捷還要早。我在 2001 年寫下了第二版論文。它稍晚於 Scrum 的提出，幾乎與敏捷宣言的發佈同時。
快速應用開發急流（RAD Rapids) :
https://gerhardb.org/paper-2001-rad-rapids
你可能會說，這篇論文實際上並沒有給我提供一個方法論！這是我深思熟慮之後做出的選擇。我希望人們從所有的方法中挑選出最好的策略、技術和程序（TTP），並將它們應用到你的具體環境中。我認爲介紹一種單一的方法論是徒勞無益的，有兩個原因：
第一，它很快就會過時，我不太可能讓它永遠跟得上時代。當時，我意識到以前含有實際方法論的論文過於侷限，於是就有現在的 RAD Rapids。
第二，如果你介紹了一種方法論，追隨者將專注於按照所規定的方法執行，而不是按照它的原則在當前項目中靈活應用。所以我拋棄了方法論，保留了原則。
自 2001 年以來，許多新的 TTP 在軟件開發方面都很有幫助。在我目前的項目中，我發現以下幾個帶來的幫助最大：
- 每日站立會 ——從描述上來看非常像每日 Scrum。但 我們在召開產品的站立會時，產品所有者通常都會出席。首先，我們在項目的總體方向上得到了正確的指導。其次，我們的產品負責人成了障礙清除大總管。所以我們有着極高的透明度：每天！但是，每天的站立會必須有嚴格的時間限制（最好不要超過 15 分鐘）和話題（只討論影響兩位以上參與者的事情，那些只涉及兩個人的問題可以在會議之外處理）。
- 看板 ——有一個優先級列表是非常有用的。我們沒有限定時間，大家在完成當前任務後就會把它從清單上拿掉，然後再去按優先級領取任務。對於這個 TTP，我還只是個新手，但到目前爲止我很喜歡它。
- 每週展示和講述 ——沒有時間限制，我們每週評審的目的和衝刺評審是一樣的。它的一個 重點是“展示和講述”，成員在此展示顯著成就。即使某些事情還沒有最終完成 ，實際上也能充分地展示出當前的進展，讓大家清楚項目正在向前推進，從而建立起自豪感和信心。團隊成員自己進行展示和講述，以所做的工作爲自己贏得讚許。
原文鏈接：
https://dzone.com/articles/why-i-hate-scrum
譯者簡介：
冬雨，小小技術宅一枚，從事研發過程改進及質量改進方面的工作，關注編程、軟件工程、敏捷、DevOps、雲計算等領域，非常樂意將國外新鮮的IT資訊和深度技術文章翻譯分享給大家，曾翻譯出版《深入敏捷測試》、《持續交付實戰》。