什麼還要分組？不是讓大家一起做細化、做估算的嗎？

敏捷聖賢：是這樣的，我曾經帶過一個Team，有10個人。最初，我都是開啟投影儀，把Product　Backlog投到螢幕上去，大家一邊說，我一邊敲，我是挺忙活的，但是大家卻不一定都能集中注意力。現在回頭看看，這種方法真是有點蠢！當Team成員少的時候，在最初的幾個Sprint，大家在興趣還比較高的時候，這種方法還行。當Team成員超過6個的時候，問題出現了，首先是當討論某一個問題的時候，總會有人問，剛才你們說什麼來著？很顯然，他走神了。另外，人多的時候，對同一個任務的細化，即使採用Delphi方法，溝通成本也很高，很費時間。

阿捷：那你們具體怎麼做的？

敏捷聖賢：後來我就把Team分成兩個小組，分別對任務進行細化。細化時，不再用投影儀，而是把Sprint　Backlog中的內容按大塊張貼在牆上，大家站在牆前，拿著記事帖直接進行細化和估算。當兩個小組都進行完後，互相檢查對方對任務的細化，解決爭議，澄清模糊的地方。這樣一來，就把大家的積極性調動起來，參與程度非常高，效率也高。

阿捷：雖然我們團隊現在只有5個人，估計還用不上，但這個經驗真的值得推廣。

敏捷聖賢：產品負責人（Product　Owner）一定要參加。實在不能參加的話，也要指定一個人授權代理。否則，就不要開Sprint計劃會議。

阿捷：嗯，我一定會把他叫過來參加這個會議的。

敏捷聖賢：最後一點，雖然我們採用了Scrum，但即使不再採用Gatt圖，但是傳統的Risk/Dependency分析還是不要丟棄。在Sprint計劃會議結束前，進行Risk/Dependency的分析，還是會幫助我們發現一些問題的，然後再稍微重新調整任務的優先順序，更能保證Sprint的成功。

阿捷：好的！有了這些指導原則，我相信我們的第二個Sprint會走得更好的。

敏捷聖賢發過來一個不斷眨眼的笑臉，似乎提醒阿捷不要過於樂觀。

阿捷：還有一個問題就是，我感覺這個Scrum好像只定義了一個專案管理框架，沒有給出具體的程式設計實踐指導，是你還沒告訴我嗎？

敏捷聖賢：嗯，不是的。Scrum依靠的是經驗管理，所以他沒有定義出很細的工程實踐。這樣才能很好地跟組織原來的工程實踐融合起來，譬如跟CMM、ISO　9000、RUP，甚至XP等都能很好地工作在一起。因為Scrum主要是想解決專案管理和組織實踐範疇的東西，更多的是關注在敏捷團隊建設上，它的終極目標就是自我管理自我組織的高效團隊。作為一個敏捷框架，具體的程式設計實踐，可以靠XP去補充。但我還是建議你們，最初先努力適應這個框架，待成熟後再考慮引入其他敏捷實踐。

阿捷：好的！這次我不會冒進的。？

敏捷聖賢：那就好！凡事預則立，不預則廢。對形勢做出良好的判斷並提前做好準備還是非常有必要的。我要下了，有事咱們再聯絡吧。

阿捷：多謝。886。

敏捷聖賢：886。

今天的收穫太大了，阿捷重拾起了Scrum的信心，準備帶領TD團隊再次快跑。

。　最好的txt下載網

第6章　不僅僅是站立（1）

The　way　ahead　is　long；　I　see　no　ending；　yet　high　and　low　I’ll　search　with　my　will　unbending。

路漫漫其修遠兮，吾將上下而求索。

——屈原《離騷》

根據敏捷聖賢的建議，如果想真正搞好Scrum，就必須有專門的Product　Owner負責維護Product　Backlog才行，這事得趕緊解決，否則，以後的Sprint　Planning會議不僅開不好，而且每個Sprint肯定又問題多多。阿捷想了想，這事只有李沙最合適。李沙是負責Agile國內OSS產品的Product　Manager，阿捷決定請他出山擔任Product　Owner。

李沙個子有米高，四方臉，稍微有點瘦，是個典型的東北大漢，平時總是西裝革履。因為同是公司籃球隊裡面的，大家經常一起打球