敏捷開發中產品負責人與團隊如何協作

1.Story的確定

    在敏捷開發團隊中，產品負責人需要將用戶故事放在隊列中。這個隊列叫做產品訂單，由產品負責人負責。

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

2。一個Sprint中完成的Story的確定

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

    因為資源的限制，有些問題我們一直需要討論——Story的價值、大小、優先級、劃分——所有這些通常叫做“訂單梳理”。產品負責人要根據情況梳理訂單，并不定期召開訂單梳理會，理論上整個團隊都會參加，有時一些利益相關者，橫向經理人員，決策者也會參加。會議議程會不斷變化，有時關注點放在估算上，有時放在故事的劃分上，有時還會為討論驗收標準。  

    產品負責人知道應該構建什么，并向Scrum團隊表明這一點。團隊會與產品負責人通力協作來確定在一個Sprint中應該開發多少內容。

    對于軟件產品的開發來說，每個Scrum角色都會有自己的關注點：

    各個Scrum角色之間應該保持健康的關系。產品負責人應該關注本次迭代應該完成哪些正確的東西。而團隊關注如何快速和正確地構建這些東西。Scrum Master關注效率，包括進度和溝通，并且最大程度上維護敏捷的基本制度。

    開發團隊除了能按時完成任務外，還要保證開發可持續性。意思是，如果團隊積累了所謂的技術債務（比如框架不合理，沒有編寫測試，沒有可持續改進的架構設計），那么團隊的開發速度將會隨著時間的推移變得越來越慢，這使得后面的預測變得幾乎不可能。因此，考慮到團隊要負責保持可持續的節奏，產品負責人要注意，不應該對其施加壓力導致其走捷徑，這種現象經常存在，尤其是團隊開發者缺乏強大開發經驗的時候。所以信任和鼓勵是非常重要的。產品負責人應該唾沫橫飛，意氣風發，手舞足蹈地，像一個專業的騙子一樣向團隊灌輸他的產品Story，讓團隊像打了雞血一樣自愿去戰斗，而不是唉聲嘆氣，歇斯底里地傳送壓力。

    產品負責人應該避免這么說“我們還有剩下4個Sprint，因此你們必須在這個Sprint中完成1/4的產品訂單，否則后面會。。。”。產品負責人的工作是通過清晰、鼓舞人心的目標來激勵團隊。團隊成員最清楚他們自身的開發能力，因此在任何一個迭代中，他們都會從產品訂單中選擇可以交付的用戶故事，產品經理盡量避免討論這個工作，如果真的有需要，可以借助于 Scrum Master。

3。產品負責人在敏捷組間的協調

    大型項目會有多個團隊同時工作，當然也會擁有一個以上的產品負責人。所以產品負責人本身之間的協作是非常必要的。

    在多團隊的情況下，產品負責人還有一個額外的重要職責——團隊之間彼此交流！沒錯，我們當然應該讓團隊之間的Story只有最小化的依賴或者沒有依賴。但事實上總還是會有一些依賴，無論是產品邏輯還是技術實現方面！因此，產品負責人之間應該進行某種同步，這樣才能按照順序構建，避免局部優化而影響整體效率。

    產品負責人是一個至關重要的角色，通常需要全職參與才行，一個產品負責人可以兼任一個或者兩個敏捷團隊，但不能夠兩個或者以上的產品負責人在一個敏捷團隊里面。     

4。需求變更

    關于需求變更，產品負責人還會與團隊就如何管理需求變更這一問題達成一致。

    作為理論而言，Scrum團隊會承諾完成從產品訂單中所選擇的用戶故事，作為對等要求，產品負責人要承諾不在Sprint中拋出新的需求。

    需求可以變更（需求變更是Scrum存在的目的，也是受鼓勵的），但只能在Sprint之外變更。

    然而，只要有實際敏捷開發工作經驗的產品負責人都會覺得，這有時候的確是個難題，尤其是面對業務方的時候。有一個比較好的方法可以大部分解決這個尷尬的問題，在一開始組建團隊和設立迭代周期的時候，不要把迭代周期設定的太長。產品經理可以了解業務方的規律，建議敏捷團隊設定一個比較斷而合理的迭代周期，比如二周，甚至一周。