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

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

本文是一篇舊文，原名為《“迭代期內無變更”與敏捷開發產品版本規劃》，因符合本系列內容，做相應修改後重新編排發出。

迭代期間無變更？

支援派說：對，如果經常變，我們怎麼開發啊。

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

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

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

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

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

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

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

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

 產品版本規劃步驟圖

 產品立項 ------------------------------------------- 在這個時候大致規划出路線圖，走多遠，多久，走到哪裡

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

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

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

        Sprint2計劃會

        ……

        Sprint Release ----------------------- 在這個時候，無論技術順序的先後，所有V1.0的功能都做完了

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

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

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

 

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》