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

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

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

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

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

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

n???????? 增加小版本信息，在軟件運行中就能夠看到大、小版本信息。

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

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

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

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

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

轉載于:https://www.cnblogs.com/Jackey_Chen/archive/2008/11/12/1331987.html

總結

以上是生活随笔為你收集整理的【推荐】极限编程的十二大原则——小版本的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。