開發leader們最該了解的軟體度量名額

什麼是軟體度量名額？為什麼它們很重要？

管理者的工作是為公司創造價值，在軟體領域，開發負責人負責建構和改進産品、管理時間和滿足預算。這些職責都依賴于評估團隊或項目的目前狀态、衡量進度以及估計達到下一個裡程碑所需時間和資源的能力。

開發負責人依賴軟體度量名額來保證品質，并幫助加強團隊成員之間的協作。有效的軟體度量名額與主動管理相輔相成，幫助開發負責人滿足釋出日期并控制開支。軟體度量名額有助于識别目前版本和預發行版本中的問題，可用于相應地跟蹤問題并确定其優先級。重要的是，正确的軟體度量名額為更準确的預測鋪平了道路，并有助于考慮在開發生命周期期間所做決策的影響。

軟體度量名額如何缺乏？

軟體度量名額比較棘手，因為衡量軟體品質不僅具有多方面性和主觀性，而且重要的東西可能會因項目而異。一個團隊或組織中的優先級和最重要的事情對于另一個團隊或組織而言會有所不同，這意味着沒有一種通用的軟體度量名額。

如何在正确的時間選擇正确的軟體度量名額？

軟體度量名額五花八門，數量衆多，是以選擇正确的度量名額取決于您需要跟蹤的确切内容。一個常見問題是，度量名額并不總是與項目目标相關聯。例如，如果記憶體優化很重要，那麼減少代碼行(LOC) 可能是相關的。但是，如果目标是盡可能地減少錯誤，那麼應該對測試名額（如報告的錯誤數量）施加更大的權重。

項目階段也将決定哪些軟體度量名額應給予更多考慮。項目早期，Git 送出的數量将産生有關子產品添加速度的寶貴資訊。以後，開發負責人将會對平均故障間隔時間 (MTBF) 或應用程式崩潰率 (ACR) 更感興趣。

評價和追蹤度量名額

我們應該記住，一個有價值的度量名額不僅僅是一個數字。任何給定時間的單點訓示在不顯示趨勢的情況下幾乎沒有用，它們需要呈現更大的畫面。這是因為從一天到另一天，某一特定度量名額可能幾乎沒有變化。然而，随着時間的推移，這一趨勢将逐漸凸顯成功或失敗。如果您的度量名額沒有凸顯出趨勢，那麼就需要重新考慮。

另一個重要點就是，度量名額必須建議和促進變化。使用不會帶來顯著變化的度量名額其實就是浪費時間，因為沒有這個，開發人員會繼續犯同樣的錯誤。需要重申的是，度量名額不僅僅是一個數字，而是需要進一步推進您的目标。如果有一個度量名額沒有導緻代碼庫或程序發生變化，那麼最好用更有意義的名額來代替它。

軟體度量名額類型

軟體度量名額可以分為幾個不同的類别，根據團隊、環境和開發階段的不同，每個類别對項目可能或多或少有用。不同的度量名額适用于不同的粒度級别，其中一個與單個開發人員相關，而其他名額則考慮團隊績效。當然，有些适用于兩者，盡管個人和團隊應該分開評估。

代碼度量名額

代碼度量名額是用于訓示代碼庫細節的衡量标準。這些可能是以大小為導向的名額（例如，代碼行總數 或邏輯與注釋的比率），或者是與内容相關的名額（例如，代碼複雜性名額）。總之，代碼度量名額隻在一定程度上有幫助，特别是在單獨使用時，因為它們沒有充分考慮環境，是以不能說明全部情況。

以規模為導向的度量名額

以規模為導向的度量名額是一種代碼度量名額，通常用于以千行代碼 (KLOC) 來比較相同語言的項目。KLOC 度量名額不用于衡量項目規模。相反，它們是統計度量，訓示每 1000 行代碼的相對錯誤數、相對缺陷數和相對成本。無論項目規模如何，它都使用這個通用基線。由于程式設計語言之間的内在差異，以規模為導向的度量名額在比較使用不同語言開發的項目時并沒有用處。

方法特定度量名額

編碼方法因公司和項目而異。雖然有共同的目标，但是方法，或者更具體地說，過程各有不同。說到 KPI，不同的方法有不同的優先級。兩種流行的方法是 Agile（靈活方法）和 Waterfall（瀑布法）。

靈活過程度量名額

這些度量名額專用于遵循靈活過程方法的開發團隊。它們用于衡量團隊在釋出可傳遞軟體方面的效率。例如，Sprint Burndown 用于跟蹤沖刺期間的工作完成情況，并顯示剩餘的工作量。速度是另一個靈活法度量名額，用于描述團隊在沖刺期間可以完成的工作量，以小時或故事點來衡量。

瀑布法度量名額

瀑布法比靈活方法更為固定，通常在項目需要高度可靠性或要求明确的情況下使用。由于固定的時間線不包括頻繁的回報，是以度量名額有所不同。例如，在實施階段發現的錯誤數量非常重要，因為有時需要傳回設計階段。如果這種情況發生的太頻繁，可能表明實施前審查過于倉促。

工作效率度量名額

工作效率名額可以用來确定一個項目或一個團隊已完成的工作量。這與工作完成的效率和速度高度相關，本質上突出了團隊的優勢和需要改進的地方。選擇工作效率名額時，應確定選擇不僅相關且代表項目實際目标的名額。

工作效率實際上是任何項目都應該最大化的名額。正如我們在部落格文章 C++ 開發人員的工作效率工具中所讨論的那樣，有各種各樣的工具可以幫助提高個人和團隊的工作效率。

安全度量名額

安全度量名額用于衡量軟體對安全事件的敏感度或抵抗力。存在軟體漏洞的成本可能非常高，而且會導緻政府合規性方面的問題，是以這種類型的度量名額對于某些産品來說是必不可少的。安全度量名額的例子包括解決漏洞所需的平均時間和自動靜态代碼掃描識别的漏洞數量。需要記住的重要一點就是，與代碼分析器檢測到的漏洞數量相比，某些安全度量名額（例如與合規性相關的度量名額）與執行管理層的相關性更大。滿足所有相關利益相關者的需求很重要。

營運度量名額

營運度量名額有助于評估軟體在生産環境中的運作情況，包括産品的年度正常運作時間或正常運作時間與停機時間的比率。這些名額很重要，因為它涉及到品質保證、産品可靠性，以及是否有足夠的資源用于維護和支援。但是，這些名額對于開發新産品的開發團隊來說沒有那麼有用。

産品度量名額

産品度量名額可表明産品在市場上的表現如何。這些名額并不隻是适用于軟體領域，但至少可以應用。您可以利用這些名額跟蹤諸如您的産品在多大程度上滿足公司目标等情況。這些名額的例子包括使用者采納和客戶保留。這些名額旨在回答管理層和規劃者的問題，而不是開發人員的問題。

品質保證度量名額

品質保證是個籠統的術語，包括故障名額以及其他與維護相關的衡量名額。這其中包括諸如平均故障間隔時間以及修複故障通常需要多長時間等細節。這可以深入了解正常運作時間與停機時間，以及有多少停機時間可歸因于維護。

測試度量名額

在任何版本轉移到生産環境之前，開發人員和産品測試人員都會使用各種測試名額。這些名額有助于提供有關系統測試情況的資訊，這與品質保證有關。但是，這些名額并不适用于管理層，這是它們與更一般的品質保證名額的不同之處。管理層使用品質保證名額判斷釋出的品質，而測試名額僅用于在預釋出階段為開發人員提供幫助。

具體度量名額——詳細研究

現在，您已經有了一個大概的了解，接下來讓我們看一下根據您的項目和流程可能會選擇的一些特定軟體度量名額。

傳遞周期

這反映了開發新功能或子產品從定義到傳遞所需的時間。它傾向于顯示開發組對利益相關者的請求的響應程度。即使團隊不願意提供大緻的傳遞時間，我們也可以通過檢視具有類似功能集的以前的産品來估計。

循環時間

該度量名額是指變更請求與其可傳遞或生産釋出之間的時間。其中包括打開問題的時間、發現和審查問題的時間、準許工作的時間、完成更改所需的時間，以及部署時間。這是一個非常重要的度量名額，因為它表明了價值實作時間與效率的比率。

部署頻率

部署頻率指的是每天釋出的數量。該度量名額可表示傳遞給客戶的價值水準。考慮這一點很重要，因為開發管道可以在較短的周期内實作高效，但同時，部署頻率低可能意味着傳遞的價值不足。

團隊速度

通過團隊速度，我們可以深入了解團隊在靈活法沖刺期間或釋出疊代期間完成的工作量。雖然它對于衡量團隊内部随着時間的推移而取得的進展很有用，但它不應該用于比較團隊，因為每個團隊可傳遞成果的性質和複雜性可能無法比較。

打開/關閉率

打開/關閉是在規定期限内識别和确認的生産問題。這一比率随時間的推移而增加，這表明團隊在解決問題方面變得更加高效。

效率/工作效率

效率通常是指開發人員在生産中的代碼量，以百分比而不是代碼行數來衡量。高效率與更長時間地提供價值相關，而低效率則可能表明在難以實施的創新功能上出現了許多錯誤的開始。與效率相反的是代碼改動，它表示非生産性編碼的水準。

活躍天數

活躍天數與程式員的工作效率有關。一個活躍日代表單個開發人員在單個項目上工作的一個編碼日。這可以僅跟蹤程式設計，而不包括行政管理工作。事實上，會議等行政管理任務占用了編碼時間，而這正是該度量名額所衡量的。從本質上說，跟蹤活動天數重點關注中斷成本。

影響

該度量名額是一種主觀衡量标準，表示添加、删除或修改代碼後項目的更改程度。其理念是，影響更大的變更更難實施，這意味着需要承擔更大的任務，或者可能需要更大的認知努力。例如，與更改一組輸出語句中的文本相比，添加一個新穎而複雜的功能将産生更大的影響，即使有更多行的修改代碼。

代碼改動

代碼改動是一個基于 Git 的度量名額，可提供對個人和團隊等的洞察。它表示開發人員在短時間内修改或删除了多少工作，通常表示為在指定時間内更改的代碼行數。代碼改動率高可能意味着開發人員不确定該做什麼，實施時遇到問題，甚至他們沒有其他工作要做。從管理層或團隊的角度來看，這可能表明相關子產品或功能未正确定義或過早添加。

平均故障間隔時間(MTBF)

該品質保證度量名額表示平均無故障時間，定義系統的可靠性。故障是必然會發生的，但是最好很少且相隔甚遠。理想情況下，當确實發生故障時，恢複所需的時間相對較短，但無論如何，在安排預防性維護時，該度量名額可以提供幫助。

平均恢複/修複時間(MTTR)

即使是高度可靠的系統也會發生故障，而當它們發生故障時，客戶希望将是以導緻的任何停機時間降至最低。為此，平均故障恢複時間必須盡可能地短。當然，故障的嚴重程度會有所不同，做出必要更改的個人也會有所不同，所有這些都會給度量名額增加幹擾。但是，随着時間的推移，在預測客戶在操作恢複正常之前必須等待多長時間時，MTTR 将作為一個可靠的估計。

應用程式崩潰率(ACR)

應用程式的崩潰率類似于 MTBF，但它是指使用頻率與失敗頻率的比率。MTBF 則不一樣，因為它是時間度量。

終點事件

終點事件涉及安全相關問題，表示在規定時間段内有多少裝置受到惡意軟體的影響。這可能是軟體漏洞造成的。

每KLOC的錯誤數/每KLOC的缺陷數

每KLOC的成本

該名額描述每一千行代碼的平均成本。它可用于描述項目的不同階段。例如，開發期間每 KLOC 的成本将與釋出後維護期間的每 KLOC 的成本不同。

每個功能點的工作量/每個功能點的缺陷數/每個功能點的成本

這些是以功能為導向的度量名額，取決于首先計算功能點 (FP) 的名額。功能點是一個表示軟體應用程式中使用者可用的業務功能的衡量标準，可根據需求進行定義。

作為一個基本的度量機關，功能點具有相關的衡量标準，其中包括每個功能點的工作量 (EFP)、每個功能點的缺陷數 (DFP) 以及每個功能點的成本 (CFP)。較低的 EFP 意味着較高的工作效率，而較低的 DFP 則代表較高的産品品質。CFP 表示成本效率，而 CFP 的降低意味着開發和維護變得更具成本效益。

缺陷排除效率

缺陷排除效率 (DRE) 用于表示與釋出前開發和測試期間發現的缺陷數量相比，最終使用者發現的缺陷數量。其計算方法是将傳遞前發現的錯誤數除以軟體投入生産前後發現的錯誤總數。最終使用者發現的錯誤越多，則用于表示效率的數字越小。滿分是 1.0，這表明最終使用者在生産中沒有發現任何問題。

選擇不當衡量标準時的不良影響

度量名額選擇不當可能帶來的後果不僅僅是浪費時間，尤其是在單獨考慮時。了解您正在度量的内容很重要，以下示例說明了可能發生的一些潛在問題。

代碼行(LOC)

我們來考慮一下當代碼行是唯一或主要度量名額時的情況。就其字面而言，人們可能會認為寫更多行代碼更好。但是，作為一個經驗豐富的管理人員，您知道事情并不總是這樣。實際上，當代碼行作為驅動因素時，開發人員傾向于編寫不那麼優雅、更繁瑣且效率可能更低的長代碼。除非它與效率回報名額相結合，否則代碼行更像是一種負擔，而不是獎勵。

代碼覆寫率

另一個單獨使用的有問題的度量名額是測試中的代碼覆寫率。如果不使用諸如每次測試發現的缺陷數量等其它品質名額，而僅使用代碼覆寫率，可能會産生誤導性的結果。如果測試很幼稚，不能可靠地識别錯誤，就會發生這種情況。代碼覆寫率可能會非常高，進而産生一個令人印象深刻的度量名額，但是如果不知道測試結果，會更難以對測試進行評估。

是否有與特定項目更加相關的衡量标準？

毫無疑問，不同的度量名額與特定項目更相關。例如，衡量影響就和處于初始階段的項目無關。另一方面，與在更成熟的産品中處理功能請求相比，代碼行等代碼度量名額在早期開發期間更有價值。為您的項目選擇适當的衡量标準意味着在适當的時間将度量名額與适當的目标相比對，并確定度量名額互相補充，以增加統計資料的有效性，進而最終引導代碼庫、團隊或流程發生積極變化。

結語

軟體度量名額是應用于軟體開發周期的定量衡量标準，可用于評估項目的目前狀态。随着時間的推移，趨勢将會出現，而開發負責人可以展示進度，計算項目決策的影響，并對時間表做出可靠的估計。度量名額是無價的，對于任何項目的推進都至關重要。

同時，使用太多度量名額，或者使用那些對項目目标沒有幫助的名額，反而會适得其反。沒有哪個度量名額是一門精确的科學。請做出明智的選擇！ 然後，跟蹤和評估這些度量名額，以確定每一個都能發揮作用。如果一個度量名額沒有帶來變化，則必須對其進行修改或更換。

本文作者:Dori Exterman 來源:incredibuild

CIO之家 www.ciozj.com 微信公衆号:imciow