作者：Gu-dong 咕咚老王

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

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

故事是這樣的（括號中的是筆者的情緒表達 :)）：

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

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

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

但是從這時起，一個負能量的變化卻在暗流涌動：項目經理和測試Leader因升職或其他原因而調離團隊，整個團隊中沒有人再關心質量。但是問題并沒有立刻暴露，因為前一個項目中遺留的資產（Test frame work、Test case等）還能繼續使用。還有一點就是美國團隊引入了一位精力充沛的Architect，這位老兄每天20小時盯著項目，還會自己手動的去進行測試。（美國牛仔？）。他成了項目中唯一一個關心質量的人，不斷的督促團隊成員去寫測試Case。到這個階段，整個項目依賴著前一個項目的積累和Architect的個人英雄主義推行著。

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

最終的結果是，曾經開發新產品Bug不超過兩位數的團隊，現在淪落到一個新的功能完成后，都沒有人去測試一下的狀態。（嗚嗚嗚~，大哭！）。

是什么導致了這樣的結果？下面是筆者的一點感受：

前一個產品開發階段的敏捷，是權威下的“敏捷”。之所以成功，不是形成了真正敏捷的自組織團隊，而是在項目管理人員的個人權威之下，實施了真正的敏捷實踐。當權威不再存在時，實踐也就無法堅持下去了。

敏捷團隊中沒有敏捷教練/Scrum Master。許多人認為這個角色在國內的公司內是無法得到認同的，因為他既不開發也不測試，對產品沒有貢獻。而這個案例恰恰對此作了很好的注釋。我們是關心一個人的成本被“浪費”？還是坐視一個團隊的成本被浪費？之前的那個項目經理這個角色是否是“浪費”？（關于此點當時有所討論，分享者認為項目經理與敏捷教練是不同的，項目經理的責任更多，而敏捷教練則很少。筆者認為這是一個誤解，項目經理的責任，包括權利被整個團隊繼承和分擔了，其中項目整體管理這個責任的一部分就放到了敏捷教練身上。同時，敏捷教練也承擔了更多其他敏捷相關的責任。筆者個人認為：當團隊成員都對敏捷有了極致的理解，敏捷文化高度盛行的時候，敏捷教練也就不需要了。也就是說，敏捷教練一定要做自己的掘墓人。）
敏捷教練的角色之所以重要，就是因為TA在引導大家遵循敏捷實踐的原則和價值觀，遵守敏捷的紀律，最終促使團隊走向成功。
缺少了敏捷教練，就沒有人關注團隊中那些偏差和障礙，甚至當這些問題擺在面前時，大家也是熟視無睹。比如案例中：對TDD的拋棄、對“完成”定義的拋棄。

沒有敏捷教練的角色，帶來的另外一個弊端就是沒有人宣揚和傳輸敏捷的價值觀和文化，沒有人對團隊成員進行敏捷教育。從而使得團隊只是一個權威下的“敏捷”團隊，而非最終形成一個自組織的敏捷團隊。

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

歡迎大家板磚伺候！

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。