敏捷Scrum培訓有感

      InfoQ網站上有兩篇介紹Visual Studio產品團隊敏捷實踐經驗的中文文章，推薦給大家！

《大型軟體開發項目中的功能小組模型── Visual StudioTeam Dev的敏捷實踐經驗分享（一）》

《功能小組模型的過程與品質控制 - Visual StudioTeam Dev的敏捷實踐經驗分享（二）》

 

 

題外話：前天聽說歐盟也無條件批准了Oracle對Sun公司的收購，雖然還需要等待俄羅斯和中國等國家的批准，但相信那隻是時間的問題了。一個曾經在軟體行業無比輝煌的公司，一個曾經締造了眾多頂級軟體和硬體（Solaris、Java 、MySQL）的公司，就這樣說沒就沒了，真是不敢相信。“江山代有人才出，各領風騷數百年”，對於IT行業可用不了數百年了，也就是數十年吧，應該改為“市場代有人才出，各領風騷數十年”。市場的選擇是無情的，倒下了一個Sun，還會有更多站起來。     

      今天（2010/01/23）是周六， 一整天都在參加InfoQ在上海閔行紫竹微軟新園區舉辦的“京滬兩地敏捷Scrum訓練營”上海站的活動。活動分為上下兩場：上午主要是由雅各布森公司吳穹博士的“敏捷式軟體開發 (Agile Software Development)之Scrum實踐（上/下）”，介紹敏捷開發和Scrum的北京和理論方面的知識；下午是由微軟鐘鳴所做的“大型團隊中的Agile-微軟研發團隊的敏捷開發實踐”和北京金橋公司王然的“基於Visual Studio 2010大型敏捷項目開發”，分別介紹了微軟開發工具部門上海團隊所採用的Scrum流程和經驗，以及如何採用Team Foundation Server 2010來進行敏捷項目開發。總體來說感覺還是不錯的，理論+實踐經驗+工具，應該是不錯的搭配。

      我所在的Team Dev已經成功的應用Scrum有段日子了，但通過這次培訓，對以前一些模糊的概念得到了澄清，瞭解了一些新觀點和名詞，觸發了我的一些新想法，還是頗有收穫的。下面是些具體的收穫和見聞，給大家報告如下：

 

不要誤讀敏捷宣言

      下面四條就是敏捷宣言（Agile Manifesto）的內容，往往會被敏捷的“粉絲”或者激進者誤讀，或者用來誤導領導。 他們通常會把這裡的over翻譯為“不需要”或者“不要”等。敏捷看似是《笑傲江湖》中的“獨孤九劍”，以無招勝有招，但那要看是誰來用，並不是人人都可以的。只有風清揚這樣的super senior前輩，和令狐沖那樣的super smart晚輩才能真正用得上“無招勝有招”，才能真正可以把over翻譯為“不要”。而我等泛泛之輩，只能將其翻譯為“重於”，也就是說，對於絕大多數（99.99999%）的團隊而言，在敏捷開發中，方法、文檔、工具合約以及計劃都是必須的，區別在於要讓它們的存在更合理有效，不要動輒就是幾百頁無人願看的文檔。

• 個人和互動重於方法和工具（Individuals and interactions over processes and tools）；
• 可工作的軟體重於完備的文檔（Working software over comprehensive documentation）；
• 與客戶的協作重於合約談判（Customer collaboration over contract negotiation）；
• 響應變化重於嚴格遵照計劃（Responding to change over following a plan）；

Be Agile rather than do Agile

       敏捷的本質是要找出開發流程中不合理和浪費資源的內容，並加以改進。只要所做的工作能達到這樣的效果的我覺得就是一種適合你的敏捷方法。而並不一定說是必須遵循別人的已有的方法和步驟才叫敏捷。而且往往是公司、人員和項目性質等不同，別人成功的敏捷應用絕大多數情況下是不適合你的。

敏捷多起於“草根”，而終於上層和老闆

      採用敏捷方法的提議多是從實際的Team Dev興起，而終止於老闆或者老闆的老闆。原因很簡單，一線的技術人員（技術癡迷者、技術憤青、技術Guru）對新的開發方法更為敏感和強烈的熱愛，他們經常會提出對現有流程好的改進意見。但很多敏捷方法涉及到對現有流程和人員組織圖的改變，如Scrum，沒有老闆的支援是絕難完成的。現在很多公司採用的是“弱項目，強職能”組織模式（不確定這是不是CMMI要求），而Scrum的Feature team/Feature crew的組織方式則正好是相反。

      相對而言，採用TDD和XP要簡單一些，兩三個開發人員就可以實施，不需要過多的組織調整。

 

推廣敏捷方法不是大躍進

 

     不要把推廣敏捷當成一場運動，不是要搬倒現有的一切而從頭來過，那樣只會招致更多人的反感和更大的阻力。存在的東西總有它合理的地方，推廣敏捷是針對其中不合理的東西進行漸進式的改變。要做到“隨風潛入夜，潤物細無聲”得推廣。當然這很難，只能是個奮鬥的目標和方向，做不到100%，達到個50-60%總是可以的。再說了，現在啥事不難呢，容易做就不找你了，是吧！

 

啥是ATDD?

       這是我在這次活動中聽到的一個新名詞，ATDD的全稱是Acceptance Test-Driven Development，也即是接受性測試驅動開發，它也是敏捷方法中的一種。

Scrum經典流程圖沒有指出Scrum的痛點

 

      

 

      Scrum最大的痛點應該說是Product Backlog到Sprint Backlog的任務挑選和分解的過程，這需要構架師的參與。另一個痛點是如何讓測試能跟上敏捷的步伐，特別是在當下仍以手工測試為主的情況下。

 

Scrum只會讓曾經愛偷懶的人感覺更累

       採用了Scrum方法，會不會讓團隊成員感覺更累呢？確切地說：它是讓那些愛偷懶的人更累了，呵呵。Scrum以專案管理實踐為核心，它不同於XP和TDD。它要達到的管理效果，我用16字總結如下：分工明確、責任到人、項目透明、過程可控。在相對開發週期比較短（一個迭代周期在2-4周）的情況下，每個人的時間分配和利用都比較明確，這樣就很難再有偷懶的機會了。

 

 

 

什麼是Scrum？

      Scrum一詞本意是指英式橄欖球的爭球，英文解釋是這樣的： (rugby) the method of beginning play in which the forwards of each team crouch side by side with locked arms; play starts when the ball thrown in between them and the two sides compete for possession。Scrum 將軟體Team Dev比擬成橄欖球的爭球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，確保每天、每個階段都朝向目標有明確的推進。

 

任何敏捷活動都應該是Time-boxed -“學生綜合症”

       有明確時間約束的活動才是更有效地活動，否則經常會為不必要的話題展開冗長而無結果的討論。“學生綜合症”告訴我們只有在考試前那段時間才是學習效率最高的時候，同樣到的現象的也存在項目開發中。只有到最後快要提交的時候，大家才會擱置不必要的意見，達成可接受的公示。

 

將Scrum master比喻為Scrum小組的"牧羊犬"，很恰當！

       保證Scrum過程的順利進行，這樣的牧羊犬的職責是明確：對外保護“羊群”不受“狼群”幹擾，對能保證“羊群”按時、按量吃草。

 

什麼是敏捷？

      敏捷是一個組織素質，也包括組織成員素質。它代表了一組體系和原則，它們的目標是使組織變得更能夠自適應，反應更迅速以獲得商業成功。

 

 

 

“排隊原理”- 給每個人的時間安排到100%並不是一件好事

      經常會發現路上塞車並一定應為出事故了，排隊原理解釋了這種塞車出現的原因，以及對Team Dev的啟示。

 

 

成熟的敏捷團隊是相對穩定的組織

      敏捷團隊不是遊擊隊，打一槍換一個地方，人員經常分撒變動。成熟的敏捷團隊是相對比較穩定，大家能夠在一起經曆多個Sprint。其中的道理很簡單，人員和組織的磨合是需要時間和成本。