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

　　減少不必要的任務切換

　　隨著開發的進行，功能越來越多。我們發現，測試環節中發現的問題也多了起來。然而我們采用測試用例先行的開發方式不應該引起這么多問題(即在寫實現代碼之前，對用戶故事及相關功能的測試用例已經完成，并經過團隊的review)。 在回顧會議中，測試人員提到這一點時，說有時候明確的用例都無法測試通過。根據大家的意見，在白板上增加一欄，叫做“開發測試”，就是開發人員編碼結束 后，根據已寫好的測試用例，要做明確地自測后，才能放到“測試”一欄。從這之后，一些很低級的缺陷就不會流到“測試”這個環節了，開發人員減少了不必要的 任務中途切換。

　　拉響警報，限制“在制品”數量

　　當功能點開發過半以后，測試人員在回顧會議上提出，測試任務就越來越重。此時出現的現象就是在測試一欄中會堆積很多用戶故事，等待被測試。而沒有被測試驗證通過，就不能算是完成。因此，即使開發工作進行得再快，也無法說“完成”。根據團隊的討論，采用了精益中“限制在制品”的概念，但并沒有直接設定在測試欄中用戶故事的數量，而是使用另一種方法，來達到類似的效果，即：每天早會上，大家會問測試人員是否能在當天測試完當前待測試的用戶故事。如果完不成，則可以根據情況采用兩個措施：(1)是否能找到外部資源，幫助完成測試;(2)如果不能，根據任務多少，停止部分開發活動，由開發人員幫助測試人員進行測試，條件是：開發人員不能測試自己開發的用戶故事。

　　白板的演進只是冰山的一角

　　在白板的演進過程中， 我們使用了一系列工具，包括價值流分析、“看板”工具、系統思考、“五個why”分析以及精益思想中的限制“在制品”等等。然而，并不是說，我們放棄了SCRUM中的那些實踐(如迭代計劃會議、站會、迭代演示、迭代回顧會議)。恰恰相反，對于白板的很多改進正是在這些活動中討論并決定的，尤其是站會和回顧會議。

　　另外，團隊還應用了很多其它實踐，包括用戶故事的細粒度拆分、相對估算方法、基于RAID的敏捷迭代計劃、編寫單元測試、從分支開發切換為主干開發、嚴肅的代碼規范(如圈復雜度不得超過10，每個方法的代碼不超過50行)、每日提交代碼、測試先行方法、使用GIT版本控制工具提高效率等等。

　　收益

　　比原定計劃完成了更多的功能點;該特性無需缺陷修復階段，且產品測試沒有發現缺陷;團隊各角色合作順暢，團隊幸福感提升。

　　小結

　　老子云：“天下大事必作于細，天下難事必作于易”。SCRUM方法是一個簡單易懂的軟件開發框架，而“把簡單的事做好”并不是一件容易的事情。只有理解了敏捷的價值觀與原則，才能真正發揮作用，而“照貓畫虎”，只能反受其累。同時，大型企業采納敏捷方法時，也需要充分考慮“跨越鴻溝”時帶來的風險，做好準備工作，否則可能會令員工士氣低落。

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