鄒欣是工作於微軟亞洲研究院的研發經理，同時也是《
程式設計之美》和《移山之道》的作者。前不久，他在部落格上總結了自己使用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 結束之後，還要總結不足，提出改進，並且自己要實施這些改進。「自我管理」不等於「沒有管理」。
自組織：
以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對專案負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。
跨職能：
以前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，一嘆! )
在結尾時，鄒欣提出：
scrum不是 「銀彈」，不能解決軟體開發的所有問題，至於具體專案進度如何跟蹤， 如何管理測試工作，如何管理複雜專案， 還要靠戰鬥在一線的團隊成員見招拆招，想出合適的辦法。
Scrum敏捷開發流程
1 我們首先需要確定乙個 product backlog 按優先順序排列的乙個產品需求列表 這個是由 productowner 負責的 2 scrum team 根據product backlog 列表，做工作量的預估和安排 3 有了productbacklog 列表，我們需要通過 sprint p...
敏捷開發 自用SCRUM專案開發流程
目前團隊所使用的開發模式流程，請大家指正優化。1.pm需求整理 在禪道整理出需求清單和原型圖 標註清楚 需求評審。往復，直到需求定稿。2.sprintmaster根據需求清單進行技術任務拆解，包括前端ui設計 前後端開發等。3.程式設計師各自領任務，具體內部商定。3.每天早上站會過下任務進度。滬杭不...
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...