本文是敏捷開發(fā)產品管理系列的第一篇。（序言及設立迭代目標，產品版本規(guī)劃，產品用戶群規(guī)劃，新產品研發(fā)，Product Owner團隊，產品線管理）

序言

之前的“敏捷開發(fā)用戶故事系列”已經提到了微觀層面的需求管理問題。由于敏捷開發(fā)的提出者和實踐者主要是開發(fā)團隊及其領導，因此一般較少提及產品的整體規(guī)劃、商業(yè)目標這些內容。

本系列匯集了本人在做產品管理的時候的一些心得，以及在與不同企業(yè)交流、做互聯(lián)網(wǎng)軟件分析的時候的一些所得，與大家分享。

本系列的順序整體由微觀到宏觀排序，擬包括設立迭代目標，產品版本規(guī)劃，新產品研發(fā)，Product Owner團隊，產品線管理等話題。

為何設立迭代目標

之前筆者的博客中曾經兩次提到關于迭代目標設立的話題。

基于版本規(guī)劃的迭代目標

一次是關于“迭代期內無變更”，即由于產品應該預先設定商業(yè)目標和客戶群，因此整體版本規(guī)劃也應預先設定，進而可以分解出相對穩(wěn)定的迭代目標。

若能完成上述工作，則迭代期內盡管有微弱的變更，但迭代的總目標不會發(fā)生大的變化，從而保證迭代期內整體開發(fā)內容的穩(wěn)定。

基于故事群的迭代目標

第二次則是提到用戶故事的組織時，引入了“故事群”的概念，即某個迭代不應該簡單地開發(fā)“當前最重要的功能”，因為萬一這些最重要的功能零散地分布在不同的業(yè)務模塊中，開發(fā)者就要同時面臨同步了解多個業(yè)務模塊的困境，前來評審的客戶也會有如瞎子摸象一般只能看到多個局部的一角。

相對容易開發(fā)的方式，是在一個迭代中，應該安排相關的一組故事，從而將開發(fā)和評審的焦點都集中在一起。這樣開發(fā)出來的產品也不完整，但卻相對完整地交付了一部分功能，比之零散功能還是更有價值。

上述兩種方法，一種基于外部的商業(yè)目標，一種基于內部的開發(fā)方便性，但都指向相同的結果。

怎樣設立迭代目標

會前準備

迭代目標是提前設立的，早于計劃會，甚至早于Product Owner將有開發(fā)意向的Backlog條目計劃到迭代中。它實際上在做產品版本規(guī)劃的時候，就應該捎帶著被完成了。

它常常是一句簡單的描述，如“一個能登陸和顯示故事列表的版本”。

在迭代計劃會之前，Product Owner會審視這個迭代的目標，從而決定將哪些故事置于本迭代中開發(fā)。

事實上，若已經設定了多個迭代的目標，Product Owner應該會同開發(fā)團隊骨干，為未來2～3個迭代大致分配所需的用戶故事，而不是趕在當前迭代前才匆匆分配。這個活動有利于開發(fā)團隊骨干提前了解未來，從而在架構上做一些準備。

長期存在的一個難以平衡的問題是：若在架構上做了過多的準備，若中間發(fā)生變更乃至放棄某些功能，這些準備會浪費；若架構上準備不足，不斷迎來新功能又會導致過多的“重構”發(fā)生，也會造成浪費。為多個迭代設立目標可以有效地幫助開發(fā)團隊做出切合實際的架構準備，將浪費降低到最低點。

會后核對

在計劃會上講解故事、估算故事后，事情常常有所變動。

這時候要從已經計劃要開發(fā)的故事總結一下看看，是否與原來設定的目標相符。

開發(fā)中跟蹤

在日常開發(fā)中Product　Owner常常提出變更，若變更符合目標甚至能更好地達成目標，則應該被積極地接納；若背離了目標，則應該緩做或重新考慮。

若“被激勵”的程序員有了奇思妙想的時候，團隊同樣應該冷靜地思考，做出判斷。

“擁抱變化”與“迭代期內無變更”的矛盾其實向我們揭示了敏捷開發(fā)中的一個重要原則：變化的是路徑，不變的是目標。

為每個迭代設立目標，非常好地讓我們能夠遵循這一點。

文章來源：blog.csdn.net/cheny_com/article/details/6912278

標簽： 敏捷 ��

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。