本文是敏捷開發產品管理系列的第一篇。（序言及設立迭代目標，產品版本規劃，產品用戶群規劃，新產品研發，Product Owner團隊，產品線管理）
序言
之前的“敏捷開發用戶故事系列”已經提到了微觀層面的需求管理問題。由於敏捷開發的提出者和實踐者主要是開發團隊及其領導，因此一般較少提及產品的整體規劃、商業目標這些內容。
本系列匯集了本人在做產品管理的時候的一些心得，以及在與不同企業交流、做互聯網軟件分析的時候的一些所得，與大家分享。
本系列的順序整體由微觀到宏觀排序，擬包括設立迭代目標，產品版本規劃，新產品研發，Product Owner團隊，產品線管理等話題。
為何設立迭代目標
之前筆者的博客中曾經兩次提到關於迭代目標設立的話題。
基於版本規劃的迭代目標
一次是關於“迭代期內無變更”，即由於產品應該預先設定商業目標和客戶群，因此整體版本規劃也應預先設定，進而可以分解出相對穩定的迭代目標。
若能完成上述工作，則迭代期內盡管有微弱的變更，但迭代的總目標不會發生大的變化，從而保證迭代期內整體開發內容的穩定。
基於故事群的迭代目標
第二次則是提到用戶故事的組織時，引入了“故事群”的概念，即某個迭代不應該簡單地開發“當前最重要的功能”，因為萬一這些最重要的功能零散地分布在不同的業務模塊中，開發者就要同時面臨同步了解多個業務模塊的困境，前來評審的客戶也會有如瞎子摸象一般只能看到多個局部的一角。
相對容易開發的方式，是在一個迭代中，應該安排相關的一組故事，從而將開發和評審的焦點都集中在一起。這樣開發出來的產品也不完整，但卻相對完整地交付了一部分功能，比之零散功能還是更有價值。
上述兩種方法，一種基於外部的商業目標，一種基於內部的開發方便性，但都指向相同的結果。
怎樣設立迭代目標
會前准備
迭代目標是提前設立的，早於計劃會，甚至早於Product Owner將有開發意向的Backlog條目計劃到迭代中。它實際上在做產品版本規劃的時候，就應該捎帶著被完成了。
它常常是一句簡單的描述，如“一個能登陸和顯示故事列表的版本”。
在迭代計劃會之前，Product Owner會審視這個迭代的目標，從而決定將哪些故事置於本迭代中開發。
事實上，若已經設定了多個迭代的目標，Product Owner應該會同開發團隊骨干，為未來2～3個迭代大致分配所需的用戶故事，而不是趕在當前迭代前才匆匆分配。這個活動有利於開發團隊骨干提前了解未來，從而在架構上做一些准備。
長期存在的一個難以平衡的問題是：若在架構上做了過多的准備，若中間發生變更乃至放棄某些功能，這些准備會浪費；若架構上准備不足，不斷迎來新功能又會導致過多的“重構”發生，也會造成浪費。為多個迭代設立目標可以有效地幫助開發團隊做出切合實際的架構准備，將浪費降低到最低點。
會後核對
在計劃會上講解故事、估算故事後，事情常常有所變動。
這時候要從已經計劃要開發的故事總結一下看看，是否與原來設定的目標相符。
開發中跟蹤
在日常開發中Product Owner常常提出變更，若變更符合目標甚至能更好地達成目標，則應該被積極地接納；若背離了目標，則應該緩做或重新考慮。
若“被激勵”的程序員有了奇思妙想的時候，團隊同樣應該冷靜地思考，做出判斷。
“擁抱變化”與“迭代期內無變更”的矛盾其實向我們揭示了敏捷開發中的一個重要原則：變化的是路徑，不變的是目標。
為每個迭代設立目標，非常好地讓我們能夠遵循這一點。
文章來源：blog.csdn.net/cheny_com/article/details/6912278