軟體專案的返工問題

軟體專案的返工問題

軟體行業普遍利潤率低，軟體專案的成本超支司空見慣，到底成本到哪兒去了？

軟體工程師天天加班加點，說到底還是返工問題。軟體專案的返工成本幾乎達到

專案成本的一半以上。到底什麼算返工，目前業界好像還沒有確切的定義，我總結

了一下，一下情況應該算是返工：

返工的定義可以理解為應該並有能力做到返工後的水平的卻因為各種主觀因素

卻沒有一次性達到，只能用返工甚至多次返工的方法來達到目前的要求。

1. 隱含需求的變更；

2. 由潛在的需求引起的變更；

3. 架構選型不當引起的移植、變更；

4. 需求或設計的理解錯誤造成的變更；

5. 在專案範圍、技術平台、技術路線決策失誤造成的變更；

6. 設計的抽象不夠，造成的開發過程中的浪費、合併、再抽象等工作；

7. 評審遺漏缺陷造成的變更；

8. 測試遺漏造成的反覆修復工作量。

其實對比其他行業，軟體行業似乎是返工最大的了，很少聽說哪個大樓把地基扒

了三次再蓋的，但是很多軟體專案確實不止一次的扒掉重來。甚至很少聽說哪個專案

是一直一步一步往前走的，都是來來回回、反反覆覆完成的。

第一版確認的需求vs最後交付的系統之間的變動分析：

變動內容和原因

變動的可能性（非互斥關係）

對工作量的影響（進度、成本），但是在質量上是改進的

介面元素、介面風格、介面的易用性、前台的業務邏輯

80%＋

較小

設計上的變更、後台業務處理邏輯、資料庫的變更、易用性設計的變化

50%～60%＋

較大

返工的需求、區域性返工或推倒重來

20%＋

大

增加的需求、範圍的擴大

20%～30%＋

大

上表是根據以前專案的經驗得到的關於軟體在開發過程中的變化情況的總結，大部分都是應用型別的專案。

分析造成這種情況的原因：

1.是客戶不成熟，拼命要求進度；導致專案趕進度，前面工作做的不到位，返工是必然的；

2.專案中做需求和設計的人員的能力和經驗，經驗的欠缺往往導致後期才發現隱含的需求和設計的不到位；

3.專案管理經驗如果不成熟，乙個重要的表現就是進度狂。要減少返工就要做到胸有成竹、處亂不驚、從容應對。按照計畫行事是很重要的，專案過程中突發事情和壓力是很多的，做到專案組內部陣腳不亂是非常重要的。

軟體專案的返工問題

軟體專案的返工問題 軟體行業普遍利潤率低，軟體專案的成本超支司空見慣，到底成本到哪兒去了？軟體工程師天天加班加點，說到底還是返工問題。軟體專案的返工成本幾乎達到 專案成本的一半以上。到底什麼算返工，目前業界好像還沒有確切的定義，我總結 了一下，一下情況應該算是返工 返工的定義可以理解為應該並有能力做...

軟體專案的核心風險

風險在所有的專案中都是存在的，在這些風險中有些是專案失敗的罪魁禍首，下面列舉五種最常見的，對專案的成敗有著巨大影響的風險。1.從一開始進度的安排就是錯誤的。人們總是傾向於樂觀的估計，常常無視那些 可能需要作 的工作，儘管你可能對專案規模作了認真的估算，但是估算的結果仍可能太小，這也就直接導致進度的安...

敏捷專案的軟體測試

我們的專案實行敏捷已經近兩年了，關於敏捷我相信大家已經比較熟悉了，我今天就先談談在敏捷的專案裡如何實行測試的工作。敏捷的專案對測試的影響 敏捷專案的正確測試觀念 敏捷測試的管理 敏捷測試的執行 我們的專案之前的測試開發比例是1比5，質量基本達到客戶的要求，為什麼1比5可以，因為我說過，開發人員是可以...