《火星人開發紀實：敏捷開發一千零一夜》第一個月：一個產品的誕生

（序言，之一，之二，之三，之四，之五）

 

第一個月：一個產品的誕生

 

沒有國王，沒有宰相，沒有能講故事的王后，也沒有需求文檔，開發就這樣開始了：

為何不先寫需求文檔？

因為敏捷開發不寫文檔！不是的。

策劃這個產品的時候，有一個大願：就是用這個產品管理這個產品自己的研發。雖然這不等於沒有“長得像”Word的文檔的需求，但是我們仍然想盡量只用產品本身的功能來寫需求。

所在在項目開始的那天，我們手裡（確切說是腦海裡）只有一個商業計劃，外加這個產品的大致功能列表。

那怎麼知道要開發什麼功能？

         至少在開始的時候，這個問題不很重要。

         因為敏捷工具已經存在了至少10年了，裡邊到底應該有什麼功能，在前輩們的網站上一搜，都能找到。但是，完成這些功能，乃至超越這些功能，都不是我們的目的。因為在軟體界，一個已經做了10年的市場，本應是一個沒有投資價值的市場。

除非，發現了全新的價值觀。

一個產品是怎樣誕生的？

限於商業機密，這裡就不把我們當時發現的新價值觀和商業策略寫下來了。下面泛泛地講一下一個產品誕生時應該發生的事情。

幾乎所有產品，在開發出來前，都有類似的產品存在。

幾乎所有產品，在開發出來後，都有類似的產品跟進。

幾乎所有新公司，都比之前的前輩小，不可能追上前輩。

幾乎所有老公司，都比之後的後輩大，很容易轉向踩死後輩。

若不想被前面的駱駝拖死，又不想被後面的大象踩死，就要走一條駱駝或大象都不會走的路。這種路很少很少，以至於很多人花費很多年才能發現一條，但是幸運的是它不但被我們找到了，似乎還已經裝好了路燈。

早期的開發，就是要證明這條新路可走，而不是把駱駝的路重新走一遍。所以在最一開始，我們並不需要一個完善的功能列表，而是要那個核心價值，以及一些能體現那個核心價值的功能即可。

這是新產品研發的核心原則。

那先開發什麼呢？

         我們當時的選擇，是“使用者故事顯示”功能。因為這是第一個我們會用到的功能。新增、編輯、刪除，則直接在資料庫裡邊做。由於選擇了ASP.net、MVC2.0（現在用3.0）、LINQ等一票先進技術，第一周，故事就安然地呈現在螢幕上了。第一個願望算是實現了。

又經過一個月的時間，增刪改查都做好了，而且還做了一個叢集編輯的介面，幾十個故事一羅列，特宏偉。

這似乎預示著未來將是一帆風順。