敏捷中Scrum開發流程的問題和經驗

　　鄒欣是工作于微軟亞洲研究院的研發經理，同時也是《編程之美》和《移山之道》的作者。前不久，他在博客上總結了自己使用scrum開發流程的經驗。

　　在對Scrum的基本概念和流程做了簡單介紹之后，鄒欣提出幾個在實踐中會遇到的問題：

　　各個需求和任務之間是有種種復雜的依賴關系的，除了優先級之外， 我們還要考慮相互的依賴關系。怎樣在計劃中表現依賴關系呢?

　　如果團隊成員對某個任務不感興趣， 都不認領這個任務怎么辦?

　　有些成員的認領的任務很多， 有些成員認領的任務很少， 忙閑不均， 怎么辦?

　　每日立會流于形式怎么辦?

　　針對這些問題，鄒欣提出幾個改進方法：

　　定義好任務究竟是什么? 任務的完成 (done) 到底意味著什么? 每個人的任務必須是明確定義的

　　要在每一個任務中記載我們完成這個任務還需要多少時間。已經花了多少時間雖然重要， 但是不是關鍵 (那是沉沒成本)，關鍵是要看我們離最后目標有多遠。

　　有些燃盡圖只是列出了任務的數目， 這種圖無法展現項目的拖延， 一個任務有大有小， 它們在圖表中都是一個點， 一個16小時的任務需要3 天完成， 一個2小時的任務處于種種原因也花了3天時間， 他們在圖表中的表現是一樣的。 在實踐中， 我個人認為以時間為度量的燃盡圖更有效果

　　鄒欣接下來對于“任務完成”這件事又提出問題：

　　做過項目的人都知道， 當你說“任務都完成了”的時候， 那只是說， 開發人員認為該寫的代碼都寫完了， 還有很多事情沒做完。 例如寫一個Windows 客戶端的功能， 顯示一個新聞圖片加上和與它相匹配的文字 (假設這些圖片/文字都可以從互聯網上拿到) ， 做完之后， 還有下面的事情：

　　驗證這個功能顯示在WinXP， vista， win7， win2008 server R2， win2012 server 都顯示正確。 (開發人員表示自己的機器是win2008 server， UI 看起來不錯， 其它平臺想必也不錯!)

　　驗證這個功能的顯示布局和字體在100% 到150% 的DPI 上都顯示正確， 在各種色彩配置中都顯示正確。

　　驗證文字無論是中文， 英文， 阿拉伯文都能正確顯示 (聯合國五種工作語言我們得支持吧? )

　　驗證程序效能上沒有問題

　　……

　　誰來做這第三步半呢? 程序員寫完功能的時候， 我們感覺好像項目完成了 80%， 殊不知后面的20% 往往要花費80% 的時間， Sprint/Scrum 沒有明確表明到底 何人/何時/何種優先級 來完成這個20% 的任務。

　　對于測試人員的職責問題，鄒欣提出：

　　測試人員在一個沖刺中怎么工作呢? 有敏捷專家建議測試人員可以擔負起 Product Owner 的部分責任，同時掌握 Acceptance Test 流程， 對產品的最終質量負責。 但是測試人員的開發技術能力在團隊中并不占優 (在有些中國公司中甚至是最弱的一環)，他們在大家都要 “燒光”所有任務的壓力下，能擔當起 Product Owner 這一責任么?

　　上面這兩個問題，鄒欣并沒有給出明確的答案。

　　鄒欣認為：ScrumMaster是Scrum實施是否能夠成功的關鍵。

　　我聽到有些團隊也實施Scrum， 但是他們隨機挑一個成員來做 ScrumMaster， 好像 ScrumMaster就是招呼大家開開會， 記錄每個人的進度而已。這種方法失敗的可能性很大。 一個好的ScrumMaster 能在兩種語境 (描述軟件項目的商業語境，描述實現細節的技術語境) 自如地翻譯和切換，事實上是一個強有力的PM，如果團隊還要求她做全職的開發工作，這樣的人就更難找了。

　　不過鄒欣認為Scrum也沒有那么特別，它和質量控制理論的模型，比如經典的戴明環PDCA沒什么區別，在6西格瑪理論中也可以看到相似的流程——DMAIC(Define， Measure， Analyze， Improve， Control)，與漸進交付的流程(Evolutionary Delivery)也很類似。

　　對于Scrum團隊，鄒欣指出：自我管理、自組織、跨職能，這三點要求看似簡單，實際上很難做到。

　　自我管理：

　　以前領導布置了任務，我們實現就可以了，現在要自己挑選任務;每次sprint 結束之后，還要總結不足，提出改進，并且自己要實施這些改進。“自我管理”不等于“沒有管理”。

　　自組織：

　　以前做好自己的事情就好了，安心下班?，F在每個人要聯合起來對項目負責，有人工作落后了還要幫助他改進，項目缺少某類資源還要自己頂上去。

　　跨職能：

　　以前spec 由PM 來寫， test 由測試人員來做， 現在每個人都全面負責，自己搞定spec， 和別人溝通， 同時自己搞定測試。

　　他強調：

　　如果你的團隊很弱， 那么強行把Scrum (或者其它高級方法)套在上面也沒有用， 也許還會適得其反，往往需要多次Sprint 才能讓Scrum 走上正軌。換句話說， 如果你的團隊已經是這么厲害 (self-managing， self-organizing， cross-functional)的一幫人， 那么用不用Scrum 都能寫好軟件!

　　最后，鄒欣總結了一些實踐者的經驗教訓：

　　ScrumMaster 不是一個官，而是一個沒有行政權力的溝通者，就像微軟的PM 那樣。她同時還要在團隊中做具體的工作。直接把原來的 “經理”變成 ScrumMaster 大多行不通。

　　在一些公司中，不少項目需要很多暗箱操作和政治角力才能搞定， Scrum 會把這些矛盾都擺到明處。這有好處，也有風險。

　　在復雜的項目里，要讓一線團隊成員做決定。

　　創業公司的團隊其實經常是運行在 Scrum 的模式中 (只不過大家太忙，沒功夫論證到底多么Scrum)。

　　在Scrum 計劃階段的估計不是一個“合同”， 領導們不要把它當成一個合同。估計總是不準的。 堅持短期的Sprint，即使不準的估計也不會有大的損害。

　　不要和管理層談 “流程”， 他們只關心 “結果”。

　　在大型團隊，復雜項目中，Scrum 并沒有非常完美的答案，Scrum 的創始人也承認這一點。 (我曾看到30多人擠在會議室里搞 Daily Scrum，一嘆! )

原文轉自：http://www.kjueaiud.com