敏捷開發產品管理系列之二：產品版本規劃

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

本文是一篇舊文，原名爲《「迭代期內無變動」與敏捷開發產品版本規劃》，因符合本系列內容，作相應修改後從新編排發出。

迭代期間無變動？

支持派說：對，若是常常變，咱們怎麼開發啊。

反對派說：不對，敏捷開發不能上來就確認了需求，要的就是在開發中逐步瞭解需求，怎麼可能不變呢。

只在開發層面，這個問題無解。讓咱們站在產品版本規劃的高度來看這個問題。

基於商業目標的產品版本規劃

下個產品版本（或下個迭代）中到底應該有什麼功能？最重要的功能？最基礎的功能？當前可能實現的功能？已經弄清楚的功能？

這些角度都是基於技術活動而非市場目標來制定的，都有其侷限性。

其實，每一個產品的版本都是企業的一步棋：在某個時間，推出某些功能，知足某些需求，獲取某些客戶，戰勝某些對手，取代某些產品。

若認同了這一點，則早在產品版本規劃的時候，就應該確認此版本中應該大體包含哪些功能，而非到迭代計劃會議或迭代中才會確認，更不會在迭代中間發生變化。

這樣看來，「迭代期間無變動」指的是：「不該該到迭×××發已經開始了還沒明確要開發什麼功能」（What問題）；而不是：「應該在迭代前把需求弄明確，一旦開發了就別改動了」（How問題）。

產品版本規劃步驟圖

產品立項 ------------------------------------------- 在這個時候大體規劃出路線圖，走多遠，多久，走到哪裏

V1.0 --------------------------------------- 在這個時候明確規劃處這個版本要作哪些功能（未必到達故事點的粒度）

Sprint1計劃會 --------------------------------- 在這個時候達到故事點的粒度，且從技術角度思考能夠先作什麼後作什麼

平常工做 ----------------------------- 細化作成什麼樣子，隨時能夠變，但基本不會大量扔掉或換掉什麼功能了

Sprint2計劃會

……

Sprint Release ----------------------- 在這個時候，不管技術順序的前後，全部V1.0的功能都作完了

V2.0 --------------------------------------- 根據市場反饋，調整產品路線圖

V3.0 --------------------------------------- 繼續

 

從這一點上，敏捷產品版本規劃的目標與設定迭代目標的初衷相同：在「事先計劃防止返工」與「隨機應變防止想太多沒用上」之間找到平衡，下降浪費。