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

[[334055]]

我現(xiàn)在的團(tuán)隊(duì)最近采用了Scrum這種敏捷方法，并且開始了一個(gè)兩周的Sprint，但是Scrum出現(xiàn)的問題讓我開始憎恨它。

以鄙人之見，Scrum并不敏捷，也不靈活，因?yàn)橛行﹫?jiān)定的追隨者(狂熱分子)堅(jiān)持按照Scrum字面的意思去做，這些信徒已經(jīng)接管了一切。

讓我們從Scrum的兩個(gè)基本術(shù)語(yǔ)開始：Sprint和Daily Scrum

Sprint

[[334056]]

[[334057]]

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

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

碼農(nóng)翻身：不認(rèn)同，這說明公司和管理層并沒有真正地學(xué)會(huì)什么是敏捷和Scrum，但悲哀的是有不少公司就是打著敏捷的旗號(hào)這么做，壓榨程序員。

Daily scrum

[[334058]]

[[334057]]

Scrum是渾身“臟兮兮”的橄欖球運(yùn)動(dòng)員“互相推搡”著爭(zhēng)球， 這是另外一種隱喻，表示你得完成日常工作，確保項(xiàng)目進(jìn)展沒有障礙。

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

碼農(nóng)翻身：實(shí)際上，在國(guó)內(nèi)我們使用的詞就是“每日站會(huì)”，而不是“每日爭(zhēng)球”。

Done

“Done”(完成)是Scrum中一個(gè)關(guān)鍵的術(shù)語(yǔ)，它要求那些干活的人和檢查的人對(duì)于“Done”必須得達(dá)成一致，實(shí)際上，"Done"指的是被最終用戶接受， 有些人真把它玩壞了。

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

“生孩子需要花9個(gè)月。”

“你必須把這個(gè)過程分解到以兩周為單位的Sprint當(dāng)中，這樣我們每個(gè)Sprint Review都能看到進(jìn)展。”

“起草這個(gè)文件需要花費(fèi)3個(gè)月時(shí)間，因?yàn)槲覀冃枰岩恍┰O(shè)計(jì)加上去。"

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

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

碼農(nóng)翻身：作者舉的例子比較極端，一般來說任務(wù)完成是指開發(fā)完成，測(cè)試完成，代碼提交，構(gòu)建完成，隨時(shí)可以部署

Time Box (時(shí)間框)

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

但是有些事情會(huì)快一些，有些會(huì)慢一些，當(dāng)那些比較快的任務(wù)已經(jīng)完成，為什么不立刻發(fā)布它們呢?為什么要等到Sprint的結(jié)束，等到Sprint review 會(huì)議后才發(fā)布呢?

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

Scrum Master

OK，現(xiàn)在正處于“黑人的命也是命”的抗議時(shí)期。"Master"經(jīng)常被認(rèn)為是一個(gè)種族主義的詞匯，正好可以停止使用它了。

什么是“Scrum Master”? Scrum Master是團(tuán)隊(duì)的一個(gè)“仆人”式領(lǐng)導(dǎo)，他實(shí)際上是被剝奪了管理項(xiàng)目能力的PM，我可不想?yún)⑴c其中。

很多時(shí)候，我們需要完成一些緊急的，意料之外的事情，項(xiàng)目經(jīng)理有權(quán)力做出改變，把這些事情搞定。

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

會(huì)議

• Scrum定義了四個(gè)正式的會(huì)議：
• Sprint 規(guī)劃會(huì)議
• Daily Scrum
• Spring Review
• Sprint 回顧和反省

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

碼農(nóng)翻身：不認(rèn)同，任務(wù)的時(shí)間估算還是必不可少的。

我甚至聽說過有些團(tuán)隊(duì)為了使得Sprint更“滿”，特意增加一些不重要的任務(wù)。 我認(rèn)為任務(wù)應(yīng)該按照優(yōu)先級(jí)來進(jìn)行開發(fā)，而不是僅僅為了放入到Sprint當(dāng)中!

每日站會(huì)的確是個(gè)好主意，但是最好不要把它稱為“每日爭(zhēng)球”。看看在既定時(shí)間表上正在發(fā)生的事情是一個(gè)好主意，但是在每次會(huì)議上都要求“Done”就不是這樣了。

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

團(tuán)隊(duì)

Scrum對(duì)于團(tuán)隊(duì)有個(gè)說法：一切歸團(tuán)隊(duì)所有，團(tuán)隊(duì)要同甘共苦。

我相信團(tuán)隊(duì)成員需要互相幫助，團(tuán)隊(duì)?wèi)?yīng)該作為整體而成功，但是我并不喜歡績(jī)效好成員也要為績(jī)效差的成員背鍋， 吃大鍋飯必然導(dǎo)致優(yōu)秀成員的離職。所以個(gè)體的努力應(yīng)該被認(rèn)可，Scrum在很大程度上踐踏了這一理念。

Scrum還有一個(gè)說法： 團(tuán)隊(duì)成員的每個(gè)人都可以做其他人的工作，我不認(rèn)同，這只會(huì)讓團(tuán)隊(duì)的技術(shù)專家降級(jí)到泥瓦匠的層次。

碼農(nóng)翻身：不認(rèn)同，開發(fā)幫著做點(diǎn)兒測(cè)試的工作，測(cè)試幫著寫一點(diǎn)自動(dòng)化單元測(cè)試，我認(rèn)為是可能的。

我也反對(duì)每個(gè)成員對(duì)任何事情都有平等的投票權(quán)， 假設(shè)我雇傭了一個(gè)有30年經(jīng)驗(yàn)的專家和5個(gè)剛走出校門的大學(xué)生，我肯定期待專家發(fā)言權(quán)更大，而不是被新手們通過投票擊敗。

對(duì)于一個(gè)團(tuán)隊(duì)，我認(rèn)為需要培訓(xùn)更好的領(lǐng)導(dǎo)者，而不是完全放棄這個(gè)概念，軍隊(duì)是完全建立在領(lǐng)導(dǎo)者和領(lǐng)導(dǎo)力基礎(chǔ)上的，在需要的時(shí)候軍隊(duì)非常敏捷，尤其是被給予現(xiàn)場(chǎng)做決定的自由時(shí)。我們應(yīng)該更多地研究一個(gè)好的領(lǐng)導(dǎo)者是什么樣子，而不是發(fā)明一個(gè)方法論，故意地去除領(lǐng)導(dǎo)者和領(lǐng)導(dǎo)力。

可以工作的軟件

Scrum致力于每?jī)芍芏及l(fā)布可以工作的軟件，對(duì)于有些項(xiàng)目(如Web前端)，這樣一個(gè)短的、相同的節(jié)奏工作良好，對(duì)另外一些項(xiàng)目(如航空電子設(shè)備)它就沒法工作了。

我工作過的大部分項(xiàng)目都無法適應(yīng)這個(gè)模型。你通常可以每周展示進(jìn)度，但是很難保證每?jī)芍芏加幸粋€(gè)潛在的，可以發(fā)布的產(chǎn)品。

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

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

雖然我堅(jiān)信編碼才是最終的設(shè)計(jì)步驟，但是我不相信編碼是唯一的設(shè)計(jì)步驟。對(duì)于絕大多數(shù)任務(wù)，我希望在編碼之前看到一些設(shè)計(jì)。

碼農(nóng)翻身：說得好!忽視設(shè)計(jì)和文檔后果嚴(yán)重，敏捷不是不要設(shè)計(jì)文檔，而是要去除那些繁瑣的、容易過時(shí)的設(shè)計(jì)文檔

最后，作者列舉了他認(rèn)為有用的幾個(gè)實(shí)踐

1. 每日站會(huì)

對(duì)我們來說，我們的Product Owner通常會(huì)出席，他在開始的時(shí)候能在總體方向上給出指導(dǎo)，后來他總能幫我們移除一些障礙。

2. Kanban

擁有一個(gè)事情優(yōu)先級(jí)的列表是非常有用的，我們沒有用固定時(shí)間長(zhǎng)度的Sprint，每當(dāng)開發(fā)人員完成了之前的任務(wù)，就會(huì)從列表中取下一個(gè)優(yōu)先級(jí)更高的來做

3. 每周展示

雖然沒用固定時(shí)間長(zhǎng)度的Sprint，但是我們的每周展示相當(dāng)于Sprint Review，只要成員完成了一些重要的事情，即使沒有符合Scrum "Done"的標(biāo)準(zhǔn)，我們就會(huì)展示出來，這會(huì)樹立我們項(xiàng)目正在前進(jìn)的自豪感和信心。團(tuán)隊(duì)成員也通過這種方式獲得了認(rèn)可。

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

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

如需轉(zhuǎn)載，請(qǐng)通過作者微信公眾號(hào)coderising獲取授權(quán)。