作者：Gu-dong 咕咚老王

昨天通過(guò)微信沙龍，分享到了一個(gè)案例，講述的是從成功到失敗的過(guò)程。

很多人可能疑惑，很多案例都是從失敗到成功，這個(gè)怎么反了。很多成功背后都有其原因，可能很勵(lì)志，但從失敗中我們能夠獲取更多。畢竟我們的知識(shí)大多源于失敗而非成功。

故事是這樣的（括號(hào)中的是筆者的情緒表達(dá) :)）：

（在很久很久以前……）某公司成立了一個(gè)團(tuán)隊(duì)，開(kāi)發(fā)一款全新的產(chǎn)品。產(chǎn)品的開(kāi)發(fā)模式是產(chǎn)品需求獲取和開(kāi)發(fā)同步進(jìn)行，團(tuán)隊(duì)構(gòu)成為：項(xiàng)目經(jīng)理帶領(lǐng)開(kāi)發(fā)和測(cè)試兩個(gè)子團(tuán)隊(duì)，每個(gè)子團(tuán)隊(duì)各有一名Leader。產(chǎn)品經(jīng)理在開(kāi)始僅提出最基本需求，根據(jù)內(nèi)部用戶的反饋，不斷改進(jìn)需求。（哇噢，很酷！）。這就導(dǎo)致了持續(xù)發(fā)布的需求。開(kāi)發(fā)流程選用了Scrum。（用到敏捷啦*_*）。開(kāi)發(fā)測(cè)試同步進(jìn)行，最早幾個(gè)Sprint，采用純手工測(cè)試，僅限功能測(cè)試。（噢~，會(huì)成功么？）。純手工的問(wèn)題立刻暴露：無(wú)法回歸。（出現(xiàn)問(wèn)題了吧~）。形式所迫，引入自動(dòng)化測(cè)試。（還好，糾正的及時(shí) :)）。項(xiàng)目經(jīng)理很權(quán)威，立刻決定實(shí)施自動(dòng)化測(cè)試，同時(shí)保留部分新功能的手工測(cè)試。但問(wèn)題依然存在，當(dāng)開(kāi)發(fā)人員不參與測(cè)試，測(cè)試相對(duì)于開(kāi)發(fā)的滯后是必然的。這個(gè)gap無(wú)法逾越。

項(xiàng)目經(jīng)理允許測(cè)試落后開(kāi)發(fā)一個(gè)Sprint。（看來(lái)要違反敏捷中“完成”原則了。）測(cè)試工程師們經(jīng)過(guò)努力，達(dá)到了這個(gè)標(biāo)準(zhǔn)，中國(guó)team表示很滿意；但美國(guó)老大不滿意，要求開(kāi)發(fā)測(cè)試必須同步。（看來(lái)老大還是理解敏捷的。）于是制定強(qiáng)制要求，要求開(kāi)發(fā)人員必須寫單元測(cè)試，由此引入了TDD。（哇！原來(lái)這個(gè)神器是被老大逼迫使用的。）同時(shí)測(cè)試架設(shè)CI，并引入測(cè)試覆蓋率統(tǒng)計(jì)工具，如果新功能的測(cè)試代碼覆蓋率低于閾值，則不允許checkin代碼。（持續(xù)集成也有啦。手舞足蹈中~）。項(xiàng)目經(jīng)理進(jìn)一步要求，開(kāi)發(fā)人員必須參與集成測(cè)試Case的編寫，這一點(diǎn)其實(shí)并沒(méi)有很好的執(zhí)行，但靠著項(xiàng)目經(jīng)理個(gè)人的權(quán)威和測(cè)試工程師的努力，產(chǎn)品就這樣發(fā)布了。反饋非常不錯(cuò)，Bug很少，且沒(méi)有任何致命的Bug。（耶~成功啦~，此處掌聲如雷！）。總結(jié)經(jīng)驗(yàn)，感覺(jué)產(chǎn)品的質(zhì)量很高，能到達(dá)這個(gè)質(zhì)量，與開(kāi)發(fā)和測(cè)試同步進(jìn)行有直接關(guān)系。所以此產(chǎn)品1.0發(fā)布之后的開(kāi)發(fā)中，希望敏捷過(guò)程更加推進(jìn)了一步。

成功發(fā)布了一個(gè)產(chǎn)品后，團(tuán)隊(duì)又接受了開(kāi)發(fā)另外一個(gè)新產(chǎn)品的任務(wù)，類型與前者類似。團(tuán)隊(duì)將敏捷推進(jìn)到了第二階段：全功能團(tuán)隊(duì)，Scrum+pair programming+TDD。（此處可以有掌聲！）（滿眼都是羨慕的小星星，結(jié)對(duì)都用上啦！）。開(kāi)發(fā)測(cè)試不分，前后端不分，所有工程師都一律結(jié)對(duì)編程。由于招聘時(shí)對(duì)測(cè)試人員的要求高，因此Coding技能并不比開(kāi)發(fā)人員差。這時(shí)沒(méi)有QA和Dev的差別了，兩個(gè)人之間會(huì)自由交換角色。團(tuán)隊(duì)終于從半敏捷轉(zhuǎn)為全敏捷！（其實(shí)前面已經(jīng)很敏捷啦~）。

但是從這時(shí)起，一個(gè)負(fù)能量的變化卻在暗流涌動(dòng)：項(xiàng)目經(jīng)理和測(cè)試Leader因升職或其他原因而調(diào)離團(tuán)隊(duì)，整個(gè)團(tuán)隊(duì)中沒(méi)有人再關(guān)心質(zhì)量。但是問(wèn)題并沒(méi)有立刻暴露，因?yàn)榍耙粋€(gè)項(xiàng)目中遺留的資產(chǎn)（Test frame work、Test case等）還能繼續(xù)使用。還有一點(diǎn)就是美國(guó)團(tuán)隊(duì)引入了一位精力充沛的Architect，這位老兄每天20小時(shí)盯著項(xiàng)目，還會(huì)自己手動(dòng)的去進(jìn)行測(cè)試。（美國(guó)牛仔？）。他成了項(xiàng)目中唯一一個(gè)關(guān)心質(zhì)量的人，不斷的督促團(tuán)隊(duì)成員去寫測(cè)試Case。到這個(gè)階段，整個(gè)項(xiàng)目依賴著前一個(gè)項(xiàng)目的積累和Architect的個(gè)人英雄主義推行著。

依賴著這套貌似很酷的“敏捷”，項(xiàng)目堅(jiān)持到了產(chǎn)品的發(fā)布，但大家都知道這個(gè)項(xiàng)目的質(zhì)量是無(wú)法和前一個(gè)產(chǎn)品相比的。（我這時(shí)問(wèn)了一個(gè)問(wèn)題：團(tuán)隊(duì)中是否有敏捷教練或類似的角色？回答是沒(méi)有。）故事還沒(méi)有結(jié)束，原測(cè)試人員的頂頭上司（測(cè)試部門經(jīng)理）轉(zhuǎn)變了職能，但團(tuán)隊(duì)中QA engineer的report line并沒(méi)有改變。至此，團(tuán)隊(duì)內(nèi)外，已經(jīng)沒(méi)有人關(guān)心質(zhì)量了。之后持續(xù)了一段時(shí)間的結(jié)對(duì)編程，但是TDD已經(jīng)被放棄了。（神器被首先拋棄了。）。CI雖然還在運(yùn)行，但每次運(yùn)行時(shí)執(zhí)行的Test Case已經(jīng)很久沒(méi)有增加過(guò)新的，舊的則無(wú)人維護(hù)以致被關(guān)掉了。（測(cè)試通不過(guò)怎么辦？不測(cè)試就行了唄 :)）。之后所謂的敏捷團(tuán)隊(duì)，就是產(chǎn)品經(jīng)理的Story，以及團(tuán)隊(duì)成員每天去完成這些Story。他們覺(jué)得已經(jīng)“完成”了，就Checkin。整個(gè)團(tuán)隊(duì)陷入了噩夢(mèng)的狀態(tài)，如果產(chǎn)品經(jīng)理不去確認(rèn)，沒(méi)有人知道這些程序是否能夠運(yùn)行起來(lái)。

最終的結(jié)果是，曾經(jīng)開(kāi)發(fā)新產(chǎn)品Bug不超過(guò)兩位數(shù)的團(tuán)隊(duì)，現(xiàn)在淪落到一個(gè)新的功能完成后，都沒(méi)有人去測(cè)試一下的狀態(tài)。（嗚嗚嗚~，大哭！）。

是什么導(dǎo)致了這樣的結(jié)果？下面是筆者的一點(diǎn)感受：

前一個(gè)產(chǎn)品開(kāi)發(fā)階段的敏捷，是權(quán)威下的“敏捷”。之所以成功，不是形成了真正敏捷的自組織團(tuán)隊(duì)，而是在項(xiàng)目管理人員的個(gè)人權(quán)威之下，實(shí)施了真正的敏捷實(shí)踐。當(dāng)權(quán)威不再存在時(shí)，實(shí)踐也就無(wú)法堅(jiān)持下去了。

敏捷團(tuán)隊(duì)中沒(méi)有敏捷教練/Scrum Master。許多人認(rèn)為這個(gè)角色在國(guó)內(nèi)的公司內(nèi)是無(wú)法得到認(rèn)同的，因?yàn)樗炔婚_(kāi)發(fā)也不測(cè)試，對(duì)產(chǎn)品沒(méi)有貢獻(xiàn)。而這個(gè)案例恰恰對(duì)此作了很好的注釋。我們是關(guān)心一個(gè)人的成本被“浪費(fèi)”？還是坐視一個(gè)團(tuán)隊(duì)的成本被浪費(fèi)？之前的那個(gè)項(xiàng)目經(jīng)理這個(gè)角色是否是“浪費(fèi)”？（關(guān)于此點(diǎn)當(dāng)時(shí)有所討論，分享者認(rèn)為項(xiàng)目經(jīng)理與敏捷教練是不同的，項(xiàng)目經(jīng)理的責(zé)任更多，而敏捷教練則很少。筆者認(rèn)為這是一個(gè)誤解，項(xiàng)目經(jīng)理的責(zé)任，包括權(quán)利被整個(gè)團(tuán)隊(duì)繼承和分擔(dān)了，其中項(xiàng)目整體管理這個(gè)責(zé)任的一部分就放到了敏捷教練身上。同時(shí)，敏捷教練也承擔(dān)了更多其他敏捷相關(guān)的責(zé)任。筆者個(gè)人認(rèn)為：當(dāng)團(tuán)隊(duì)成員都對(duì)敏捷有了極致的理解，敏捷文化高度盛行的時(shí)候，敏捷教練也就不需要了。也就是說(shuō)，敏捷教練一定要做自己的掘墓人。）
敏捷教練的角色之所以重要，就是因?yàn)門A在引導(dǎo)大家遵循敏捷實(shí)踐的原則和價(jià)值觀，遵守敏捷的紀(jì)律，最終促使團(tuán)隊(duì)走向成功。
缺少了敏捷教練，就沒(méi)有人關(guān)注團(tuán)隊(duì)中那些偏差和障礙，甚至當(dāng)這些問(wèn)題擺在面前時(shí)，大家也是熟視無(wú)睹。比如案例中：對(duì)TDD的拋棄、對(duì)“完成”定義的拋棄。

沒(méi)有敏捷教練的角色，帶來(lái)的另外一個(gè)弊端就是沒(méi)有人宣揚(yáng)和傳輸敏捷的價(jià)值觀和文化，沒(méi)有人對(duì)團(tuán)隊(duì)成員進(jìn)行敏捷教育。從而使得團(tuán)隊(duì)只是一個(gè)權(quán)威下的“敏捷”團(tuán)隊(duì)，而非最終形成一個(gè)自組織的敏捷團(tuán)隊(duì)。

?9/28日更新：
剛剛看完Ken Schwaber和Jeff Sutherland合著的《30天軟件開(kāi)發(fā) 告別瀑布擁抱敏捷》，其中在第8章——“在企業(yè)中應(yīng)用Scrum”——中有這么一段話，對(duì)此類案例做了精辟的總結(jié)：我們已經(jīng)見(jiàn)過(guò)太多例子，在企業(yè)內(nèi)的其他人還沒(méi)有真正懂得如何用新的方法思考和工作，轉(zhuǎn)型還沒(méi)有在企業(yè)內(nèi)扎根時(shí)，發(fā)起人就由于晉升或離職離開(kāi)了原來(lái)的崗位。當(dāng)發(fā)起人高官離開(kāi)之后，之前取得的進(jìn)步將灰飛煙滅，而剛被淹埋卻沒(méi)有根除的舊文化又會(huì)卷土重來(lái)。之前取得的優(yōu)勢(shì)和持續(xù)改進(jìn)的習(xí)慣也會(huì)隨著時(shí)間的推移漸漸減弱。

歡迎大家板磚伺候！

原文鏈接 http://www.cnblogs.com/Wangyong-Wen/p/3976805.html

總結(jié)

以上是生活随笔為你收集整理的一个成功敏捷团队的失败历程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。