「迭代期內無變動」與敏捷開發產品版本規劃

迭代期間無變動？

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

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

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

 

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

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

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

若認同了這一點，則早在產品版本規劃的時候，就應該確認此版本中應該包含哪些功能，而非到迭代計劃會議或迭代中才會確認。這樣看來，「迭代期間無變動」指的是：「不該該到迭×××發已經開始了還沒明確要開發什麼功能」（What問題）；而不是：「應該在迭代前把需求弄明確，一旦開發了就別改動了」（How問題）。

 

總結一下：

 

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

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

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

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

Sprint2

……

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

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

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