產品負責人與團隊該如何協作?


本文來源於我在InfoQ中文站翻譯的文章,原文地址是:http://www.infoq.com/cn/news/2013/02/product-owners-teams


近日,由Henrik Kniberg撰寫的博文agile product ownership in a nutshell從產品負責人的角度高度總結了敏捷軟件開發。Henrik稱其為“將一天的產品負責人課程壓縮為15分鍾的精彩介紹”。他建議大家觀看一個關於敏捷產品所有權的視頻,該視頻提供了相應的腳本。下面介紹了該視頻所涵蓋的內容。

在Scrum中,利益相關者需要將使用用戶故事表述的東西放在隊列中。這個隊列叫做產品訂單,由產品負責人負責:

產品負責人決定將什么放進去,什么拿出來。產品負責人還會決定順序——什么東西需要現在構建,什么可以放在后面進行?這個工作不好做,需要與團隊和利益相關者協作完成。

產品負責人需要與團隊協作來管理產品訂單:

這些問題我一直在談——估算故事的價值與大小、優先級、划分——所有這些通常叫做“訂單梳理”。Pat會在每個周三的11:00到12:00召開訂單梳理會。整個團隊都會參加,有時一些利益相關者也會參加。會議議程會不斷變化,有時關注點放在估算上,有時放在故事的划分上,有時還會為故事編寫驗收標准。

對於軟件產品的開發來說,每個Scrum角色都會有自己的關注點:

各個Scrum角色之間應該保持健康的關系。產品負責人關注構建正確的東西。團隊關注正確地構建東西。Scrum Master或是敏捷教練關注縮短反饋回路。

產品負責人應該與團隊協作來平衡質量與進度:

如果團隊積累了技術債務(沒有編寫測試、沒有持續改進架構),那么團隊的速率將會隨着時間的推移變得越來越慢,故事燃盡曲線將會變平。這使得預測變得幾乎不可能。因此,團隊要負責保持可持續的節奏,產品負責人不應該對其施加壓力導致其走捷徑。

擁有多個團隊的大型項目會有一個以上的產品負責人。產品負責人之間的協作是非常必要的:

但在多團隊的情況下,產品負責人還有一個額外的重要職責——彼此交流!我們應該組織團隊與訂單以最小化依賴。但總還是會有一些依賴!因此,產品負責人之間應該進行某種同步,這樣才能按照順序構建,避免局部優化。

Mountain Goat Software在learning scrum – the product owner中介紹了產品負責人這一角色。產品負責人知道應該構建什么,並向Scrum團隊表明這一點。團隊會與產品負責人通力協作來確定在一個Sprint中應該開發多少內容。

產品負責人不能這么說“我們還有4個Sprint,因此你們必須在這個Sprint中完成1/4的產品訂單”。產品負責人的工作是通過清晰、鼓舞人心的目標來激勵團隊。團隊成員最清楚他們自身的能力,因此在任何一個Sprint中,他們都會從產品訂單中選擇可以交付的用戶故事。

此外,產品負責人還會與團隊就如何管理需求變更這一問題達成一致:

Scrum團隊會承諾完成從產品訂單中所選擇的用戶故事,作為回報,產品負責人也會承諾不在Sprint中拋出新的需求。需求可以變更(變更也是受鼓勵的),但只能在Sprint之外變更。

Faisal Mahmood在博文should the product owner attend daily scrum, product owner and team engagement中討論了產品負責人該如何與敏捷團隊在會議中協作。Faisal解釋了產品負責人為何要參加Sprint計划、Sprint評審與回顧會議中:

產品負責人會向團隊描述產品訂單條目(用戶故事或是需求)。他與團隊一起工作,確保大家對產品訂單條目(或是用戶故事等)范圍的理解是一致的。產品負責人必須要參加Sprint計划會議,否則團隊可能會選擇低價值或是壓根就沒有價值的條目。這會導致浪費、混淆或是錯失機會的狀況發生。

Sprint評審是產品負責人接受或拒絕工作的最后機會。Scrum團隊(產品負責人、團隊與Scrum Master)與利益相關者會在Sprint評審中就產品方向、市場或是競爭狀況中的變化進行討論。該討論會產生更新的產品訂單。因此,我們說產品負責人必須得參與Sprint評審會議。

如果產品負責人不出席回顧會議,那么Scrum團隊就很難改進計划Sprint、管理與更新產品訂單、梳理產品訂單的方式;此外,團隊與產品負責人及利益相關者之間的交流方式,以及執行Sprint評審的方式也將變得難以改進。

Dean Leffingwell所創建的scaled agile framework可以在企業范圍內應用精益與敏捷實踐。它是這樣描述產品負責人角色的:

產品負責人是團隊中負責團隊訂單(即一般意義上的Scrum中的產品訂單)並確定其優先級的成員。此外,產品負責人在質量上也有着一個重要的角色,他是團隊中唯一一個有權向系統基線中“增加”新故事的人。對於向敏捷轉型的大多數企業來說,這是個全新、至關重要的角色,通常需要全職參與才行(一般來說是每1到2個敏捷團隊配有1個產品負責人)。

根據Dean所述,應用敏捷方法開發軟件的企業必須得對多個產品經理、產品負責人與團隊做出平衡:

從某種程度上來說,企業中成功的開發是一種數字游戲。如果沒有在正確的角色上使用正確的人數,那么瓶頸將會嚴重限制速率。因此,產品經理、產品負責人與敏捷團隊的數量必須要做到大致平衡,否則整個系統將會花費大量的時間在定義、澄清與接受上。

Marc L?ffler在其博文5 reasons why a product owner team might be a good idea中談到了產品負責人團隊的好處。其中一個原因就是每個敏捷開發團隊都應該有一個產品負責人:

曾經聽過讓Scrum Master來擔任產品負責人的角色,那他要是不在了呢?這就是瞎搞!但真的就有人這么做,而且不止一個。這就是產品負責人團隊存在的另一個原因。即便團隊中有一兩個成員不在(生病或是度假等) ,團隊也依然能夠繼續。

Marc提到的另一個原因是產品負責人的團隊協作可以改進訂單的質量:

我知道並沒有人規定只有產品負責人才能在訂單中創建新的條目,但很多團隊都覺得就該如此。產品負責人團隊會迫使大家在一起工作。當然了,他們還需要與開發團隊緊密協作,召開訂單梳理會議,甚至是讓開發者幫助維護訂單等。產品負責人團隊有助於培育團隊的協作精神。

查看英文原文:How do Product Owners and Teams Collaborate?


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com