從07年中初次接觸Scrum的概念到其中幾年項目中逐漸實踐CI、TDD，到親自掌握項目實踐Scrum近一年，最終我們放棄了Scrum這個框架和所謂的“自組織”。原因為何？

　　1. 成員放棄了Scrum所“賦予”的“權利”

　　比如領用任務、評估工作量、自組織協作、決策等。在第一次Scrum計劃會議上排出任務讓大家領用時，成員的態度可以用“反感”來形容。在經歷四個Sprint后成員依然堅持認為，應為PM完成這些工作，故放棄。

Gopher的評論：

你缺乏對程序員足夠的培訓，為什么要切分任務、評估工作量，對比以前，我們需要解決什么問題？為什么人家會反感，估計是開會前缺乏足夠的準備，PO自己都解釋不清楚需求，慢慢的會議發展為頭腦風暴。并且會議主持人對這種明顯超出討論范圍的亂象并沒有及時制止。

所以，結論是：1、你自己都沒搞清楚為什么搞敏捷。

2、因為你沒有搞清楚，所以你缺乏實施敏捷的路線圖。

3、因為沒有路線圖，所以在人員選擇上，你找了一群沒有“敏捷人格”的人來做敏捷。

　　2. 團隊成員能力參差不齊

　　我很主觀地認為，現在國內的開發團隊都會是一部分高級工程師搭配一部分初、中級工程師，這種搭配本身就決定了領用任務時的混亂，尤其是團隊中一部分成員極度渴望去做那些自己沒有經驗的任務。結果造成一部分人一直搞不清楚自己在團隊中的定位，一直處于“費力不討好”的挫折中。高級工程師對另一些成員的效率、成果也頗有微詞，對團隊分工非常不滿。

Gopher的評論：

根據團隊的velocity，我們通常會對需求的粒度進行要求（這點也是我們敏捷QA的度量目標）。在確定需求粒度之后，任務切分肯定是全體團隊成員一起進行的。如果有Issue，就記錄并落實Issue責任人，同時解決Issue也形成任務并需要評估時間。當然，長官意志必不可少。

擺明了這人承擔不起這項工作（解決Issue都有問題）你也讓他選？找死！

擺明了這人面臨的任務有多個待解決的Issue（導致團隊工作延后）你也敢讓他做，找死！

能力參差不齊不是關鍵，關鍵的是，scrum master缺乏控場技巧和領導力。這樣的水平，當PM都成問題。

　　3. 沒有清晰的設計階段是造成上面第2個問題的另一個因素

　　眾所周知，敏捷倡導演進式架構，其本質是，在目標不確定性極大的情況下，通過一次又一次短周期的反饋修正來不斷接近目標，固在敏捷中，每項任務、剩余工時、成本燃盡，控制得如此之細，CMMI根本扛不起這樣恐怖的基線變化次數。取消清晰的設計階段，以及采用大量并行的測試，可謂敏捷的一種取舍，贏取更短的發布周期。也正因為如此，在任務分解時，無法清晰地定義設計任務，而將其混雜在功能化的任務中，事實說明，這里有大量的重復工作并且交付良莠不齊。

Gopher的評論：

首先，CMMI的基線并非通常意義上的敏捷的“廣泛認可”或“增量輸出”。所以CMMI在配置管理和質量管理的基線標準不會定義得如此變態。

再次，“清晰”是相對的，在我們的公司里面，一個成熟的敏捷團隊，不用將任務粒度劃分得過細。而一個才成立的團隊，任務粒度幾乎就是流程圖級別的。當然，無論資深還是新手團隊，Scrum Master必須是資深的。

最后，你的團隊無法“清晰”的定義任務，要么是PO沒有做到位，要么是成員不了解需求。對于團隊中的資深的“個性”程序員，那么，尊重他們個性好了。也就是我說的，長官意志。

　　4. 高估了工程師的成熟度

　　敏捷對工程師的心智有過高的要求。為什么說是過高？其實，在公司里擔任高層管理人員的，恐怕都不具備成熟的心智，何況處于一線年輕又尚輕的程序員？現在的程序員，從學校或從培訓班子里出來，人際圈子小，知識面狹窄，遇事僅能從自身考慮，常常因生活中一些事情影響情緒和工作，遇到難題就放棄，全力投入到項目開發中來的并不多見。所以，在項目和開發過程中，監控、管理，催促、激勵甚至批評，是必須的！

Gopher的評論：

在我的實踐經驗中，這種人最好培養。你們不會是因為成本考慮找的實習生吧。如果團隊都是高手，我想這種團隊，無論CMMI還是敏捷都不重要了。

　　5. Scrum缺乏領導者

　　Scrum把團隊想象得太完美了，如果有完美的團隊，開發方法根本就不重要。工作、項目在進行的過程中，必須會遇到困難、遇到卡殼、團隊發生沖突和爭吵，這時候，必須有一個人挺身而出，作出決定，解決問題，為大家指明方向，平息爭端，警告不利分子，這個人只能是領導人物，能力、權力和職位比團隊成員高的人。扁平式組織，想象得太完美了，團隊里各種性格的人都有，不服你不爽你的也總有人在，吵個沒完沒了，各做一套，家常便飯。

Gopher的評論：

會議主持人能力相當重要，并不是每個人都可以做Scrum Master的。爭論，是我最喜歡看到的情況。有分歧才有爭論，有爭論才有更詳細的任務目標。關鍵是，你真的嘗試過去引導爭論并使之切題？

　　最后我想說說Scrum適合的團隊，這樣的團隊需要有一些技術成熟度比較高（五至八年經驗）、并且比較穩定地做技術的成員，使用Scrum可以使團隊日益默契，并改善技術團隊溝通交流不善、積累反思不多的常見問題。基本上，Scrum的正面意義在于，以前的項目管理、開發管理都只注意到了需求、技術、測試等機械性問題，而Scrum把團隊管理、團隊建設的思路引進到了技術團隊。而在這個范疇里，Scrum還比較輕量級，它的回顧會議在工業產品開發中隨處可見，可作入門指南，大家會問，進階怎么走？我想未來軟件開發團隊的路子會和工業產品相似，漸漸地把決策過程、分析思路引進到團隊中，這樣子的團隊才真正是一個“工程師團隊”。

it知識庫：Scrum之成敗——從自身案例說起，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。