一個成功敏捷團隊的失敗歷程

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

不少人可能疑惑，不少案例都是從失敗到成功，這個怎麼反了。不少成功背後都有其緣由，可能很勵志，但從失敗中咱們可以獲取更多。畢竟咱們的知識大多源於失敗而非成功。

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

（在好久好久之前……）某公司成立了一個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團隊構成爲：項目經理帶領開發和測試兩個子團隊，每一個子團隊各有一名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不超過兩位數的團隊，如今淪落到一個新的功能完成後，都沒有人去測試一下的狀態。（嗚嗚嗚~，大哭！）。

是什麼致使了這樣的結果？下面是筆者的一點感覺：

1. 前一個產品開發階段的敏捷，是權威下的「敏捷」。之因此成功，不是造成了真正敏捷的自組織團隊，而是在項目管理人員的我的權威之下，實施了真正的敏捷實踐。當權威再也不存在時，實踐也就沒法堅持下去了。
2. 敏捷團隊中沒有敏捷教練/Scrum Master。許多人認爲這個角色在國內的公司內是沒法獲得認同的，由於他既不開發也不測試，對產品沒有貢獻。而這個案例偏偏對此做了很好的註釋。咱們是關心一我的的成本被「浪費」？仍是坐視一個團隊的成本被浪費？以前的那個項目經理這個角色是不是「浪費」？（關於此點當時有所討論，分享者認爲項目經理與敏捷教練是不一樣的，項目經理的責任更多，而敏捷教練則不多。筆者認爲這是一個誤解，項目經理的責任，包括權利被整個團隊繼承和分擔了，其中項目總體管理這個責任的一部分就放到了敏捷教練身上。同時，敏捷教練也承擔了更多其餘敏捷相關的責任。筆者我的認爲：當團隊成員都對敏捷有了極致的理解，敏捷文化高度盛行的時候，敏捷教練也就不須要了。也就是說，敏捷教練必定要作本身的掘墓人。）
   敏捷教練的角色之因此重要，就是由於TA在引導你們遵循敏捷實踐的原則和價值觀，遵照敏捷的紀律，最終促使團隊走向成功。
   缺乏了敏捷教練，就沒有人關注團隊中那些誤差和障礙，甚至當這些問題擺在面前時，你們也是熟視無睹。好比案例中：對TDD的拋棄、對「完成」定義的拋棄。
3. 沒有敏捷教練的角色，帶來的另一個弊端就是沒有人宣揚和傳輸敏捷的價值觀和文化，沒有人對團隊成員進行敏捷教育。從而使得團隊只是一個權威下的「敏捷」團隊，而非最終造成一個自組織的敏捷團隊。

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

歡迎你們板磚伺候！