PR VV 同行評審驗證確認 用實例學CMMI V2.0

如何提升(軟件)交付質量
大家可先看看下面 Xerox 公司的缺陷統計數據

 

 

 

 

缺陷修復成本是越後越高，而且以倍數遞增， 所以 軟件工程有個重要原則，儘量第一次就把工作做好 (do it right the first time)，減少返工。

所以從軟件質量管理，我們要：

1. 盡力避免在整個開發過程中產生缺陷

2. 如果有缺陷產生，要儘早排除。例如：瀑布性開發過程 - 要做需求評審，設計評審，代碼走查 ， 單元測試

3. 在過程中收集不同階段發現的缺陷數，兩個目標：a)把總的缺陷降低；b)把缺陷的高峯儘量往前推

 

下面首先會先介紹 CMMI V2.0 PR 與 VV 的 Practice 如何一一對應 以前 V1.3。

接着用一些實例解答如何從1級升到2級再升到3級，量化管理等的常見問題：

1. 從1級升到2級：我們做好測試，有系統測試，有QA保證不就可以了嗎，爲什麼要花精力做評審，尤其現在講究敏捷、簡單，評審是否已經過時？

2. 爲什麼要把在評審中發現的問題記錄下來並跟蹤，讓成員自發完善不是更省事嗎？

3. 爲什麼要有固定的測試環境？爲什麼重要？

4. 爲什麼極少公司能做好量化管理？收集哪些數據？成功要素是什麼？

5. 量化管理、度量，爲什麼要統計？自己依據發現的問題改好是否也可以？統計出來的數據應該如何有效利用纔對整個團隊的提升有幫助？

例如：有效的量化管理必須依據有效的公司目標驅動,後面的金融產品開發組的量化管理例子告訴我們 - 除了要度量公司關心的結果外，也需要度量一些可控因素，才能更好幫我們改善。

最後以 ‘質量之旅’總結，讓大家瞭解質量改進的路徑圖，與不同成熟度的差異。

整個討論也對應CMMI V2.0 模型 的 ‘同行評審 PR’與 ‘驗證確認(V&V)’各實踐

 

• 目錄  

• PA介紹

• PR 1.1對工作產品進行評審並記錄問題

• VV 1.1執行驗證來確保需求得到實現並記錄和溝通結果

• 從1級升到2級：同行評審案例分享

• PR 2.1開發並持續更新用於準備和執行同行評審的程序與支持材料

• PR 2.2選擇要進行同行評審的工作產品

• VV2.1 選擇用於驗證和確認的組件和方法

• Agile Tips 敏捷又如何

• PR 2.3使用既定程序準備和執行選定工作產品的同行評審

• PR 2.4解決同行評審中發現的問題

• VV 2.2開發,使用並保持更新支持驗證和確認所需的環境

• VV 2.3制定、保持更新並遵循驗證和確認程序

• 3級：從定性提升到度量與分析

• 與一金融產品開發組長對話

• 度量可控因素

• PR 3.1分析從同行評審得到的結果和數據

• VV 3.2分析和溝通驗證和確認結果

• VV 3.1制定、使用並保持更新驗證和確認標準

• 質量之旅

• 附件1：敏捷團隊如何有效利用度量數據分析

• 附件2：Inspection審查

• 反饋

• References

•  

PA介紹

PR (V2.0)

VV (V2.0)

VAL (V1.3)

VER (V1.3)

 

CMMI V2.0從V1.3特別抽出“驗證”(VER) 中的第二目標“同行評審”作爲一個單獨的PA。 可見CMMI也認同同行評審確實可以幫助項目預早找出缺陷和問題，減少後面的返工。

在V2.0， 同行評審的大部分實踐屬於CMMI 2級 (分析部分屬於3級)。以前在V1.3，“驗證”(VER)，包括同行評審，和 “確認”(VAL) 都屬於 3級，工程部分。

2.0版本和1.3版本的對應：

V2.0 對應 V1.3

什麼屬於 驗證(VER) 或 確認(VAL) ， 一直有很多爭議 (我確實見過 一些開發公司 V V 的 定義 與 CMMI 的定義剛剛相反)

V1.3 的 VER 與 VAL 本來就很相近： 如果把VER 的 中間第二部分抽出來， V 與 V 的內容基本一致：

PR 2.1 2.2 <= V1.3 VER SP2.1

PR 2.3 2.4 <= V1.3 VER SP2.2

PR 3.1 <= V1.3 VER SP2.3

VV 2.1 <= V1.3 VER / VAL SP1.1

VV 2.2 <= V1.3 VER / VAL SP1.2

VV 2.3 <= V1.3 VER SP3.1 / VAL SP2.1

VV 3.1 <= V1.3 VER / VAL SP1.3

VV 3.2 <= V1.3 VER SP3.2 / VAL SP2.2

PR 1.1對工作產品進行評審並記錄問題

Perform reviews of work products and record issues.

對工作產品進行評審並記錄問題。

Value 價值

Improves work product quality and reduces cost and rework by uncovering issues early.

通過儘早發現問題，提高工作產品質量，降低成本和返工。

VV 1.1執行驗證來確保需求得到實現並記錄和溝通結果

Perform verification to ensure the requirements are implemented and record and communicate results.

從1級升到2級：同行評審案例分享

以下例子說明, 無論是敏捷或傳統開發,都可以使用一些CMMI的最佳實踐，如同行評審，幫助改善質量。

敏捷開發越來越多人談，在杭州客戶現場，剛好就有本地諮詢顧問，印度CMMI評估師 和我。 印度老師 除了有20年的CMMI經驗外，也是敏捷的導師。有些人誤解以爲敏捷就是要減輕過程，可以不需要文檔，只是把開發做好便可以。

我們在和測試人員討論他們如何評審測試用例，他們說直接把寫好的測試用例發主管，主管覺得可以就可以。其中一位評估組成員覺得不合適，另一位偏敏捷的覺得同行評審測試用例這活動沒有價值，可以節省掉不做。

印度老師說：同行評審有多個不同的形式，有些較嚴格，有些較省力，如發郵件去讓其他人看。

問：對不同的產物有那些不同的評審方法？ 這企業就展示出在項目計劃中的一個列表：

• 需求 - 需要客戶評審

• 設計 - 需要同行評審

• 代碼 - 也是同行評審

問：同行評審如何定義？ 規定怎樣做？

這企業不同人有不同的理解，公司級也沒有明確定義。

老師接着說：如果同行評審是指審查(Inspection)，代碼也用正式同行評審是很理想，但可能太花人力，所以越來越多團隊使用靜態（代碼）檢查。

評審方法有很多，常見的包括：

1. 審查(Inspection) - 最正規，最嚴謹的方法，通常用於重要的產物，比如框架的設計

2. 走查(Walkthrough) - 要求低一些，例如 一起開會，把產物投出來一起看

3. 最簡單也可以是兩個人互相查看，或者發郵件

 (附件2 詳細介紹 Inspection 審查)

老師接着說：計劃時也要定那些工作產品選用那種評審；例如，像以上那種只說設計/代碼都是採用某種評審方法便太籠統

他還建議需要有一個項目的質量計劃 (Quality Plan)，預先列出對那些階段的那有產物採取什麼方法來評審。也預定每個階段要達到什麼質量要求，如發現多少缺陷。

例如：代碼評審 - 核心的代碼你可能就需要做正規的同行評審。但是如果是一些用戶界面那種就簡單一點，但必須要質量計劃(或項目計劃)裏面預先定好，然後按照計劃去做。

PR 2.1開發並持續更新用於準備和執行同行評審的程序與支持材料

Develop and keep updated procedures and supporting materials used to prepare for and perform peer reviews.

PR 2.2選擇要進行同行評審的工作產品

Select work products to be peer reviewed.

VV2.1 選擇用於驗證和確認的組件和方法

Select components and methods for verification and validation.

 

因爲不同的評審方式，各有利弊，所以首先要定義好每一種方法，讓團隊可以挑選最佳配搭。 同樣原因，也需要選擇哪些產物要怎樣評審/測試。 上面同行評審案例分享中的質量計劃(Quality Plan) 便是一個例子 - 預先策劃好那些產物採取什麼方法來評審最合適。

質量計劃(Quality Plan)例子

因爲團隊有信心採用新的代碼評審方法後，可以提高代碼評審的缺陷發現率，在質量計劃中，代碼評審的缺陷密度設定比歷史數據的基線高，但是比模型預測較高的缺陷密度數低一點。

 

Agile Tips 敏捷又如何

 

如果我們不是按傳統的瀑布式開發，沒有明確的需求、設計階段，按敏捷迭代來做，是否同行評審這種最佳實踐便用不上？

大部分的敏捷團隊都有用靜態檢查，效率比人工評審高；但複雜的代碼還是要依賴人工評審。例如：有些金融的核心模塊，因算法複雜，很難單靠測試找出缺陷，必須依賴專家查看代碼(評審)。

因直接看代碼，評審還是會比測試更有效率。(測試發現有缺陷，還是要看代碼) 所以不要以爲敏捷就不需要評審，如果你還記得較早的一種敏捷方法叫極限編程 (Extreme Programming)，它提倡的結對編程(Pair Programming)就是一種評審，只是不等到寫完代碼才做，而是寫代碼時，與坐在旁邊的同伴編碼與評審同時進行。而不是寫完代碼後才評審，發現缺陷。

目的很簡單，無論評審還是測試，儘可能早做，找出缺陷。

從批量交付到持續交付的例子：

 

構建測試環境，端對端持續測試。

PR 2.3使用既定程序準備和執行選定工作產品的同行評審

Prepare and perform peer reviews on selected work products using established procedures.

PR 2.4解決同行評審中發現的問題

Resolve issues identified in peer reviews.

 

技術評審（例如：代碼走查、設計評審，或者需求評審）的通病是缺乏檢查單，也缺乏評審記錄。爲什麼要檢查單，其實是個經驗的累積，哪些問題以前常常出現，就應該變成檢查項，後面的評審要注意，評審好比測試，目的是，用最短的時間，最小的力度，找出最多的問題。

很多人說自己有做互相代碼的檢查，但在問有什麼發現，有什麼記錄就記不清。

還有就是這些缺陷如果要修改，怎麼確保修改正確？沒有改錯？因爲有可能本來沒有問題，改完反而出錯。

VV 2.2開發,使用並保持更新支持驗證和確認所需的環境

Develop, keep updated, and use the environment needed to support verification and validation.

 

大家可能都遇過因爲環境不一樣，有些缺陷測不出來。

我們一個香港政府部門客戶IT部門，必須所有新開發的系統在他們一個固定的標準測試環境進行驗收測試，通過後才允許放到投產環境。證明穩定的測試環境很重要。

從批量交付到持續交付的例子：

 

確保環境穩定並持續可用。

VV 2.3制定、保持更新並遵循驗證和確認程序

Develop, keep updated, and follow procedures for verification and validation.

如何寫好測試用例，如何做好功能或性能測試 本身是一個很大的題目，也有很多專門針對測試的書籍，尤其是自動化測試，大家可能比我更熟悉。

3級：從定性提升到度量與分析

 

”沒有度量，就沒有管理”這話大家都贊同 但有多少軟件開發公司真正的使用一些可靠數據，幫助團隊持續改進？ 大部分公司都用一些工具來管理缺陷，但系統地統計並利用這些數據的團隊不多。

敏捷團隊度量分析例子1
當聽到數據驅動，大家可能立馬想到一些包含儀表板的工具，如SonarQube和Jira:

• 如圖1所示，SonarQube關注的是代碼度量:複雜性、單元測試覆蓋率、重複等等。

• 如圖2所示，Jira關注的是過程度量:問題解決時間、團隊速度等等。

 

一團隊實現數據驅動連續改進過程時，領導只是單看 儀表板上的新增代碼行數(LOC)，導致開發人員。 只爲了追求這數字，想盡辦法出增加這個數，而不是如何提升生產率和代碼質量，最終導致整個度量分析改進計劃告吹。

所以軟件分析儀表板雖然是非常有用和重要,但必須謹慎引入，而且動機要正確。如組織缺乏敏捷文化，管理層很容易以爲度量程序是用來從外部“管”質量和生產力，導致團隊會把它理解爲管理者不信任他們，反而影響了團隊的動力。

測試也一樣，如果只是單一的追求開發過程中缺陷密度(或缺陷數),效果也會一樣。

例子2

研發主管問： 我們每個開發工程師都有用靜態檢查查代碼質量，但爲什麼要統計？自己依據發現問題改好是否也可以？ 你不是提倡研發人員自主管理嗎？

答：理論上是可以，但實際上如果公司沒有系統地統計，你估計開發工程師會主動定期記錄/統計嗎？

我的老同學在深圳東莞，有一家"知識工廠"，專門爲國外做英文輸入。例如他有一美國老客戶，提供網站專門爲客戶尋找自己的祖宗信息，需要把大量老報紙，書籍，船票的掃描，利用人工配合電腦輔助，輸入成英文文檔。因爲項目的利潤都很薄。生產率很關鍵，如果生產率低項目就虧本。同樣質量也很重要，錯誤率也要很低。

生產場所坐滿時有二三百人，很多小組組成。每小組大概十人，有組長。每個組的大長桌上面都有一顯示，顯示當前的生產率與錯誤率。管理服務器也會不斷收集與統計每個小組的度量。每個小組和組長都很清楚自己組的表現。組長會盡力幫自己組提升水平。生產總經理會與各組長每天回顧成績和如何提升。

我說完以上故事，便繼續問研發主管，如果這"知識工廠"沒有系統地收集，統計與顯示生產數據，只靠每小組或每個工人自我管理，可以保證項目的利潤嗎？

所以迴應你的提問，我估計不會，或最多統計幾輪便不繼續。沒有度量，沒有壓力，我沒見過你說會自動不斷自我提升的‘聖人’；而且人不是機器，骨子裏是很厭惡不斷做一些重複性工作 - 手工收集與統計數據。

度量分析例子3

問研發主管：你們怎麼利用缺陷的統計工具來確保產品質量？

答：我們現在用自動檢測工具，比如:靜態檢查 / SonarQube，可以幫我發現一些問題，當我從這些報告發現有一些錯誤時，就會問相關的開發人員，叫他改正。

當我在訪談下面的開發團隊時，問他們怎麼利用度量數據來幫助確保質量，他們都說不出來，只是說後面會有系統測試來做檢測，QA人員也會定期檢查來保證質量等。

以上例子2可看成是McGregor XY管理理論中的X型管理(家長式)，團隊人員是受主管指揮，而不是自己主動來利用統計數據來不斷改善。如果單靠X型管理，整個團隊的質量就侷限於主管有多少時間來檢查，而不是由團隊自發依據數據持續改進。

與一金融產品開發組長對話

 

從以上例子我們瞭解度量要與團隊過程改進配合，也需要系統支撐，下面我們看看當主管與高層已經意識到數據的重要性，也有系統支撐，如何完善研發的度量與分析：

一家專門做金融產品的公司。上層對團隊都有很明確的目標， 例如：

1. 2周：需求交付週期——從想法提出並確認，到上線的時間

2. 1周：需求開發週期——從需求設計完成到上線的時間

3. 1小時： 測試驗證時長——在集成過程中，對變更的測試驗證時長

問：你們高層有這麼高的要求， 你們究竟要度量什麼？

組長答：交付吞吐率 （單位時間內交付需求數）、交付週期、開發週期，發佈頻率、交付後線上的缺陷數，與修復缺陷所需時間，開發過程中發現的缺陷數與排除數等。（如圖）

 

 

 

 

問： 確實很多要求。但你們還度量什麼來確保可以達到以上是要求？

組長有點迷茫地望着我，然後答：我們主要就是度量這些。

度量與分析有一個很重要的概念——不應僅僅度量結果，也要度量那些會影響結果的因素。

好比如果要減肥就不能每天僅僅度量體重，還要每天收集運動量與吸收了多少卡路里。

我繼續問組長：你們團隊用什麼方法去提高交付率，也同保持質量？

答：把本來複雜的大模塊細分成小模塊，也儘量減小之間的耦合度，本來是類似瀑布性的開發，最後才集中力量測試，改成持續的迭代開發，控制每兩週發佈。

問：效果如何？

答：非常好。

他立馬在電腦展示過去六個月他們用了新方法後的結果。

雖然這組長沒有度量可控因素，但他心裏很明白以下的原理：

• 軟件越複雜，質量就越難控制

• 控制每個迭代的週期：兩週。持續交付是可以提高交付率，也保證質量。

這些最佳實踐在很多成熟的國外軟件團隊都驗證過，證明有效。

我表揚了組長的好成績後。便介紹他可以利用 GQM(goal-question-metric)來找出一些會影響結果的度量來幫我們更好控制結果。

我先沿用他已有的度量：

G: 提高交付率，也同保持質量

Q: 程序越複雜，模塊越大，越容易出問題？

M: 度量程序的複雜度、模塊的大小、耦合度，
也度量效果：交付週期，新增缺陷/關閉缺陷，線上缺陷與問題解決時長

一方面幫我們驗證一下他的假定是否正確？另一方面，如果我們發現有些模塊，複雜度高便要預警。

因這些很可能會導致後面出現質量問題。 GQM也可以系統地幫我們把要度量的可控因素與希望結果關聯。

我接着跟他分享了我們杭州案例：

我們很清楚如代碼本身不好，肯定會影響質量與交付，所以我們一開始便培訓開發團隊編程，避免一些陳舊的語法， 如 if - else, for, switch - case...。代碼儘量簡單直接。 培訓後我們便要求團隊每兩週度量有多少陳舊語句，測試發現缺陷多少？交付了多少新功能點，我們收集了六輪，陳舊語句迅速降低，交付與質量也逐步提升。

我再問組長：你估計每次變更代碼多少，是否也會跟缺陷有關？

答：很可能。

問： 你們好像也開始用靜態檢測。

答： 是的

問： 是否對提高代碼質量有幫助？

答：肯定

問： 有沒有想過也應收集這方面的數據來預測交付質量？

我便繼續與組長把所有他覺得影響也可以收集的度量列出來。

 

 

組長問：我們定了那些度量如何收集？

答：比如代碼變了多少是可以從配置管理系統收集。當我們幫企業改善度量時，常見問題是客戶沒有系統收集數據，大家可以想象，人工收集是無法長期的，也很難確保數據是否正確。 直接從系統導出可避免這些問題。因你們一直用 GIT ， JIRA 與 SonarQube，可考慮類似下圖，定期導出數據。

 

 

我接着說：你們一直強調要定期做覆盤。以前覆盤時缺少中間影響因素數據。只有結果數據。後面做覆盤分析是否會更全面？

組長答：我們過去討論時，大家都會說很多理由。但最終選擇怎麼改進還是依賴那些有經驗的人士說的算。我估計多了這些數據討論會全面多了。

我說：你們有影響因素的數據，便可以針對問題，對症下藥。比如確實某些語句的問題影響到質量。便要更新編碼指南，加強培訓等，預防後面質量出問題。

不僅僅有這個好處，你們不是也做了一些大數據分析，機器學習項目？當我們不斷收集數據，到了一定的數量便可以用這些新的方法去量化管理。 例如預測哪個模塊會缺陷較多。

度量可控因素

 

當我學軟件工程時，數據挖掘、機器學習沒有這麼流行。開發的環境工具和現在不一樣。那時候的預測模型，比如預測缺陷、預測工作量會用一些很主觀的因素，例如團隊成員經驗與能力、過程成熟度、團隊合作性，也有一些較客觀的因素，如語言、複雜度等，但如何校正模型的參數是個難題。導致模型很難可以在不同公司使用。而且那些時候大部分項目都是傳統的瀑布性開發，不一定適用於現代迭代，持續交付的開發模式。

請不要誤會，以爲上面這些因素，如經驗、能力不重要，這些都重要，只是非‘可控因素’(controllable factor)。對度量分析的預測作用不大，預測其中一個目的是希望我們可以在過程中憑一些過程中的指標，預測結果。例如,我們發現靜態檢測的缺陷數與後面發佈後的產品質量，或遺漏缺陷數相關。例如,我們發現代碼模塊大小與複雜度與後面的質量相關，就可以在開發過程中收集這些數據來預計最終的質量，不要等到發佈後才發現質量不行。

反過來，我們很難使用團隊人員經驗或能力來預測/控制結果。

除了主觀判斷以外，主因是這些因素難以在過程中改變，一旦發現人的能力和經驗達不到要求的話，你可以在團隊開發中換人嗎？估計不太可能。

所以我們更需要一些過程中的客觀、可系統收集並可控的因素來預測結果。

下面讓我們看看如何對應 上 CMMI V2.0 VV PR 3.X

 

PR 3.1分析從同行評審得到的結果和數據

Analyze results and data from peer reviews.

VV 3.2分析和溝通驗證和確認結果

Analyze and communicate verification and validation results.

從上面組長對話 與“附件1 :敏捷團隊如何有效利用度量數據分析”，大家可看到數據分析與有效溝通同等重要，可以互補，所以在V2.0 也加入溝通。

VV 3.1制定、使用並保持更新驗證和確認標準

Develop, keep updated, and use criteria for verification and validation.

當我們有歷史數據支撐，知道過程中的哪些因素會影響最終目標，我們便可以更具體規定開發過程中，無論是編碼，靜態檢查，單元測試，系統測試， 要達到什麼程度。

質量之旅

 

質量改善絕非一步到位，CMMI “創始者”已故Humphrey先生概述以下七步“質量之旅”:

1. 儘快開發出產品，測試，改錯 (Test and Fix)

2. 開始在測試前做檢查（評審）希望儘早找出缺陷並解決 (Inspect)

3. 開始使用一些數據來改善評審過程 (Partial measurement)

4. 開發工程師從參與回顧，開始意識到要預先自我評審自己的產出物，減少錯誤(Quality ownership)

5. 爲了提升，工程師開始記錄自己的引入缺陷數，排除數，產出物規模，花費時間等 (Personal measurement)

6. 工程師完善設計方法 (Design)

7. 度量+設計已降低了大量缺陷引入，再系統地避免缺陷，進一步提升質量(Defect prevention)

8. 最終應度量客戶重視的質量要素，驅動整體質量的持續改進 (User – based measurement)

我們也可以利用CMMIV2.0 判斷公司質量改善的成熟度 (V2.0 比以前V1.3版更明確), 從下面彙總表，大家可以看到公司驗證、確認、同行評審過程改善的階段：(也可以把下圖看成一張地圖，幫我們更好理解上面案例 / 例子在整個“質量之旅”中的位置)

 

 

從上面的總表，你是否覺得你認識的軟件開發公司很少處於較高成熟度？ 爲什麼？ 因公司要推行度量與分析必須：

1. 高層要有較高的交付與質量的量化要求。因要開始團隊做度量分析，開始時要有不少投入，如果沒有提升壓力，很多時候會半途而廢。

2. 培訓與系統同樣重要。單靠團隊自己摸索，或依賴人手收集數據都很難成功。

3. 溝通也非常重要：團隊必須有‘以數據說話’的文化，定期分析數據做改進。

所以當質量工程師問我，如何幫他們公司推進量化管理，我會反問她領導的主要關注點。

如果他們都覺得已經很清楚項目的情況，不需要客觀數據，無論這質量工程師如何努力都不會有什麼結果。

附件1：敏捷團隊如何有效利用度量數據分析

公司已創立了十多年，正在使用敏捷方法，但沒有使用很多度量標準來監視和優化。由於複雜性增加，團隊面臨着越來越多解答不了的問題，包括:

• 是否和十年前一樣快速高效?

• 如果不是，什麼原因可以解釋慢速度嗎?

• 如果速度確實慢了一些，那麼在質量和可持續性方面有什麼提升?

• 是否應該引入或調整一些過程來改進某些方面?

這些都是複雜問題。沒有數據就很難進行有根據和建設性的討論，也很難評估爲改善這種情況而採取的任何行動的影響。

這個案例很有趣，因爲開始時，有很多歷史數據可用。版本管理系統中的數據、問題跟蹤服務器、代碼評審平臺等。 越來越多研究如何應用數據挖掘和可視化技術，從這些知識庫收集數據，被稱作軟件分析(software analytics)。

最終目的是幫助他們發現有價值的信息。進行溝通，最後記錄並分享他們的見解。步驟:

1. 運用目標-問題-度量(GQM, Goal-Question-Metric) 方法來決定具體的分析目標，推導出一些相關的具體問題，並定義可以用什麼度量來回答這些問題。。首輪選擇的目標是：評估交付的速度是如何隨着時間演進。

2. 訪問公司軟件數據庫:版本管理系統,問題跟蹤,敏捷規劃工具和代碼評審平臺等。利用一些軟件從這些庫中提取數據,爲建立統一的模型和 可視化準備。

3. 然後，組織了一個研討會，讓團隊討論軟件和組織的演進。爲了支持這討論，我們將一些可視化結果打印在大型紙質海報上(請參見下圖），該示例顯示了跨存儲庫的團隊活動和發佈的頻率。此外，我們還配合一些交互式可視化投影。在工作坊中，參與者走進房間，看着可視化展示的數據，很自然地參與了小組討論。我們觀察了這些參與者，並記錄下討論要點。

4. 我們將在數據分析過程中獲得的事實見解和在研討會中獲得的觀點集成在交互式報告中。我們的軟件分析平臺使生產交互故事成爲可能，它結合了敘述和數據可視化。這些故事總是爲特定的讀者而寫。例子：

   1. 某人想寫一篇關於測試驅動開發價值的故事，並針對加入團隊的新開發人員

   2. CTO 想編寫一故事來支持他與管理團隊的交流

   3. 某團隊想編寫一故事來慶祝成功採用了一個新過程，以及在質量或交付時間上的好成績

 

從這個實驗的經驗教訓：

• 數據可視化和媒體的影響：在大家參與討論的工作坊中，牆上的海報起到了吸引參與者積極主動參與的鍵作用，單靠幻燈片投影絕不會達到同樣的效果。以視覺形式看到過去十年發生了什麼，對參與者來說也有情感方面的影響，引發更多多討論。

• 講故事的形式提供了有效的方式來傳達信息，有效地補充儀表板數據的不足。這兩個界面的目的不同，但它們都可以構建在相同的軟件分析平臺上。

附件2：Inspection審查

• 是一種正式評審， 目的是嚴格與正式地識別工作產品缺陷

• 詳細檢查，明確地檢測和識別缺陷

• 作者不得擔任主持人，管理者通常也不允許參加，以確保公正

• 必須正式跟蹤處理所有主要缺陷

• 系統地收集缺陷數據並存儲到檢查數據庫，對缺陷數據進行分析，以改進產品、過程和檢查過程

Inspection 包括:

• 驗證工作產品既滿足其規格要求

• 驗證工作產品是否符合適用標準

• 識別與標準和規範的偏差

• 收集工程數據(如，缺陷和工作數據)

• 不檢查風格問題

雖然它需要的投入比其他評審方法高，但它最能找出缺陷。

審查員的職責

選擇審審員:

• 識別和描述產品或產品組件中發現的主要和次要缺陷(檢查)

• 代表不同的觀點(需求、設計、開發、測試、獨立測試、項目管理、質量管理等等)

• 分配特定的評審主題以確保有效的覆蓋

• 符合特定的標準

• 整體的一致性

最低進入條件：

• 產品或產品組件完整，並符合標準

• 可用自動錯誤檢測工具

• 有支持類文檔

• 對於重新檢查，缺陷清單上的所有項目都已解決。

• 有訓練有素的主持人和足夠數量的熟練審查員

審查準備工作

審查組長必須確認審查人員是否已做好準備。如果沒有充分準備，組長可以重新安排日期;

審查缺陷列表;

記錄員負責記錄每個主要和次要的缺陷、與位置，缺陷列表上的描述和分類。作者應該準備好回答提問。如果對某個缺陷存在異議，則應在會議結束時記錄並標記爲潛在缺陷。主持人負責與團隊一起評審缺陷列表，以確保它的完整性和準確性。

反饋

 

一位總工對文章初稿的反饋：

從三年前，我們開始用靜態代碼檢查工具，確實有效果。但需要注意兩點：誤報的剔除（有些問題其實嚴格講不算問題），另外，不能爲了消除警告把原本的業務邏輯改壞，或者是修改導致性能降低。

一位很熟悉銀行業務的IT顧問反饋：

很棒，通俗易通。目前在企業中的軟件開發過程PR、VV的實施中存在如下困境，你看是否對您編輯稿件有觸發作用。

1. 評審缺乏專家，耗時較多，但評審出來的問題質量不高，較多的問題並未被發現，參評人員參與度不夠，存在部分評審過程只是走流程或形式。

2. 評審材料本身需準備較長時間，領導層、技術人員比較看重技術實現的結果，對於評審的關注度不夠，甚至認爲浪費時間。

3. 關於度量，目前過程中的數據類型很多，但前期度量規劃、分析不到位，導致數據很多，但沒有有效的彙總、分析和利用。

References

Humphrey, Watts: TSP; Leading a Development Team
Kasse, Tim: Practical insight into CMMI 2/e
Liechti, O.: Beyond dashboards: on the many facets of metrics and feedback in agile organizations