很多人可能疑惑，很多案例都是從失敗到成功，這個怎麼反了。很多成功背後都有其原因，可能很勵志，但從失敗中我們能夠獲取更多。畢竟我們的知識大多源於失敗而非成功。
故事是這樣的（括號中的是筆者的情緒表達 :)）：
（在很久很久以前……）某公司成立了乙個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團隊構成為：專案經理帶領開發和測試兩個子團隊，每個子團隊各有一名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不超過兩位數的團隊，現在淪落到乙個新的功能完成後，都沒有人去測試一下的狀態。（嗚嗚嗚~，大哭！）。
是什麼導致了這樣的結果？下面是筆者的一點感受：
前乙個產品開發階段的敏捷，是權威下的「敏捷」。之所以成功，不是形成了真正敏捷的自組織團隊，而是在專案管理人員的個人權威之下，實施了真正的敏捷實踐。當權威不再存在時，實踐也就無法堅持下去了。
沒有敏捷教練的角色，帶來的另外乙個弊端就是沒有人宣揚和傳輸敏捷的價值觀和文化，沒有人對團隊成員進行敏捷教育。從而使得團隊只是乙個權威下的「敏捷」團隊，而非最終形成乙個自組織的敏捷團隊。
9/28日更新：
剛剛看完ken schwaber和jeff sutherland合著的《30天軟體開發 告別瀑布擁抱敏捷》，其中在第8章——「在企業中應用scrum」——中有這麼一段話，對此類案例做了精闢的總結：我們已經見過太多例子，在企業內的其他人還沒有真正懂得如何用新的方法思考和工作，轉型還沒有在企業內扎根時，發起人就由於晉公升或離職離開了原來的崗位。當發起人**離開之後，之前取得的進步將灰飛煙滅，而剛被淹埋卻沒有**的舊文化又會捲土重來。之前取得的優勢和持續改進的習慣也會隨著時間的推移漸漸減弱。
乙個團隊的工作流程 敏捷
例 步驟1 讓我們擁有乙個由9人組成的scrum團隊，其中包括1個產品所有者，1個scrum master，2個測試人員，4個開發人員和1個dba。步驟2 sprint決定遵循4周的週期。所以我們從6月5日到 7 月4 日開始為期乙個月的sprint 步驟3 產品所有者在產品待辦事項中具有優先順序的...
構建乙個敏捷的開發團隊的小結
此文作為如何才能構建乙個敏捷的開發團隊，希望和大家一塊交流 的乙個小結，希望大家能夠提供更多的寶貴意見。總結如下 1。敏捷的團隊建設，確實是乙個漸進的過程。好像沒有那個團體是一下子就自動產生，大家只有在比較長期的磨合中，才能達到某種默契。2。在磨合的過程中，有乙個良好的習慣養成，同樣也很重要。在這方...
乙個成功的分析團隊 角色與職責
多年以來我和數百家企業打過交道，在這個過程中，我領悟了讓資料分析專案成功的一些因素，也親眼看著很多專案失敗。最常見的失敗原因說出來可能會讓你驚訝。並非是缺乏資料專業知識或者整合失誤，而僅僅是因為企業沒有讓 利用資料 成為任何人員的職責。太多公司花費好幾個月收集有趣的資料，然後讓它們靜靜地躺在角落裡積...