1 軟件開發(fā)度量

      在多數(shù)行業(yè)中，決策基于數(shù)據(jù)而產(chǎn)生。重要的 KPI 一般是隨時間測量的，數(shù) 據(jù)表示某種事件或模式，該事件或模式是某個操作的觸發(fā)因素。舉一個簡單的例 子:工廠中一條重要裝配線的吞吐量(即每分鐘裝配的產(chǎn)品數(shù)量)。當吞吐量低 于某個閾值時，說明出現(xiàn)了問題。因此，維修人員將確定問題并進行維修。

      在軟件行業(yè)中，人們經(jīng)常提到“軟件工廠”。這些團隊專注于軟件開發(fā)，為 客戶提供相應價值。例如:移動應用程序中的新功能、網(wǎng)站上的新功能或 ERP 系 統(tǒng)的更改。
那么如何衡量開發(fā)團隊的產(chǎn)出呢?為了解決這個問題，制定了功能規(guī)模度量 的 ISO 標準。目前有 5 種方法(按字母順序排列)。

    •    COSMIC-FFP (ISO/IEC 19761)
    •    FiSMA (ISO/IEC 29881)
    •    IFPUG (ISO/IEC 20926)
    •    Nesma (ISO/IEC 24570)
    •    UKSMA-Mark II (ISO/IEC 20968)

      在這些方法中，IFPUG、Nesma 和 COSMIC 是最常用的方法。這些方法不 考慮技術層面或非功能需求，而是通過量化軟件的功能點來度量軟件的功能規(guī)模。正如 100 平方米的磚墻具有與 100 平方米玻璃墻具有相同的表面積一樣，用 Java編寫的 1000 個功能點的軟件系統(tǒng)與用 Cobol 開發(fā)的 1000 個功能點的應用程序 提供的功能數(shù)量相同。

      功能點分析師對一組功能用戶需求(例如用戶故事、用例、功能設計等)進 行分析，并確定這些需求的功能規(guī)模，還可以確定在特定時間段(一個 sprint 或 一個版本)內添加、修改或刪除的功能規(guī)模。這是由 Nesma 開發(fā)的，也是其標準 的一部分。Nesma 將其稱為“項目規(guī)模”，度量單位為“增強功能點(EFP)”。因此，有兩種功能規(guī)模:
    •    應用程序規(guī)模:應用程序在某一時刻的功能規(guī)模。例如，應用程序 X 當 前為 1000 FP。
    •    項目規(guī)模:在一定時間內添加、修改或刪除的功能規(guī)模。比如，在 SprintY 中，添加了 25 個 FP，修改了 15 個，刪除了 5 個。項目規(guī)模為 25+15+5=45個增強功能點(EFP)。

2 團隊績效指標

      通過測試每個Sprint或者每個版本的EFP 數(shù)量，可以比較不同團隊的生產(chǎn)率 差異。例如，當獲取到所花費的工時、這些工時的成本以及發(fā)現(xiàn)的缺陷數(shù)量等數(shù) 據(jù)時，就可以確定以下指標:
    •    項目交付率:每個 EFP 花費的工時;
    •    成本效率:每個 EFP 花費的工時成本;
    •    程序質量:每 1000 EFP 中的缺陷;
    •    交付速度:每月 EFP。

      對每個團隊的上述指標進行監(jiān)控，就可以知曉團隊情況。當開發(fā)的 EFP 較少時，則可能存在問題。功能點是產(chǎn)生價值的代表，團隊開發(fā)的功能越多，用戶 使用該功能的機會就越多。通過上述指標可以進行團隊之間的對比，管理層可以了解到效率更高，更具 價值的團隊。
      人們通常用生產(chǎn)率進行比較，因為它獨立于費率或內部成本。在 ISBSG 術 語中，經(jīng)常使用生產(chǎn)率，而不使用正確的術語—項目交付率(PDR)。對于大多數(shù) 人來說，很難處理有很多小數(shù)的數(shù)字，而在計算每小時的功能點時得到的結果就 是這樣的數(shù)字，因此將這個計算結果反轉為每個功能點的小時數(shù)，稱為 PDR。即PDR 是每個功能點花費的工時。圖 1 為不同團隊之間的 PDR 對比。
      例如，團隊 A 是一個 8 人的 Java 團隊，而團隊 C 是一個 5 人的 Cobol 團隊。團隊的生產(chǎn)率很大程度上取決于技術環(huán)境。因此，將每個團隊的生產(chǎn)率與行業(yè)的 市場平均水平進行比較是有意義的。