【推薦】極限編程的十二大原則——小版本

小版本：用最少的代碼工作量帶來最大的業務價值。

這個原則是意思是為了高度迭代，與客戶展現開發的進展，小版本發布是一個可交流的好辦法，客戶可以針對性提出反饋。但小版本把模組縮得很小，會影響軟體的整體思路連貫，所以小版本也需要總體合理的規劃。

這麼一說，感覺這一原則對我們公司的產品是沒有什麼適用性的，我們不可能讓電訊廠商承受這樣的高度迭代過程。然而，正如我一開始就提到的，我們學習敏捷開發、極限編程的目的不是為瞭解決所有的問題，而是開拓思路，防止我們的思維僵化。據我的觀察，我們的測試部開發的自動化測試、調試軟體就非常適合利用這個原則。客戶是誰呢？就是負責生產調試的內部客戶。

自動化測試、調試軟體有個很大的特點就是：變化快，而對於這個特點，正是敏捷開發理論所特長解決的。目前對於這類軟體的管理的強度遠遠要弱於那些產品軟體，一方面是因為這些軟體因為在使用過程中需求變化太快，如果按照公司的規範輸出各類文檔，並且按照常規流程管理的話，無法做出及時地響應，會影響工作。另外一方面，就是開發人員的主觀因素，常常這類軟體都是開發人員在生產線與負責生產調試的人員即時溝通即時修改的，這樣的習慣也就導致了習慣成自然，我們的“客戶”養成了習慣，開發人員也被迫養成了習慣：開始的時候開發人員往往想反正軟體改起來也要比硬體來的容易，那就改吧，一來二往，突然有一天發現自己突然陷入了一個泥潭。

作為技術部的組態管理，我就多次發現這些自動化的測試、調試軟體版本混亂的情況，而且從使用這些軟體的人員反饋回來的聲音中，我們也可以聽到對於軟體品質方面的抱怨。這就是我說到的“泥潭”：作為開發人員，自己每天疲於修改，卻無法得到“客戶”的認同，這是一件多麼讓人鬱悶的事情啊！

那麼我們是不是可以考慮利用敏捷開發的方法來解決這些問題呢？或者，通過一種思維上的啟發來“創造”一個適合我們實際情況的方法來解決這些問題呢？我想到了一些改善的方法：

n         增加小版本資訊，在軟體運行中就能夠看到大、小版本資訊。

n         增加線上更新功能，這樣無論身在公司何處，只要能夠連入內部網路，就可以及時、準確地更新程式。

n         增加版本檢驗功能，根據需要檢測版本是否需要更新，以此來保證當需要時，保證所有的用戶端都運行在一個基準之上。

n         增加錯誤反饋、日誌功能，保證當錯誤發生時能夠通過郵件將必要的資訊反饋給開發人員。這樣可以防止在問題反饋時問題無法複現或者反饋人說不清楚的情況。

這些方法其實都是我們在很多軟體中能夠看到的功能，並不是什麼新奇的技術，實現起來也很容易，而且我們可以將這些功能作為一個公用模組來保證不同的自動化測試、調試軟體不用重複開發。這些功能的實現將會讓你體會到更多的方便。

有了這些基礎，我們就可以在軟體開發的過程中將高迭代過程變得更容易控制、實施起來的效率也會更高，效率提高了，時間節省了，才能有條件去思考、去改進。就如同我們的胳膊自由了，呼吸順暢了，才有可能將自己從泥潭中解救出來一樣。