關於軟件項目工做量估算的若干問題

軟件項目工做量估算從估算依據上看能夠分紅以下兩類：

1，基於規模估算

2，基於工做量估算

基於規模估算的狀況下，須要估算軟件項目的規模。本文首先來看規模方面的問題。

問題1：如何表達規模？

軟件產品或項目的功能規模是涉及軟件開發和交易的成本、項目資源投入的預測、項目維護成本的預算、項目質量管理的要求以及產品上市的時間等方面的關鍵指標。所以，進行軟件產品的功能規模測量顯得尤爲重要。

如何測量軟件規模這個問題自軟件工程誕生起就一直是這個領域的焦點問題。剛開始，人們很天然的使用代碼行數做爲規模的表達。可是做爲規模表達方式的代碼行數隨着時間和技術的發展，愈來愈不正確了，主要緣由是

1，新工具自動生成大量代碼行；

2複用構件或源代碼；

3，難以區分新開發代碼和舊代碼。並且最重要的是源代碼行數的實際測量只能在軟件項目開發的後期，缺少在前期較精確指導項目的能力。

世界上各個組織都看到了代碼行做爲規模表達方式的弊端，紛紛發展了各自的規模表達方式，其中IFPUG的功能點計數是其中有顯著影響的。可是因爲規模度量存在各類各樣的狀況，IFPUG的方法並無統治地位，涌現了多種規模度量方法。目前，國內外軟件領域的專家對軟件功能規模測量開展了極富成效的研究，提出了各種工業標準。國際標準化組織（ISO）和國際電工委員會（IEC）聯合技術委員會分別於199八、2002和2003年推出了軟件功能規模測量方面的系列標準。

國際標準化組織ISO/IEC相繼發表了4個功能規模測量方法的標準，它們是：

——ISO/IEC 19761（COSMIC-FFP方法）；

——ISO/IEC 20926（IFPUG方法）；

——ISO/IEC 20968（MkⅡ方法）；

——ISO/IEC 24750（NESMA方法）。

其中，COSMIC-FFP方法聲明能夠應用於管理信息系統（MIS）和實時類型二類軟件，IFPUG方法聲明可用於全部類型的軟件，MkⅡ方法聲明可用於邏輯事務能被肯定的任何軟件類型，NESMA方法很是相似於IFPUG方法也能夠用於全部軟件類型。

我國也十分重視這類標準的研究，於2001年開始了這方面的工做。

我國相繼發佈了GB/T 18491.1～6《信息技術 軟件測量 功能規模測量》的系列標準，但具體的測量方法不包含在該系列標準中。由中國工業和信息化部支持的《軟件工程 軟件功能規模測量方法 功能點計數》（徵求意見稿）於2011年9月1日完成，如今正處於意見徵集階段，這個標準非等效採用了ISO/IEC 20926:2003，爲全部類型的軟件開發的全生存週期提供了一種統一的軟件功能規模計數方法。

除了以上方法，常見的方法還有：

其它各種功能點方法

代碼行數 LOC

數據點

對象點

用例點

故事點，故事點是比較特殊的一個方法，下文還有說明。

很多公司發展了本身的功能規模測量方法。

問題2：如何測量規模？

以上這些規模測量方法的基本框架是相同的，下面是一個概要的介紹。

首先對作所測量對象進行分解，針對分解獲得的各個部分，估算或測量模塊的初始規模u（有些場合稱爲未調整功能點），乘以模塊級調節參數f1，獲得模塊一次調整後的規模，將全部一次調整後的規模累加獲得一次調整後的總規模，乘以整體調節係數f2，獲得二次調整後的總規模s，見以下公式：

總規模S = (西格瑪u*f1)*f2

有些方法只有一次調整，有些方法有上述的2次調整。

問題3：如何根據規模估算工做量

通過前人的大量研究，認爲規模與工做量的數學關係如如下公式所示：

估算工做量e = a * S的b次方 + c

s是表明了規模, a,b,c是參數，其值的得到須要大量數據分析，通常採用非線性轉換到線性，再進行線性迴歸分析。b的取值通常是1到1.2之間。

從以上公式能夠看出，隨着規模s的增長，工做量e是指數級增加，代表了軟件項目規模越大，所須要的工做量增長得更多，代表了軟件開發規模不經濟的狀況，這和咱們直觀的感覺是一致的。

世界上各個軟件生產率研究組織（好比ISBSG，SPR，日本的IPA SEC等）收集了成千上萬個項目數據，開展各類各樣的數學分析，試圖獲得在各類狀況下 a, b ,c 的取值。

在第5屆世界軟件質量大會上，來自Toyo University的野中誠（Makoto Nonaka）介紹了日本IPA SEC組織（http://sec.ipa.go.jp/），舉了某種狀況下的一個工做量估算公式：

工數 = e的0.542次方*FP的1.154次方 = 1.719*FP的1.154次方。

對於通常的場合，其規模在必定有限的範圍以內，那麼能夠假設工做量與規模的關係是簡單的線性正相關，那麼上述公式就變爲：

估算工做量e = a * S，即b=1, c=0 。 那麼參數 a 就是 代表了生產率，a的單位是 工做量/單位規模，好比8工時/FP；另一種生產率單位是規模/單位工做量，好比30FP/Man-month，若是採用常見的生產率單位，那麼a就是生產率的倒數。

這種作法是更容易爲各方所理解，在不少組織裏常見到這個作法。

對比基於規模的工做量估算，直接的工做量估算方法所積累的數據和資料就少了,沒有看到哪一個組織在收集積累這類數據，這與直接工做量估算方法自己的特徵也有關係。

下面來看看直接工做量估算方面的問題。

問題4，如何表達工做量？

工做量的單位通常是工時、人天、人月、人年。這些不一樣的單位是能夠換算的。不一樣單位換算並不麻煩，在同一個國家沒有差別，在不一樣國家由於法定假期的不一樣，1人月所對應的人天多是不一樣的，但差別並不大。真正麻煩的是工做量表達有以下兩種：

1，工做量

2，理想工做量

而工做量也有差別，有些地方是計毛時，好比一天都在某項目上工做，就直接記爲8工時，有些地方是計淨時，雖然一天都在某項目上工做，但會把諸如非直接相關的工做（如部門例會、參加其它項目評審）等等剝離，一天在某項目上的工做量只有5工時。 這樣看，能夠發現計淨時的工做量與理想工做量比較接近，但注意並不徹底相等。

問題5，如何直接估算工做量？

主要的思路是分解和類比。

把待完成物細分，根據以往估算和經驗進行類比估算。 對於以往估算和經驗的處理，能夠分爲兩種作法：

1，不作特別處理，天然停留在團隊成員的頭腦裏，使用時並不明確要求、不保證可以想起來對照

2，記錄典型事物（特性，用戶故事等）所須要的工做量，獲得一套基準類比庫，新任務根據這個基準類比庫來估算。

在使用理想工做量的狀況下，須要一個名爲capacity的參數。工做量 = 理想工做量 / capacity ，capacity的取值通常是50% ~ 80%。

在估算時，本次待完成的理想工做量 = 計劃的工做容量 * capacity

在回顧時，capacity = 原估算的理想工做量 / 實際工做容量 * 100%，注意工做容量並不等於工做量，而是團隊在指定時段內能夠提供的工做量，好比 5我的的團隊工做21天，那麼這個工做容量就是5*21=105人天。

在使用工做量時，注意區分毛時和淨時，在選擇淨時的狀況下，須要注意一天按多少小時來計，好比按5小時來計算，估算工做量達到50工時，若是1我的作的話，須要10天來完成。

問題6，在什麼狀況下使用直接工做量估算？

能夠看到雖然之前也存在直接工做量估算的作法，但並無獲得大力的宣揚，在之前的軟件工程教材裏，通常不多提直接工做量估算。

從敏捷類開發方法開始起，直接工做量估算獲得了宣揚，獲得了更普遍的傳播。

在敏捷類軟件迭代開發當中存在對此方法的很多應用。

問題7，Story Point的特殊狀況是什麼？

Story Point的起源與理想工做日緊密相關，通常的，在開始時，團隊會將估計一理想人日能完成的用戶故事爲一個故事點。

若是始終保持一理想人日對等於一個故事點，那麼故事點估算實際上是直接工做量估算。

但多數狀況下，1個故事點對應的工做量是會發生變化的，隨着團隊的變化，對1個故事點所須要的工做量通常會減小。

有些團隊會始終維護一套用戶故事樣例庫，至關於用戶故事的砝碼，新的用戶故事與樣例庫的用戶故事進行比對，進而斷定新用戶故事的故事點數。

在具體比對上，常見的方法有 排序法，排序法通常利用斐波那契數列（1，2，3，5，8，15, …，？，無窮大），還有模仿T-shirt size估算，常見的，分紅3到5檔，好比 S、M、L、XL，或大、中、小，給每一檔設定故事點數值。

能夠看到排序法和T-shirt size模仿估算在本質上是同樣的，T-shirt size模仿估算是排序法的一個實現。

這有樣例庫的作法獲得的估算點數就是規模，值得注意的是 故事點所表達的規模是相對的規模。不一樣組織、不一樣團隊的故事點是不能夠比較的。這與諸如IFPUG、NESMA等等的功能點是不同的。

4個國際軟件功能規模測量標準的功能點是像「米」同樣的絕對單位。就是說 在中國A公司的A1軟件用IFPUG識別出了1000個功能點，美國B公司的B1軟件也用IFPUG識別出的1000個功能點，那麼能夠說A1軟件的規模與B1軟件規模相等。而若是中國A公司的A2軟件用Story Point識別出了1000個故事點，美國B公司的B2軟件也用Story Point識別出了1000個故事點，那麼，是不能說A2軟件的規模與B2軟件規模相等，兩種不具有可比性，若是非要比較，那麼須要分析A2和B2各自所依據的故事點樣例或基準。

前面說到新的用戶故事與樣例庫的用戶故事進行比對，進而斷定新用戶故事的故事點數，目前這個比對並無絕對的作法，常見不一樣的作法有：
1，是否考慮不一樣人作的影響

2，是否考慮實現的複雜度、難度

3，是否考慮新用戶故事關聯或依賴的事務

4，是否考慮有疑問的部分

目前業界對以上的問題並無定論，各家組織或團隊結合各自狀況和理解各有各的選擇。

所以，Story point具有在規模和直接工做量的兩種形態之間變化的多態，具有巨大的靈活性，具體組織在採用Story Point時，能夠作適應性的選擇。

問題8，哪一種方法更加準確？

沒有結合具體狀況，這個問題是沒法回答的。

假設偏差係數= 估算值/實際值。

估算值 = 實際值 * 偏差係數

絕對偏差 = 實際值-估算值 = 實際值 - 實際值 * 偏差係數 = 實際值*（1-偏差係數）

能夠看到的一點是 敏捷小團隊短迭代的實際值是不大的。 假設9我的的團隊，迭代週期是3周，那麼 實際值約在135人天範圍以內。就算偏差係數比較大，絕對偏差也是有限的。

而傳統瀑布型項目就是另一個樣子，好比時間跨度也許達到1年，總的人月數約是120人月，在這種狀況下，就不難理解爲何存在多個組織來維護功能點定義，收集數據，給出須要指數運算的估算公式。由於就算偏差係數小，因爲基數大，所形成的絕對偏差就比較大。

在敏捷開發方法裏，常見的，採用撲克估算方式，這個方法能夠驅動總體團隊的智慧來肯定故事點的大小，也能提升估算的精確度，並且也能澄清不一樣的理解，是很是值得采納的一個方法。

 

做者：irenbest 來源：希賽網 發佈於 2016-4-20