這是一篇翻譯的文章(有刪減)，作者Gerhard Beck對Scrum瘋狂吐槽，我雖然不能完全認同，但是有些吐槽還是挺對的，比如忽視文檔。翻譯出來想讓大家看看，在實施Scrum的時候有沒有同感?有沒有覺得敏捷已經變味了?

[[334055]]

我現在的團隊最近采用了Scrum這種敏捷方法，并且開始了一個兩周的Sprint，但是Scrum出現的問題讓我開始憎恨它。

以鄙人之見，Scrum并不敏捷，也不靈活，因為有些堅定的追隨者(狂熱分子)堅持按照Scrum字面的意思去做，這些信徒已經接管了一切。

讓我們從Scrum的兩個基本術語開始：Sprint和Daily Scrum

Sprint

[[334056]]

[[334057]]

Sprint是英式橄欖球的“沖刺”，這是一種隱喻，意味著經理們可以告訴每一個人，我們的開發需要“沖刺”得更快一些，把需求放到兩周的時間框中，定期加大開發的壓力。

這真是一種偉大的管理技術，可以最大程度地提高員工的加班時間，雖然加班已經讓我們精疲力盡了。

碼農翻身：不認同，這說明公司和管理層并沒有真正地學會什么是敏捷和Scrum，但悲哀的是有不少公司就是打著敏捷的旗號這么做，壓榨程序員。

Daily scrum

[[334058]]

[[334057]]

Scrum是渾身“臟兮兮”的橄欖球運動員“互相推搡”著爭球， 這是另外一種隱喻，表示你得完成日常工作，確保項目進展沒有障礙。

相比而言，我更喜歡一個不那么激烈和侵略性的東西：每日站會。可以說說你昨天做了什么，今天計劃做什么，有沒有阻礙你的東西。

碼農翻身：實際上，在國內我們使用的詞就是“每日站會”，而不是“每日爭球”。

Done

“Done”(完成)是Scrum中一個關鍵的術語，它要求那些干活的人和檢查的人對于“Done”必須得達成一致，實際上，"Done"指的是被最終用戶接受， 有些人真把它玩壞了。

“Done”和兩周的Sprint經常以一種特別討厭的方式結合在一起：“在每個Sprint Review會議中，我們必須看到一個完成的、可以交付的軟件增量”， 于是我們就看到了這樣的談話：

“生孩子需要花9個月。”

“你必須把這個過程分解到以兩周為單位的Sprint當中，這樣我們每個Sprint Review都能看到進展。”

“起草這個文件需要花費3個月時間，因為我們需要把一些設計加上去。"

“好啊，你把整個文件分解一下，確保每個Sprint我們都有可以發布的東西，每個Spring我們都要‘Done’。”

“但是只有全部完成才能發布，你為什么要假裝每個Sprint都能發布呢?”

碼農翻身：作者舉的例子比較極端，一般來說任務完成是指開發完成，測試完成，代碼提交，構建完成，隨時可以部署

Time Box (時間框)

時間框的目的是把所有的事情放到一起，在一個Sprint中全部完成，一個Sprint時間框通常是兩周時間，可能更長或者更短。

但是有些事情會快一些，有些會慢一些，當那些比較快的任務已經完成，為什么不立刻發布它們呢?為什么要等到Sprint的結束，等到Sprint review 會議后才發布呢?

再說一次，以我的淺見，Scrum不是敏捷，它是一個為期兩周的瀑布模型。

Scrum Master

OK，現在正處于“黑人的命也是命”的抗議時期。"Master"經常被認為是一個種族主義的詞匯，正好可以停止使用它了。

什么是“Scrum Master”? Scrum Master是團隊的一個“仆人”式領導，他實際上是被剝奪了管理項目能力的PM，我可不想參與其中。

很多時候，我們需要完成一些緊急的，意料之外的事情，項目經理有權力做出改變，把這些事情搞定。

對于Scrum Master，他只能“溫柔”地向管理層解釋，這個Sprint的工作已經確定了，不能改了，拯救這條船的機會將會出現在一周半后的Sprint Review會議上，在此之前，你的雙腳必須得忍受這些不舒服的海水。

會議

• Scrum定義了四個正式的會議：
• Sprint 規劃會議
• Daily Scrum
• Spring Review
• Sprint 回顧和反省

Spring 規劃會議提供了各種方法來估算任務需要花費多長時間(碼農翻身注：難道作者指的是撲克牌估算?)，這可以使得Sprint的任務清晰明了。我覺得這完全是浪費時間!現在僅僅是猜測，就試圖把任務放到兩周的Sprint中是荒謬的。

碼農翻身：不認同，任務的時間估算還是必不可少的。

我甚至聽說過有些團隊為了使得Sprint更“滿”，特意增加一些不重要的任務。 我認為任務應該按照優先級來進行開發，而不是僅僅為了放入到Sprint當中!

每日站會的確是個好主意，但是最好不要把它稱為“每日爭球”。看看在既定時間表上正在發生的事情是一個好主意，但是在每次會議上都要求“Done”就不是這樣了。

Spring回顧和反省會議不一定每個Sprint都做，只有你注意到了一些事情可以改善時，開回顧會議才有必要。

團隊

Scrum對于團隊有個說法：一切歸團隊所有，團隊要同甘共苦。

我相信團隊成員需要互相幫助，團隊應該作為整體而成功，但是我并不喜歡績效好成員也要為績效差的成員背鍋， 吃大鍋飯必然導致優秀成員的離職。所以個體的努力應該被認可，Scrum在很大程度上踐踏了這一理念。

Scrum還有一個說法： 團隊成員的每個人都可以做其他人的工作，我不認同，這只會讓團隊的技術專家降級到泥瓦匠的層次。

碼農翻身：不認同，開發幫著做點兒測試的工作，測試幫著寫一點自動化單元測試，我認為是可能的。

我也反對每個成員對任何事情都有平等的投票權， 假設我雇傭了一個有30年經驗的專家和5個剛走出校門的大學生，我肯定期待專家發言權更大，而不是被新手們通過投票擊敗。

對于一個團隊，我認為需要培訓更好的領導者，而不是完全放棄這個概念，軍隊是完全建立在領導者和領導力基礎上的，在需要的時候軍隊非常敏捷，尤其是被給予現場做決定的自由時。我們應該更多地研究一個好的領導者是什么樣子，而不是發明一個方法論，故意地去除領導者和領導力。

可以工作的軟件

Scrum致力于每兩周都發布可以工作的軟件，對于有些項目(如Web前端)，這樣一個短的、相同的節奏工作良好，對另外一些項目(如航空電子設備)它就沒法工作了。

我工作過的大部分項目都無法適應這個模型。你通常可以每周展示進度，但是很難保證每兩周都有一個潛在的，可以發布的產品。

我也很喜歡在早期就擁有可以工作的子系統，然后讓他們逐漸成熟，并增加更多子系統，但是“可以工作的軟件”模型真正的問題是它忽略了計劃和文檔。

在最好的情況下，你可能有一個planning sprint,用兩周的時間專門做計劃，然后你就忘記了這個苦差事，這兩周過后，再也不做計劃和文檔了，只是code, code ,code !

雖然我堅信編碼才是最終的設計步驟，但是我不相信編碼是唯一的設計步驟。對于絕大多數任務，我希望在編碼之前看到一些設計。

碼農翻身：說得好!忽視設計和文檔后果嚴重，敏捷不是不要設計文檔，而是要去除那些繁瑣的、容易過時的設計文檔

最后，作者列舉了他認為有用的幾個實踐

1. 每日站會

對我們來說，我們的Product Owner通常會出席，他在開始的時候能在總體方向上給出指導，后來他總能幫我們移除一些障礙。

2. Kanban

擁有一個事情優先級的列表是非常有用的，我們沒有用固定時間長度的Sprint，每當開發人員完成了之前的任務，就會從列表中取下一個優先級更高的來做

3. 每周展示

雖然沒用固定時間長度的Sprint，但是我們的每周展示相當于Sprint Review，只要成員完成了一些重要的事情，即使沒有符合Scrum "Done"的標準，我們就會展示出來，這會樹立我們項目正在前進的自豪感和信心。團隊成員也通過這種方式獲得了認可。

怎么樣?有沒有同感?更多吐槽，可以到原文看看：

https://dzone.com/articles/why-i-hate-scrum

如需轉載，請通過作者微信公眾號coderising獲取授權。