版本發佈失敗，緣由爲什麼？

1.   缺乏「產品」的概念

開發人員或者產品相關人員，缺乏從「產品」的角度考慮問題。經常表現爲如下幾種狀況：

1、產品版本功能規劃不合理

舉例：首個測試版本，僅有登陸，沒有退出。這種狀況登陸後要想退出從新登陸，只能卸載軟件，從新安裝才能夠，試想，誰會去重複安裝n次來測試登陸呢？暫且假設有人這麼作了，每次都是卸載後從新安裝進行的登陸，測試結果可靠不？可想而知，顯然，第二個版本的時候問題暴露出來了，雖然有退出功能了，只能登陸一次，退出後就不能再登陸了。

 

從產品的角度來看，產品應該是這樣的，登陸-功能模塊操做-退出。確保這一整個流程都是通的。若是時間來不及，中間的功能模塊能夠減小。這就是所說的「作產品作一半」。

 

2、產品基礎功能不能用

開發不進行簡單的流程性測試就拋過來給測試，結果常常是主要功能都不可用。結果只能打回去，從新打包。

 

3、程序數據寫死，爲開發自測用數據

程序中的數據不是根據具體用戶動態獲取的，而是開發寫程序時寫死的測試用數據。

舉例：登陸，登陸賬號是寫死的，無論用哪一個賬號登陸，都是寫死的賬號，這樣與用戶相關的信息沒法真實體現，好比學識獲取，課程學習狀況，這個使得本應該在前期版本中就應該發現的問題到後期版本中才暴露。

 

2.   開發對需求理解不夠透徹

明明有需求原型，可是就不按照需求原型來，或者是部分按需求原型來，部分不按照需求原型來，結果就是開發出來的產品經常是不符需求。要知道，畢竟工做性質不一樣，人家產品也不是吃素的。

 

3.   代碼管理混亂

缺乏對代碼進行管理，經常表如今如下幾個方面:

1、原來已經修復的問題再後面版本中又重現出來

2、每次提交測試的版本都不穩定，每一個功能模塊都出問題

簡而言之就是：代碼的修改沒有很好的控制，過程比較隨意，經常是大動手腳，結果到最後沒有一個版本是相對穩定，可用的版本

 

4.   開發和測試缺少互動

開發提交版本測試的時候，沒有提交changlog或者提交的changlog不 明確。這樣，若是系統比較複雜，測試人員除缺陷管理系統上提交的缺陷是否被處理外，不懂其它模塊是否有作修改，哪些地方沒作修改，測試人力不足的狀況下， 時間短的狀況下測試也就比較沒有針對性，天然也就比較容易產生漏測。因此建議要增強這種文檔反饋機制，固然口頭交流能作到也行。

 

5.   時間太趕

測試在趕，開發在趕，反正就是很趕，一趕就出問題，經常看到bug被標記已解決，可是新版本測試中發現bug原封不動的存在，，，，，，因此，項目負責人應該學會談判和計劃，儘可能爲項目爭取時間。

 

6.   不夠重視

對提出的問題不夠重視，結果就早期提出的問題在日後延幾個版本才被處理

 

7.   考覈機制不合理

考覈這東西有利有弊，好處在有考覈有壓力、有責任感、有處罰，壞處就是爲了經過考覈，逃避處罰，能夠不擇手段，應付了事等