l

2013年7月1日 星期一

誰來當Product Owner

June 30 10:20~12:19

螢幕快照 2013-06-30 下午12.18.45

 

一年多前有一次機會Teddy去觀察某個Scrum團隊運作,這個團隊是公司內部的研發團隊,主要的工作是開發後端管理平台讓公司維運人員使用。此外團隊還要提供API,讓其他部門的開發團隊可以透過API來和後端管理平台整合。這個團隊當時正準備啟動一個新專案,支援客戶(公司內部另一個部門)新的業務需求。

當Teddy參加完第一個sprint planning meeting之後,發現了一個有趣的現象,就是「沒有人願意承認自己是Product Owner」。

***

Teddy :請問你們的Product Owner是誰?

團隊:應該是客戶吧,因為他們有權決定需求的先後順序。

Teddy :那你們的客戶有寫story嗎?

團隊:沒有耶,story是我們大家分著一起寫出來的。客戶不會寫,應該也沒時間寫story,他們還有很多事情要忙。

Teddy :那你們怎麼知道要寫那些story?

團隊:因為這個專案不是一個全新的專案,而是已經開發好幾代的系統,現在只是要在上面加一些新功能。我們大致上知道有那些功能要做,只是誰先做以及一些需求上的細節需要跟客戶確認。

Teddy :所以你們自己先把你們認為要做的story寫出來,然後利用sprint planning meeting的場合跟客戶確認?

團隊:差不多是這樣。

Teddy :那請問如果這個案子失敗了,要由誰負責?

團隊:這…很難說耶。案子失敗了我們的考績和客戶的考績都會受影響…

Teddy 內心獨白:所以就是說…沒有人需要負責挑眉質疑

Teddy :那你們團隊為什麼不指定一個人來當Product Owner呢?

團隊:不行啦,需求的內容和優先順序又不是我們決定的…

Teddy :你們可以把客戶當成stakeholder,然後在團隊成員中指派一人當Product Owner。雖然說需求的內容和優先順序是由客戶(stakeholder)決定,但是一但你們指派了團隊成員當Product Owner,也可以想成Product Owner參考stakeholder的意見來決定需求的優先順序。請參考下圖。

螢幕快照 2013-06-30 上午11.12.21

 

團隊:可是這樣就變成我們要承擔案子的成敗,這樣也不合理啊。我們的人變成Product Owner之後,說不定客戶就偷懶,以後就不來參加sprint planning meeting了…

喬了老半天,結果這個案子還是在「不知道誰是Product Owner」的情況下繼續進行。

案子最後是有順利完成,從「結果論」來看,這種「不知道誰是Product Owner」的情況好像也沒什麼重大缺點。但是Teddy內心還是覺得,就算是要採用這種「不知道誰是Product Owner」的運作模式,開發團隊還是應該要指派一人作為「地下 Internal Product Owner」,由此人來統整從stakeholder與開發團隊而來的需求,並且要安排足夠的時間給「Internal Product Owner」,讓他可以扮演好這個角色

***

最近重讀Alexander的《Notes on the Synthesis of Form》,再回頭思考這個問題。假設在導入Scrum之前,開發團隊與客戶的溝通模式,可能是下方左圖或右圖的狀態:溝通複雜度過高(光是找到對人的來問問題就花了很多時間)或鮮少溝通(結案的時候才一翻兩瞪眼)。

螢幕快照 2013-06-30 上午11.41.30          螢幕快照 2013-06-30 上午11.33.22

 

如果是採用「標準版」的Scrum,團隊中會包含一位Product Owner(PO),由他來和客戶溝通需求。兩個子系統(客戶和開發)內部的溝通複雜度可以很高(內聚力很高微笑),但子系統之間的溝通複雜度由Product Owner隔開(降低不必要的耦合)。

螢幕快照 2013-06-30 上午11.25.36

在「不知道誰是Product Owner」的情況下,Product Owner的責任由客戶與團隊共同分擔。其實開發團隊還是有一個主要的人扮演著「Internal Product Owner」的角色,只是扮演這個角色的人不願意公開承認(雖然再度違反了Scrum的規範,在這種情況下此人通常是由ScrumMaster兼任)。

螢幕快照 2013-06-30 上午11.26.15

***

Product Owner是一個很辛苦的工作,在某些專案中,要找到願意且有時間、有能力接受挑戰來擔任Product Owner的人的確是非常困難。公司內部IT部門協助其他部門的專案開發就是一個很典型的例子,接外包案的專案也有類似的問題。Teddy目前的經驗,在這種「不知道誰是Product Owner」的情況下要成功,最好要把握以下幾點原則才不至於逆練九陰真經練到走火入魔:

  • 要把客戶洗腦到能夠接受專案採用value-driven的方式開發。
  • 客戶要一起參加sprint planning meeting (part 1)與sprint review。
  • 團隊指派一人作為「Internal Product Owner」,並給他足夠的時間來扮演好這個角色。
  • 把客戶的考績跟自己的考績綁在一起(目標一致,大家在同一艘船上)。

***

友藏內心獨白:Alexander的書真的有提到內聚和耦合的觀念啊。

沒有留言:

張貼留言