《精益軟體度量——實踐者的觀察與思考》讀書筆記（一）

由于最近項目研究需要，對軟體工程中的軟體度量比較感興趣，在目前的實際軟體項目中，其實很難做到對軟體過程進行度量，常常面對“我有一堆資料，卻不知道怎麼利用它們給項目帶來改進”這樣的問題。在現在這個大資料時代，擁有資料其實就是擁有了一切，而如何利用這些資料成為了一件很棘手的事情。管理學大師彼得·德魯克曾說過“如果你無法度量它，就無法管理它”。要想進行有效的管理，就繞不開度量的問題。

《精益軟體度量——實踐者的觀察與思考》這本書給了我很多啟發，我雖然作為一個還在研究所學生階段的學生，但也接觸過一些實際軟體開發項目，目前的研究方向就是軟體過程管理，最近主要在看效能方面的内容。我覺得軟體工程是一門很難的學科，并不是如算法那般技術上的難，而是實踐中與理論不可能一樣的難，可以說軟體工程是一門管理學，管理項目，管理人員，管理資源……雖然難，但是研究這種充滿不确定性因素的東西還是很有意思的。

chapter 1 度量謎題

1.1 精益軟體開發的度量體系

度量本身不是目的，是手段。這句話其實闡明了很多人對度量這個詞的誤區。資料的生産者不是其使用者，且沒有動力去分析資料産生的價值與準确性，他隻關心他生産的資料是否能給他帶來收益或者懲罰。而對管理者來說，度量的目的是確定事情在掌控之中，帶來安全感和可靠感。這就是目前度量這個問題的現狀。

度量的重心應該從“控制”轉向“改進”，也就是挖掘資料真正的價值，用曆史資料為未來提供改進措施。

度量體系的作用就是提供資訊來幫我們知道現在在哪裡，距離目标有多遠，我們是否在朝着目标前進，進展的程度如何。

書中将度量體系實作分成了3個不同的層次：理念、設計、應用。

    分析性思維：标準化，消除個體判斷帶來的偏見和差異，偏可靠性

    啟發性思維：發現和創新，偏向有效性

1.2 度量是什麼

1 度量是在一個特定組織上下文中形成的一系列共識。

2 度量是将經驗模型向量化模型進行比對的嘗試。

3 度量是包含人、流程、組織和工具的一個動态系統。

1.3 度量不是什麼

1 度量不是軟體開發固有的活動。

2 度量應該避免跟績效直接相關。

3 度量不是免費的。需要投入時間、工具和基礎設施的投入等。

chapter 2 組織目标

     業務目标 - 開發組織服務的企業業務目标是什麼？對應到對開發組織的期望是什麼？

     決策場景 - 在開發過程中，誰是度量資訊的使用者？他們使用度量資訊的目的是為了做什麼決策？

     名額體系 - 如何設計一個契合的名額體系來滿足這些資料消費的需求？

目标 -> 決策場景 -> 名額體系

業務組織的目标：響應速度、産能、投入産出

開發組織的目标：價值、效率、品質、能力

軟體開發組織的改進：速度、效率、品質、能力

對應政策：切合時機、減少浪費、品質内嵌、學習型組織

chapter 3 決策場景

軟體度量資訊的使用者：管理者、項目管理、工程師

影響開發組織模型和流程模型的5方面因素：

    關鍵性——缺陷帶來的影響

    參與人員的水準——技術與決策人員的協作

    動态性——需求的變化頻率和程度

    文化——團隊有對混亂和秩序的偏好

    規模——産品和項目規模

chapter 4 名額架構

戴明環（PDCA）：P計劃、D執行、C檢查、A行動

    管理層 - 組織

    項目管理人員 - 項目

    工程師 - 個人

4.1 支撐決策的資料

計劃 - 根據已知的資料，設定合理的目标，預測未來可能發生的情況，制定可行的計劃。

組織層面

計劃	參考度量名額
産品組合規劃	産品銷售預期 營運成本 資本投入産出
傳遞路線圖、裡程碑	傳遞周期
效率提升目标	機關規模産能 競争對手研發效率比較 組織技能水準
配置資源計劃	傳遞周期 機關規模産能
市場、使用者滿意度提升目标	産品、特性價值命中率 使用者滿意度 曆史品質資料 競争對手品質資料

項目層面

計劃	參考度量名額
項目進度計劃	工作量估算 團隊産能
品質目标	産品品質資料
缺陷預防和排除政策	缺陷發現環節、比例 各級測視覆寫率（單元、功能、內建/系統測試）
資源規劃	傳遞周期 目标機關規模産能 團隊能力 個人能力
能力提升計劃	團隊能力 個人能力

個人層面

計劃	參考度量名額
工作量承諾	工作量評估 個人能力
提升目标	個人能力 團隊能力 組織、團隊技能期望

檢查 - 識别現實與預期的差異、面臨的問題、改進的空間

檢查	參考度量名額
進度	團隊産能和計劃産能對比
效率	流量瓶頸 能力瓶頸 浪費統計
品質	遺留缺陷趨勢 各級測試覆寫率（單元、功能、內建/系統測試） 目标和狀态對比
能力	技能瓶頸 個人能力提升進度 組織能力提升進度
滿意度	客戶使用回報 支援響應速度 問題解決率

4.2 名額

為支援上述的決策，需要設計和營運一套名額體系來收集和分析相關的資訊。

名額體系包括：

名額的次元

每個次元裡可選的具體名額

名額的優先級評估

名額的資料采集、分析和使用方法

4.3 名額屬性

名額ID和名稱
相關的提升目标	這個名額針對的是效率、品質或人員的相關提升名額？ 名額跟目标的關系是什麼樣的？
定義	準取的計算和提取算法
假設	使用這個名額的假設是什麼？ （是否需要團隊有比對的開發實踐？是否需要某種基礎設施？）
使用級别	團隊、項目、組織
使用者	識别名額的使用者及其使用方式 （産品管理、研發主管、項目管理、開發、測試……）
采集方式	誰在什麼場合下，通過什麼手段收集和分析名額資料
期望的名額趨勢	期望名額在某種條件下應該是提高或降低
潛在負面影響	名額可能引起團隊的博弈行為，應該先行教育
工具支援	是否有自動化的工具進行無侵入資料收集、分析
其他注意事項

4.4 名額優先級

有效性：名額資料在多大程度能真實地為達成目标服務

可靠性：資料收集以及分析結果的一緻性與可靠性

成本：度量資料的收集和分析成本

4.5 名額體系的局限性

1 及時在名額上取得了亮麗的數字，也未必一定能夠達成業務目标

2 脫離使用場景，單獨使用某個名額，通常也沒有什麼意義

4.6 名額體系需要演進

1 目标的演進

2 名額資料的收集和分析手段

3 團隊的成熟度

4.6 度量資訊的傳播和使用

度量相關資訊：期望目标資訊 & 度量結果資訊

1 度量資料應該解決資料生産者的問題：對本級組織的改進活動提供幫助

2 各級組織有自己的期望和目标并需要上下雙向溝通

chapter 5 度量對象模型

被度量對象：傳遞流程、傳遞對象

5.1 傳遞流程模型

5.2 傳遞對象模型

5.3 度量邊界模型

chapter 6 價值

6.1 識别和拆分高價值特性

6.2 回報提升價值

6.3 減少沒發揮價值的特性

6.4 傳遞價值的度量

釋出前 - 評估待開發特性的價值

釋出後 - 驗證價值

   **價值傳遞速率**：團隊的産能和機關産量所産生的價值

   **價值轉化率**：每個工作環節的工作有多少是為下面的環節産生了價值

chapter 7 響應速度

要提高特性的周轉速度，提升一個開發組織地市場響應速度，應該關注以下幾個不同層面傳遞單元的周期資料，發現其中的改進點。

版本釋出：從項目立項到釋出的時間，是端到端地釋出周期，其結果通常是産能和響應速度的一個權衡。

特性釋出：從需求定義到內建測試、驗收測試、回歸測試完成的周期，基本上代表了一個開發組織響應市場需求的最快速度。

使用者故事平均周期：從使用者故事被納入疊代計劃，經過分析、開發、測試等環節，到被驗收的時間，這是一個最小的端到端工作單元在一個團隊中流轉的時間。

缺陷生命周期：缺陷的平均生命周期代表團隊對測試、運維的響應速度。缺陷定位和修複周期也意味着代碼的可維護性，還有自動化測試保護網的完善性。

7.1 響應時間的系統因素

7.1.1 WIP（Work In Progress  - 半成品)

利特爾法則：生産周期 = 半成品 / 産能

7.1.2 系統資源使用率

相關資源或人員在生産或生産相關活動的時間的比例

7.1.3 需求的差異性

工作單元的大小 - 隊列緩沖

需求到來的時間 - 系統容量

7.2 價值流圖分析 （VSM）

7.3 累計流圖 （Cumulative Flow Diagram)

7.4 庫存類名額

chapter 8 工作量估算

8.1 基于算法模型的估算技術

通過一個公式，把影響軟體規模的因素，以參數化的形式納入到計算範圍之中。例：COCOMO

8.2 基于專家判斷的估算技術

依賴專家的經驗、直覺，以及專家間的互相磋商，有相當大的主觀性，偏差大，不具備重複性。

8.3 度量機關

三大類：人天（Man Day)、代碼行數（SLOC）、功能點（function point）

8.3.1 功能點 （function point）

8.3.2 用例點 （user case point）

8.3.3 故事點 （story point）

8.4 估算的選擇與運用

chapter 9 産能

機關規模組織在機關時間内所能傳遞的軟體規模。

9.1 度量産能

       不同做法通常是在有效性、可靠性和成本上做出了不同的取舍，因而對團隊和個人的行為也會産生不同的牽引效果。

1 産能

        疊代開發模型中直接的産能名額是疊代速率——團隊在一個疊代中完成的使用者故事點數，也稱為疊代産能。實踐中通常用連續2-3個疊代的平均值來訓示一個團隊的産能。

        如果是新産品（新業務/新領域），會在疊代開發中有熱身的過程，是以會有一個值得關注的名額——疊代産能趨勢。

**邊界性問題**

隻要沒通過DoD品質保障手段檢驗，其工作量就不應該被計算在目前疊代完成的産能裡。

2 節奏

        節奏名額是代碼合入頻率和建構頻率，代表了代碼産能的穩定性和可靠程度，穩定的節奏通常也意味着進度的穩定和品質的穩定。還代表了回報的周期，快速合入代碼并驗證意味着更早地發現可能存在的問題。

        隻有成功通過自動建構裡的各項驗證活動的代碼，才能被計入産能的統計。