Scrum之成敗:從自身案例說起,僅供參考

發表於2011-05-19

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

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

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

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

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

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

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

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

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

5. Scrum缺乏領導者

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

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

原文:陳加興

 

相關文章