敏捷方法中的軟件度量

Question

當前敏捷方法比較流行，但似乎找不到有關哪些度量最有用的原因以及原因。我發現很多事情說像測試LOC和代碼覆蓋一些傳統的指標是不恰當的，留下兩個主要問題：

1. 爲什麼這兩個（及其他）指標不合適？
2. 什麼指標最適合敏捷，爲什麼？

即使採用敏捷過程，您是不是想知道您的單元測試有多少代碼覆蓋率？或者僅僅是這個度量標準（和其他標準）不是，因爲作爲其他度量如圈複雜度和速度有用嗎？

Answer 1

敏捷是一個商業化的東西，敏捷是關於最大化客戶價值，同時最大限度地減少浪費提供最優化的投資回報率。這是應該測量的。爲此，我使用Mary Poppendieck recommends的系統。該系統是基於必須被視爲一個套餐三次全面測量：

1. 週期時間
   • 從產品概念到第一個版本或
   • 從功能需求到功能部署或
   • 從錯誤檢測到分辨率
2. 商業案例實現（沒有這個，其他所有東西都是不相關的）
   • P & L或
   • ROI或
   • 投資的目標
3. 顧客滿意度
   • 例如Net Promoter Score

當然，在球隊的水平，你可以跟蹤之類的測試覆蓋率，圈複雜度，符合編碼標準等，但高品質的本身並不是一個結束，它只是一個平均值。不要誤解我，我不是說高品質並不事項，高品質是強制性的，以實現可持續的速度（和我們有「不增加技術債務」在我們做定義），但儘管如此，我們的目標是以快速和盈利的方式爲客戶提供價值。

Answer 2

1.1）LOC很容易回答

• 他們真的取決於你使用的語言！在JAVA或紅寶石寫入時同樣的功能可能有很大的區別，例如

• 一個寫得不好的軟件可能具有多好的一個多行！

1.2）的代碼覆蓋率

• 恕我直言，你應該使用指標，雖然它並不完美，它應該給你在哪裏你的代碼需要更多的測試，一個很好的瞭解。

• 你應該注意的一點是，它也依賴於語言。可能有一些情況下，你有一個你真的不需要測試的類或方法！例如一個只有getter和setter的類。

2）從（1）你剛纔提到的代碼度量，而是來自你對速度的問題來看，你有興趣在所有的創作過程度量，所以我會列出一些：

• 速度：經典之作，如果使用得當，它可以提高團隊的敏捷表現，因爲你會知道你的團隊在固定時間能夠真正做到的。

• 燒起來，並燒燬圖表：他們可以給你的團隊是如何相互作用（衝刺）期間執行一個很好的概念

大約有此相關的一些文章。 Here和here。

Answer 3

不管採用什麼方法，都可以使用一些基本指標。
據S. Kahn，其中最重要的有以下三種：

數量的測試

和數量在現場發現的缺陷的最後階段發現的缺陷產品的

• 大小。

如果這些都是您跟蹤，有至少五個方面，他們可以使用：

• 計算產品不良率（A）
• 計算測試缺陷率（B）
• 確定A的理想目標並監控性能
• 確定B的理想目標並監控性能
• 評估A和B之間的相關性
• 如果相關性被發現，測試效率（B/A×100％）

雖然不一定有趣的閱讀的形式度量，Metrics and Models of Software Quality Engineering提供了一個極好的深入軟件工程和指標概述。

Answer 4

至於問題1，在敏捷過程中，我認爲沒有任何理由說明這些度量標準是不好的。

LOC爲您提供了相對尺寸測量。雖然比較不同項目之間的數字並不總是有用，但它可以爲您提供項目內的增長率。如果你能得到它，那麼在sprint中改變的行數也可以用來跟蹤速率或重構。

代碼覆蓋率（代碼行）可以讓您瞭解您的團隊是否符合項目中自動化測試的最低標準。

對於問題2，保持以上項目和這裏有幾個：

• LOC與測試計數。如果可以的話，爲單元，集成和系統測試保持單獨的比率。
• 每個故事的驗收標準與測試場景（或測試）的平均數量。它可以幫助您更好地瞭解您的測試是否符合故事的意圖。
• 發現的缺陷數量
• 發現的工作量（這通常由敏捷跟蹤軟件捕獲）並非原始估計值。它會幫助你判斷你是否做了足夠的計劃。
• 速度衝刺的衝突一致性或缺乏衝刺
• 雖然可能不是流行的並且可能有潛在危險，但是跟蹤每個開發者完成工作的估計。雖然團隊應該是自我組織和推動的，但並非所有團隊都有能力處理人類問題。

Answer 5

我想補充

爲什麼LOC和測試的代碼覆蓋不理想：

敏捷強調結果，不輸出（見敏捷宣言）。這兩個只是跟蹤輸出。此外，他們沒有正確地衡量重構，這是敏捷過程的一個重要方面。

另一個標準考慮將運行測試後的特點。我無法描述任何比這更好：http://xprogramming.com/articles/jatrtsmetric/

Answer 6

我要回答這個很老的問題...

LOC和測試覆蓋率，在我看來，良好的指標，但他們有一個大問題：如果你把他們，你可以讓他們快速度增長，但結果將是terryifing：噸的廢話代碼，或在測試覆蓋率，可以invoque所有的代碼在一個try-catch塊，而不是寫一個單斷言......或者更糟糕，只寫一個「合規性」的原因，但沒有任何業務面向或面臨代號的含義...

因此，這幾樣指標都非常好，如果他們幫助球隊誠實地評估他們的結果，但有一個邪惡的工具，如果它們形成的一些「遵守」規則的一部分，因爲以這種方式使用它們造成更大的傷害（死碼，壞測試！）比你原來想實現。

因此，與每個指標，認爲你會如何欺騙它，如果你被迫要達到一定的值，並且想到後果......這不是LOC或測試覆蓋率的問題，很多其他指標可以有類似的結果，甚至是圈複雜性...如果以不良方式劃分代碼，可以減少圈複雜度，但這並不意味着代碼變得更好或更易讀。

因此，這幾樣指標都相當不錯，看看有什麼是一個團隊裏面發生的事情，但你採取任何措施，應根據具體的目標，而不是度量本身...例如：

測試覆蓋率很低：您每個月都會執行一次編碼dojos來幫助培訓人們編寫可測試代碼，您會發現哪些代碼具有最差的測試覆蓋率，並嘗試實施更好/更可測試的體系結構，以幫助/激勵開發人員編寫測試等。正如你所看到的，你永遠不會告訴團隊達到一定的測試覆蓋率值，你只需使用該指標來看看你可以改進的地方，然後尋找有利於你的措施過程中，一段時間後，你會期望測試覆蓋率增加，但你不會推動人們這樣做！您正在評估更改以查看這些措施是否有所幫助。如果過了一段時間，你發現測試覆蓋率沒有隨着你的測量結果而改變，那麼是時候去尋找其他想法了，等等......