儘管眾人期待Molly 談談採用Scrum的那個非軟體專案，聽故事比較有趣。Molly 堅持要大家一起理解 Scrum，知道UP 與 Scrum 差異後再來舉實例說故事。

“基本上Scrum每個Sprint 與UP 每個 Iteration 的時程由經驗法則上是一樣的大約2-4週! 每個 Sprint 的工作內容是依照 Product Owner 排定的Product Backlog 或翻譯為產品代辦清單來做計畫，圖上的 PBI, Product Backlog Item 待辦事項就是其內容。這個過程相當複雜，有理說不清，我盤算等到有確認要用Scrum 後，我們邊做邊討論”

“我個人將Product Owner想成最終要扛專案成敗的那位，他有責所以有權，反應出來最重要的工作是獲取跟專案有利害關係的客戶，主管，同事，投資人的期望或是要求，排定優先順序重要等級，然後驅動團隊完成。Product Backlog 初始的內容來自這些期望或是要求。但是後來也慢慢不得不加入一些行政庶務，例如：設備採購，辦激勵團隊的旅遊; 也可能之前的 Sprint 已知的Bug 要修改等等; 有時甚至會加入協助 Product Owner 製作產品展示用的簡報”

佳麗好奇：”那由誰製作類似 Buiness Case 或者 Use Case 或是類似的分析文件? 轉換這些期望或是要求成大家共識，我認為很重要。 一般要扛成敗的人，看來就是 Product Owner，哪有時間去需求訪談，製作文件那開玩笑了”

Molly：”我以待過的新創公司為例，文件並不被重視，重點在於Product Owner 能簡略表達出使用的情境，有人是製作所謂的 User Story，我們做開發的人很快速的製作出 Prototype，他看過後，能接受即可。至於比較正式的作法我也聽過，Product Owner 就直接在Product Backlog 加一條『製作系統分析文件』的待辦事項PBI即可，開發人員就必須選擇進某個Sprint，而且要有能力完成。”

Pete 好奇：”我看圖裡面有三種角色--除了Product Owner, Scrum Master 另外就是Development Team, 難道 Product Owner 不可以下來當 Development Team成員??”

“如果只講理論，是可以的。但是我幾次專案的經驗，我個人不建議Product Owner 下來當 Development Team成員。理由除了照顧專案利益本身是很傷神的，最最讓我怕的是地位不對等。本來Scrum對 Development Team 成員的素養要求很高，他們必須能協同合作來完成專案分內的所有工作，應該是自主管理讓專案有效率的執行。但是出現老闆級的成員就很容易變成指揮式的管理，大家看到問題或是有意見就不會暢言，會變得比較不積極。”

Gavin 趁機要求：”要不一起把Scrum Master這角色也說一下吧？”

“Scrum Master 是我最搞不懂的角色，我個人感覺是顧問性質，指導團隊還有公司其他人了解 Scrum，遇到Development Team 在Scrum型的專案執行不順或是觀念或方法有偏差時，給予指導。不過我個人對這種顧問角色有偏見：顧問不就是看著你頭上沒被自己注意到的時鐘，告訴你現在幾點幾分。但是解決不了經常有人會遲到的問題。”

“我有不同看法，如果是這樣 Scrum Master 必須是對組織很有影響力的人，他有Scrum 的知識也體會到Scrum可帶來公司的利益，然後給予支持的同仁獎勵，甚或踢走一些為個人利益而唱反調的人”。Gavin 活過該公司幾次變革的考驗，知道推動制度相當的困難。

這個佳麗馬上有感：”是啊，當時大老闆要推 Unified Process 走了一些人，也是說理念不合。也真多虧是大老闆親自推動，不然這個 UP 大概只在SM公司玩玩就結束了，不會變成現在我們公司的標誌。也許我們除了叫 Servo 大老闆，還要尊稱他為 UP Master”

Molly 似乎也頓悟 Scrum Master 的重要性，之前都是創新小公司，組織小較靈活，所以她感受不到推動一項制度是蠻艱鉅的。看來這場交流會雙方都獲益了。