为什么我恨Scrum?
這是一篇翻譯的文章（有刪減），作者Gerhard Beck對Scrum瘋狂吐槽，我雖然不能完全認同，但是有些吐槽還是挺對的，比如忽視文檔。翻譯出來想讓大家看看，在實施Scrum的時候有沒有同感？有沒有覺得敏捷已經變味了？
我現在的團隊最近采用了Scrum這種敏捷方法，并且開始了一個兩周的Sprint，但是Scrum出現的問題讓我開始憎恨它。
以鄙人之見，Scrum并不敏捷，也不靈活，因為有些堅定的追隨者（狂熱分子）堅持按照Scrum字面的意思去做，這些信徒已經接管了一切。
讓我們從Scrum的兩個基本術語開始：Sprint和Daily Scrum
Sprint
Sprint是英式橄欖球的“沖刺”，這是一種隱喻，意味著經理們可以告訴每一個人，我們的開發需要“沖刺”得更快一些，把需求放到兩周的時間框中，定期加大開發的壓力。
這真是一種偉大的管理技術，可以最大程度地提高員工的加班時間，雖然加班已經讓我們精疲力盡了。
碼農翻身：不認同，這說明公司和管理層并沒有真正地學會什么是敏捷和Scrum，但悲哀的是有不少公司就是打著敏捷的旗號這么做，壓榨程序員。
Daily scrum
?
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
總結
以上是生活随笔為你收集整理的为什么我恨Scrum?的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： “算法复杂度”——其实并没有那么复杂
- 下一篇： 说实话，Hibernate 和 MyBa