《火星人開發紀實：敏捷開發一千零一夜》序言

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

 

本文是《火星人》系列的子系列，將分期向大家分享火星人敏捷開發管理工具的開發和管理實踐。

一直以來，敏捷開發長期受困於各種名詞、術語的堆疊、羅列、解釋，而較少出現原創和實踐分享過程。而敏捷實際上本來只把自己作為一個起點，需要大家的豐富和擴充。這可能與中國的軟體業發展長期落後於國際所致，以及在PMP、CMMI推廣中所養成的重標準、輕實踐的的情況有關。

本子系列會與大家分享我們自己的開發和管理實踐，它們可能不完美，也不是終極實踐（因為我們未來會做地更好），但卻是在時間、人員、市場、產品、團隊……眾多因素的限制下的真是實踐。

每一期中，除了實踐本身之外，我們都會盡量分享關於這個實踐我們的考慮過程、未來設想，以便協助大家思考和實踐出自己的敏捷開發來。

本文已經收錄於《敏捷開發案例集》，有志於提交和發表自己案例的讀者，可致信wanglijie9057@gmail.com，或申請加入QQ群：173709637。注意這是一個內部討論群，僅對潛在的案例提供者開放。

序言

這是一個真實的故事。

這是一個只會在世界上發生一次的故事。

所以，它揭示的是真理————————在現實世界中的一次閃現。

 

去年在業餘時間開始了一個產品研發項目，開始的時候一個人隔三差五地抽空開發，後來投入了比較常規的時間進行開發，最後又有一個兄弟加盟兩個人一起開發。

這個產品，就是“火星人”，一個敏捷開發管理工具。既然是敏捷開發管理工具，自然就應該按照敏捷開發的規矩辦事：使用者故事，反覆項目計劃，每日立會，自動化測試……一個都不能少，對不對？然而在開始了不久以後，我們發現問題沒有這麼簡單。

 

下面的故事，就是摘選了其中圍繞使用者故事相關的心得體會，以後還會有一些關於測試、重構、迭代規劃、團隊管理等方面的心得。

由於我們的前後人數變化、實際生產率、開發議程很特殊，下面的時間點做了一些加工，以利於可以像正常項目一樣理解。

 

免責聲明：本系列文章涉及的若干中間產品，本文作者也認為非常醜陋。但為了保持紀實性，仍然保留這些在實際產品中已經不複存在的曆史資料。請在其他正式火星人產品文章的指導下進行閱讀。