第9部分(第1/4 頁)

阿捷：這個問題的意義在哪裡呢？

敏捷聖賢：首先，Product　Owner可以根據它來構建釋出規劃；同時團隊可以根據它來真正改進流程。只有知道自己的速度如何，這有助於一個團隊進行更好的估算，同時幫助他們在繼續後續工作時提升速度。

阿捷：嗯，這已經有三個規則了，最後一個是什麼？

敏捷聖賢：Scrum團隊依賴自組織的過程，這就意味著團隊負責挑選工作、職責分配，並要找出最快交付工作的途徑。所以，Nokia的最後一條規則是：在迭代中，專案經理不能干涉團隊工作，因為這會停止自組織的過程，並且得到解決方案的過程將不再是最最佳化的了。

阿捷再次想起了Product　Owner的問題，趕緊問：為什麼非得要專門的Product　Owner？我代替不可以嗎？

敏捷聖賢：首先，產品Backlog是Scrum的核心，從根本上說，它是一個需求或故事或特性組成的列表，並且按照重要性進行了排序，一定是客戶想要的東西，並且用客戶的語言進行描述。產品的Backlog應該僅僅由那些產品相關的較大的任務（ticket）組成，有關在產品開發中完成某項工作時候涉及的東西，太細了就不適合。

敏捷聖賢：其次，在維護產品Backlog的時候，Product　Owner（就是那個能替最終客戶發言的人）必須參加，由他排列優先順序。Product　Owner必須是離客戶最近的人，你作為研發專案管理人員，不可能是離客戶最近的人。如果沒有這個角色，你們怎麼知道哪個重要哪個不重要？和Product所有人交流，你們才可以做出來一個有優先順序的列表，把最重要的功能放在列表的前面。

阿捷：我知道了，看來我得找Product　Manager來擔任這個角色才行。那這個Backlog條目除了優先順序外，還有其他什麼要求？

敏捷聖賢：嗯，每一個條目應該有估計完成時間，這個並不需要很準確。我們只需要有一個大概的估算即可，這樣才能夠決定把多少工作放到一個Sprint裡。

敏捷聖賢：另外，在你開sprint規劃會議之前，你的產品Backlog應該保持一種合適的格式。你可以是把它們都放在一個Excel中，也可以是一個Word文件，或者是某種Scrum工具中……採用哪種形式都可以，只要你們自己覺得方便就行。

阿捷：嗯，我用了Excel。

敏捷聖賢：Sprint計劃會議除了你的團隊成員和Product　Owner外，還可以邀請更多的人參加。

阿捷：我還以為我一個人規劃Sprint就可以了呢。

敏捷聖賢：那是舊的管理模式。在Scrum框架下，沒有“個人”的概念，Scrum依靠的是團隊的力量。儘管Scrum　Master在這個框架下的作用很重要，但這個人不是*者。做Sprint計劃時，一定要讓整個團隊參加。

第5章　成長的煩惱（5）

阿捷：那具體怎麼做呢？大家一起做計劃，豈不是很亂？

敏捷聖賢：首先，你們要先定下來Sprint的目標，即作為一個團隊，你們要完成什麼，然後再決定完成多少。

阿捷：我們當前沒有任何歷史參考資料，怎麼知道完成多少呢？

敏捷聖賢：事先計算出在一個Sprint內，團隊的可能工作時間。譬如，在未來三週內，一個5人小組，每人每週工作40小時，那麼總的工作時間=5×40×3=600小時。

阿捷：理想情況是這樣的，但肯定會有人休假的。

敏捷聖賢：對，所以你要將總的工作時間扣除任何預期的非工作時間。譬如，有一個人要休一個禮拜的年假，還有人要看牙，需要佔用3天，這樣算起來是600…5x8…3x8=536小時。

阿捷：還有，即使每人每天工作8小時，但也不是會真的有8小時工作在專案上，還要參加各種Tea　Talk、培訓、Team　Building等活動。

敏捷聖賢：如果每天8小時，你們大概會有幾小時工作在專案上？

阿捷：平均差不多6小時吧。

敏捷聖賢：你得把每天花在參加會議、談話、處理郵件、上網等時間都除去。

阿捷：那估計5小時。

敏捷聖賢：我們把它用百分比