敏捷開發產品管理系列之一：序言及設立迭代目標

本文是敏捷開發產品管理系列的第一篇。（序言及設立迭代目標，產品版本規劃，產品用戶羣規劃，新產品研發，預估會議，Product Servant，Product Owner團隊，產品線管理）

序言

以前的「敏捷開發用戶故事系列」已經提到了微觀層面的需求管理問題。因爲敏捷開發的提出者和實踐者主要是開發團隊及其領導，所以通常較少說起產品的總體規劃、商業目標這些內容。

本系列聚集了本人在作產品管理的時候的一些心得，以及在與不一樣企業交流、作互聯網軟件分析的時候的一些所得，與你們分享。

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

爲什麼設立迭代目標

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

基於版本規劃的迭代目標

一次是關於「迭代期內無變動」，即因爲產品應該預先設定商業目標和客戶羣，所以總體版本規劃也應預先設定，進而能夠分解出相對穩定的迭代目標。

若能完成上述工做，則迭代期內儘管有微弱的變動，但迭代的總目標不會發生大的變化，從而保證迭代期內總體開發內容的穩定。

基於故事羣的迭代目標

第二次則是提到用戶故事的組織時，引入了「故事羣」的概念，即某個迭代不該該簡單地開發「當前最重要的功能」，由於萬一這些最重要的功能零散地分佈在不一樣的業務模塊中，開發者就要同時面臨同步瞭解多個業務模塊的困境，前來評審的客戶也會有如瞎子摸象通常只能看到多個局部的一角。

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

上述兩種方法，一種基於外部的商業目標，一種基於內部的開發方便性，但都指向相同的結果。

怎樣設立迭代目標

會前準備

迭代目標是提早設立的，早於計劃會，甚至早於Product Owner將有開發意向的Backlog條目計劃到迭代中。它實際上在作產品版本規劃的時候，就應該捎帶着被完成了。

它經常是一句簡單的描述，如「一個能登錄和顯示故事列表的版本」。

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

事實上，若已經設定了多個迭代的目標，Product Owner應該會同開發團隊骨幹，爲將來2～3個迭代大體分配所需的用戶故事，而不是趕在當前迭代前才匆匆分配。這個活動有利於開發團隊骨幹提早了解將來，從而在架構上作一些準備。

長期存在的一個難以平衡的問題是：若在架構上作了過多的準備，若中間發生變動乃至放棄某些功能，這些準備會浪費；若架構上準備不足，不斷迎來新功能又會致使過多的「重構」發生，也會形成浪費。爲多個迭代設立目標能夠有效地幫助開發團隊作出切合實際的架構準備，將浪費下降到最低點。

會後覈對

在計劃會上講解故事、估算故過後，事情經常有所變更。

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

開發中跟蹤

在平常開發中Product　Owner經常提出變動，若變動符合目標甚至能更好地達成目標，則應該被積極地接納；若背離了目標，則應該緩作或從新考慮。

若「被激勵」的程序員有了奇思妙想的時候，團隊一樣應該冷靜地思考，作出判斷。

 

「擁抱變化」與「迭代期內無變動」的矛盾其實向咱們揭示了敏捷開發中的一個重要原則：變化的是路徑，不變的是目標。

爲每一個迭代設立目標，很是好地讓咱們可以遵循這一點。