在Scrum實施效果并不理想的企業推進敏捷實施

　　前言

　　敏捷軟件開發方法在業界廣泛受到關注，尤其是其中的SCRUM方法，更是廣泛流行，幾乎成了“敏捷”的代名詞。之所以流行，一個很重要的原因是SCRUM從管理角度出發，易理解，看上到比較容易，所以也比較受管理者的青睞。

　　然而，SCRUM的創始人之一肯. 施瓦伯(Ken Schwaber)在2009年的一篇博文上說：

　　“目前實施SCRUM的軟件企業中，有75%企業可能無法得到它們想達到的效果。(I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.)”

　　這一點也得到了充分的 證實，因為隨著越來越多的企業采納該方法，負面的結果與聲音也越來越多，盡管也有很多成功的案例在全球分享。

　　本文并不打算討論導致這么負面結果的原因，而是討論在已實施SCRUM一段時間，并且實施效果并不理想的企業中，如何幫助團隊發現問題，通過白板的七次改變過程，反映團隊成長和持續改進，最終提前交付了高質量的新特性，并讓團隊成員真正理解了敏捷開發思想，在團隊中重新樹立了信心。

　　組織狀況與試點團隊人員組成

　　整個企業在2009年開始實施SCRUM，每個團隊都在做SCRUM中規定的管理實踐，而且建立了持續集成服務器，每天都可以定時構建，運行自動化測試。然而，每個產品在開發完成后，總是需要很長的時間修復缺陷，產品進度的可預期性不高。同時，還能看到肯.施瓦伯在其博文中提到的ScrumBUT癥狀，比如常常聽到下面類似的說法：

　　每天站會開銷太大了，我們每周做一次吧;

　　回顧會議太浪費時間了，所以我們不做了吧;

　　兩個星期基本上什么也做不完，我們一個月算一次迭代吧;

　　經常來一些臨時任務，所以總是完不成Sprint計劃。

　　那么，到底是因為SCRUM不適合這樣的組織嗎?還是有別的原因呢?加入公司后，本人選擇了一個試點團隊，希望通過親自實踐，找到答案和改進方法。

　　最終選擇了一個由近百人參與的嵌入式產品開發項目，并在其中選擇了一個團隊，該團隊負責其中一個特性，開發是基于1500萬行以上代碼的一個遺留系統，編程語言是C++。

　　團隊共有九人，只有TeamLead在該代碼基礎上工作過兩年，其他人員均少于半年，有一個開發人員剛剛入職兩個月。

　　Team Lead：1人

　　Product Owner：1人

　　Architect：1人

　　Developer：5人

　　Manual Tester：1人

　　團隊工作過程中的白板演進

　　“似乎標準”的SCRUM白板

　　最初團隊使用較早的SCRUM白板格式，對用戶故事進行任務分解，而分解的依據之一是活動類型。而每個任務的估計使用絕對時間，并在每天早會上更新以時間為單元的燃盡圖。而每天早會上，看上去更像是團隊成員的工作匯報，每個人都關注于自己做的任務。而且每個用戶故事都很大，需要兩周或更多才能完成。

　　建立價值流導向的白板

　　為 了更好的發揮早會的作用，并為了更好地跟蹤項目進度，交付風險，團隊統一了 認識，即：任務并不是個人的最終交付物，而用戶故事才是團隊要交付的內容。每天的早會應該圍繞著用戶故事及用戶故事中所涉及的內容，而不是獨立的任務活 動。因此，我們在第一個迭代的第一周結束就改變了我們的白板樣式，把原來的任務活動變成了獨立的欄目，使每個人都關注用戶故事在白板上從左到右的流動速度。當然，也對用戶故事進行了分拆，使大多數用戶故事都可在一周內(不超兩周)開發完成。

　　“完成”標準化、明確化

　　在第一個迭代的回顧會議上，大家發現了一個問題，即：每個人對每個活動的結束標準不一致，有的人認為自己在紙上設計好自己開發的用戶故事后， 就可以把它放到“編碼”欄中了，而有的人則是寫好的代碼，才把用戶故事從“設計”欄直接放到了“測試”欄中。為了能夠讓團隊對協作過程達成一致，并明確每 個階段的完成定義(Definition of Done)，團隊把這些完成條件寫在了各欄目之間，以使每個人在移動用戶故事卡時都檢查一下。

　　“潛在問題”可視化

　　與此同時，我們還在每個用戶故事上記錄了它在每個階段停留的時間。經過一段時間，我們發現，即使不太復雜且比較小的用戶故事在設計階段的停留時間也顯得有些長，但不知道到底是什么原因。于是，我就跟蹤了其中的一個。結果發現，根據團隊的規則，每個用戶故事的設計完成條件是：設計好后需要發郵件，讓團隊review，review后根據反饋意見進行文檔修改，之后才能放到編碼階段中?？瓷先ミ€挺正常，但出問題的做事的方式。首先，每個開發人員在自行設計時都會使用電子工具來畫圖，在畫圖中每個人都很想把各種框的位置放好看一點，這上面花了較多的時間。其次，反饋意見來以后，還要有意見確認，有的意見還不一致，要再召集討論，然后再畫圖。其中的浪費非常明顯。于是，我們決定：在設計階段，當開發人員自己想好以后，可召集大家直接在白板前畫草圖討論，討論一致后，再根據一致意見，更新一下設計文檔即算完成設計。這樣就大大節省了在每個用戶故事上不必要的浪費時間。

　　應用約束理論，發現瓶頸

　　根據原定流程，團隊有一個code review的環節，這個環節被放在了“編碼”階段。這也導致用戶故事在編碼欄的時間過長，表現就是這一欄中經常會出來兩個故事卡片上有同一個人的名字。于是團隊決定把codereview單獨放在一列中。緊接著發現，codereview這一欄目中總會堆積卡片。經過分析發現，開發人員一般在完成整個用戶故事的開發以后才會做codereview，這導致一次review的代碼過多，review困難，時間過長，反饋太慢。另外，由于大家都有開發任務在身，所以總是以自己的開發任務為高優先級。為了根本解決這個問題，團隊制定了兩條新的規則：(1)原則上每天都需要提交一次codereview，而不是等整個用戶故事寫好后再做。(2)code review的優先級原則上高于之前的步驟(編碼和設計)。因為codereview更接近價值流的出口。這樣一來，用戶故事在codereview上基本不會停滯，所以，這一欄就又被從白板上擦掉了。

原文轉自：http://letagilefly.com/post/2013/01/what-if-scrum-fails-10070.html