從07年中初次接觸Scrum的概念到其中幾年項(xiàng)目中逐漸實(shí)踐CI、TDD，到親自掌握項(xiàng)目實(shí)踐Scrum近一年，最終我們放棄了Scrum這個(gè)框架和所謂的“自組織”。原因?yàn)楹危?/p>

　　1. 成員放棄了Scrum所“賦予”的“權(quán)利”

　　比如領(lǐng)用任務(wù)、評(píng)估工作量、自組織協(xié)作、決策等。在第一次Scrum計(jì)劃會(huì)議上排出任務(wù)讓大家領(lǐng)用時(shí)，成員的態(tài)度可以用“反感”來形容。在經(jīng)歷四個(gè)Sprint后成員依然堅(jiān)持認(rèn)為，應(yīng)為PM完成這些工作，故放棄。

Gopher的評(píng)論：

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

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

2、因?yàn)槟銢]有搞清楚，所以你缺乏實(shí)施敏捷的路線圖。

3、因?yàn)闆]有路線圖，所以在人員選擇上，你找了一群沒有“敏捷人格”的人來做敏捷。

　　2. 團(tuán)隊(duì)成員能力參差不齊

　　我很主觀地認(rèn)為，現(xiàn)在國(guó)內(nèi)的開發(fā)團(tuán)隊(duì)都會(huì)是一部分高級(jí)工程師搭配一部分初、中級(jí)工程師，這種搭配本身就決定了領(lǐng)用任務(wù)時(shí)的混亂，尤其是團(tuán)隊(duì)中一部分成員極度渴望去做那些自己沒有經(jīng)驗(yàn)的任務(wù)。結(jié)果造成一部分人一直搞不清楚自己在團(tuán)隊(duì)中的定位，一直處于“費(fèi)力不討好”的挫折中。高級(jí)工程師對(duì)另一些成員的效率、成果也頗有微詞，對(duì)團(tuán)隊(duì)分工非常不滿。

Gopher的評(píng)論：

根據(jù)團(tuán)隊(duì)的velocity，我們通常會(huì)對(duì)需求的粒度進(jìn)行要求（這點(diǎn)也是我們敏捷QA的度量目標(biāo)）。在確定需求粒度之后，任務(wù)切分肯定是全體團(tuán)隊(duì)成員一起進(jìn)行的。如果有Issue，就記錄并落實(shí)Issue責(zé)任人，同時(shí)解決Issue也形成任務(wù)并需要評(píng)估時(shí)間。當(dāng)然，長(zhǎng)官意志必不可少。

擺明了這人承擔(dān)不起這項(xiàng)工作（解決Issue都有問題）你也讓他選？找死！

擺明了這人面臨的任務(wù)有多個(gè)待解決的Issue（導(dǎo)致團(tuán)隊(duì)工作延后）你也敢讓他做，找死！

能力參差不齊不是關(guān)鍵，關(guān)鍵的是，scrum master缺乏控場(chǎng)技巧和領(lǐng)導(dǎo)力。這樣的水平，當(dāng)PM都成問題。

　　3. 沒有清晰的設(shè)計(jì)階段是造成上面第2個(gè)問題的另一個(gè)因素

　　眾所周知，敏捷倡導(dǎo)演進(jìn)式架構(gòu)，其本質(zhì)是，在目標(biāo)不確定性極大的情況下，通過一次又一次短周期的反饋修正來不斷接近目標(biāo)，固在敏捷中，每項(xiàng)任務(wù)、剩余工時(shí)、成本燃盡，控制得如此之細(xì)，CMMI根本扛不起這樣恐怖的基線變化次數(shù)。取消清晰的設(shè)計(jì)階段，以及采用大量并行的測(cè)試，可謂敏捷的一種取舍，贏取更短的發(fā)布周期。也正因?yàn)槿绱耍谌蝿?wù)分解時(shí)，無法清晰地定義設(shè)計(jì)任務(wù)，而將其混雜在功能化的任務(wù)中，事實(shí)說明，這里有大量的重復(fù)工作并且交付良莠不齊。

Gopher的評(píng)論：

首先，CMMI的基線并非通常意義上的敏捷的“廣泛認(rèn)可”或“增量輸出”。所以CMMI在配置管理和質(zhì)量管理的基線標(biāo)準(zhǔn)不會(huì)定義得如此變態(tài)。

再次，“清晰”是相對(duì)的，在我們的公司里面，一個(gè)成熟的敏捷團(tuán)隊(duì)，不用將任務(wù)粒度劃分得過細(xì)。而一個(gè)才成立的團(tuán)隊(duì)，任務(wù)粒度幾乎就是流程圖級(jí)別的。當(dāng)然，無論資深還是新手團(tuán)隊(duì)，Scrum Master必須是資深的。

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

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

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

Gopher的評(píng)論：

在我的實(shí)踐經(jīng)驗(yàn)中，這種人最好培養(yǎng)。你們不會(huì)是因?yàn)槌杀究紤]找的實(shí)習(xí)生吧。如果團(tuán)隊(duì)都是高手，我想這種團(tuán)隊(duì)，無論CMMI還是敏捷都不重要了。

　　5. Scrum缺乏領(lǐng)導(dǎo)者

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

Gopher的評(píng)論：

會(huì)議主持人能力相當(dāng)重要，并不是每個(gè)人都可以做Scrum Master的。爭(zhēng)論，是我最喜歡看到的情況。有分歧才有爭(zhēng)論，有爭(zhēng)論才有更詳細(xì)的任務(wù)目標(biāo)。關(guān)鍵是，你真的嘗試過去引導(dǎo)爭(zhēng)論并使之切題？

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

it知識(shí)庫：Scrum之成敗——從自身案例說起，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。