iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 10
0
Agile

UP, Scrum 與 AI專案系列 第 10

Product Owner, Scrum Master

儘管眾人期待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 成員的素養要求很高,他們必須能協同合作來完成專案分內的所有工作,應該是自主管理讓專案有效率的執行。但是出現老闆級的成員就很容易變成指揮式的管理,大家看到問題或是有意見就不會暢言,會變得比較不積極。”

Scrum From Wiki

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

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

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

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

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


上一篇
UP-Scrum對比
下一篇
進一步了解UP, Scrum 差異
系列文
UP, Scrum 與 AI專案31

尚未有邦友留言

立即登入留言