同行評審阻礙或促進敏捷開發

喂，你。現在。

當代碼或文件需要評審時，經常會出現這樣的情況。因為一些原因，你的工作需要評審。首先，同行可能提供有價值的反饋，他們可以帶來新的視角，發現你在數小時的工作後可能沒有覺察的錯誤。其次，在快節奏的敏捷團隊中，你需要不斷地凝聚共識，這樣就不會積壓待溝通事項。最後，對於高度監管行業的團隊，同行評審可能是更大的軟體保證計劃的一個必要部分。

隨著越來越多的軟件開發團隊趨向于敏捷方法，軟體釋出變得越來越頻繁。如果你不能同步加速同行評審週期，那麼你可能會爲了在規定的時間內完成工作而開始犧牲質量。然後，那會轉換成技術債務的累積。如何避免這種情況呢？需要結構化，不過是靈活的結構。

結構化迭代溝通

大多數團隊都沒有一個明確的內部溝通計劃。他們採用的工具通常沒有定義溝通規範。如果你的團隊採用了Slack或其他的通訊應用，那麼很快，短暫的即時聊天就會變得很普遍。期望是另外一個人會在一個相對比較短的時間內回覆。如果你給同一個人傳送一封電子郵件，那麼他可能更長的時間纔會回覆。因為對於工具的固有期望，這是可以接受的。

就像團隊會慎重他們應該使用什麼庫管理工具或效能測試工具一樣，他們也應該考慮使用什麼工具進行同行評審最合適，以及那些工具對他們的行為會產生什麼影響。

例如，如果我的團隊的程式碼評審流程只是GitHub上的一系列Pull Request，那麼我們能夠推動集中式流程的改進嗎？如果我的團隊是通過傳送電子郵件附件來進行文件評審，那麼我們能指望長期的開發可追溯性嗎？這些問題可能是你想問的，但重要的是，在問之前，頭腦中要有一個可以作為最終目標的實實在在的願景。

結構化同行評審流程的三個屬性

每個評審流程都有類似的基本過程。有編碼人員編寫了新程式碼或現有程式碼的變更。然後，評審人員參與進來，評論並找出缺陷。接下來，編碼人員修復Bug，評審人員驗證修復後的Bug。有幾種常見的流程變體（提交前、提交後等）和常見的方法（臨時、基於會議、基於工具），但是，有關那些主題的詳細資訊是另外一篇博文的內容。

不管你有什麼獨特的喜好，一個理想的結構化敏捷開發評審流程都有三個關鍵的屬性。

1.它應該明確預期和規則。

當有人要求針對他們的程式碼進行反饋時，他們到底是在要求什麼？是要求人們說明你的偏好以及你可以如何採用不同的做法？如果我們不只是要求獲得「反饋」，那麼我們就可以更快獲得更好的反饋。一個結構化的同行評審流程要求評審者檢視並評估x、y、z的質量。你的團隊或相關的編碼人員可以決定那些檢查項是什麼。

檢查項可以包括來自執行單元測試和侵入測試的任何東西，以便可以檢查是否符合編碼標準，是否新增了恰當的註釋。開始的時候，會有一個團隊在大多數情況下都已經在做的基本檢查項清單，但是可能偶爾會有疏漏。隨著不同的評審型別出現，你可以相應地增加和調整。

通過建立清單和清楚說明同行評審流程，每個人都可以知道誰評審以及評審人員做了什麼。它還減少了評審範圍蔓延。如果評審者什麼都評論，那麼他們可能會針對某個東西提出一個公認的複雜問題，那會讓你洩氣。

由於同行評審流程最終應該發揮質量度量的作用，所以你的流程應該有規則，而且那些規則應該是可執行的。制定一份指導原則，說明誰參與哪種型別的評審。如果你推出了一項新特性，並希望它可以正常工作，就需要一定數量經驗豐富的開發人員參與到評審中。如果你希望把程式碼評審作為培訓策略，那麼就需要新成員參與一定數量的評審，作為他們入職的一項內容。如果沒有定義好的規則，就沒有什麼能阻止團隊成員胡亂提問題或不提問題。

2.它應該能夠促成多對多的透明化評審。

敏捷運動受到歡迎，這部分是因為筒倉開發會導致不必要的溝通壓力。就像那些現在更大程度上跨職能的團隊，部門應該開放他們的流程，那樣，整個組織的軟件開發就可以有一個清晰的跟蹤審計。在製造業，這個概念被稱為數字主線。

爲了在團隊層面和組織層面實現流程改進，你需要不斷彙總分析關鍵績效指標（KPI）。只有團隊使用的工具有跨團隊、跨部門資料互動時，你才能收集到這種資料。這種互動可以實現明顯更好的缺陷跟蹤。

收集資料只是完成了一半挑戰。爲了進行有意義的分析，選擇對於你的團隊而言最有意義的自定義KPI，並長期對它們進行追蹤。用於評審流程的工具應該支援此類分析和自定義報表。

除了有意識的改進流程外，透明化還能促進協作。如果軟體架構師在應對一項設計挑戰時做了會影響測試的修改，那麼團隊的測試人員應該能夠訪問最初的同行評審，看看修改意圖。意圖分析，尤其是通過文字媒介，會給整個軟件開發帶來多重風險。那是個高風險的電話遊戲。當團隊和職能部門共享資訊時，他們更容易直接獲得答案，無障礙協作。

3.它應該使用自動化系統和模板代替通常的人工設定。

SmartBear的 2017程式碼評審現狀報告 顯示，57%的開發團隊會進行基於會議的同行程式碼評審。將近75%的團隊會進行「過肩」即時評審。雖然這些方法可能會有效，但它們要麼需要手工文件，要麼完全不記錄。結構化同行評審流程的目標應該是儘可能減少這種手工帳。

採用基於工具的方法進行同行評審可以自動化許多設定和文件。像SmartBear提供的工具 Collaborator 就使團隊可以建立評審模板，自動通知，生成自定義報表。這些特性可以大幅減少同行評審流程的阻力。

雖然本文的重點是結構化流程，但是，我們要重點說一下， 敏捷宣言 中有一條重要的原則似乎和這個觀點相悖，「個體和互動勝過過程和工具」。通過模板化同行評審流程，你可以把大量的流程工作放在開發過程的後臺進行。開發人員很清楚檢查清單，不需要為每次評審都從頭建立一個。管理人員可以自定義和優化評審過程，不需要不斷督促團隊成員改變他們的行為。自定義並自動化同行評審流程使個人可以有更多的時間交流和構建。

進展跟蹤

過多的資料或資訊可能會成為負擔。正如前面提到的那樣，如果你的團隊能夠識別出幾個有意義、容易跟蹤的指標，那麼你就可以成功地改進流程。小團隊可能會希望設定一個自定義的滿意度指標，如贊同/不贊同或分為1到5級。如果管理著看到了一種趨勢，他們就可以定性地研究問題。

對於使用結對程式設計方法的團隊，像缺陷密度這樣的程式碼評審指標可以作為開發悟性的客觀代表。既然大多數團隊都知道誰是最頂級的編碼人員，那麼使用一個指標作為真相來源可以減少偏好或認識疏忽導致的問題。通過跟蹤每位編碼人員程式碼中的缺陷密度，你可以把高效的開發人員和缺陷率較高的同行結對，從而提升團隊整體技能。另外，考慮下如何把它用在回顧過程中。你可以輕鬆識別出一次衝刺中進步最大的編碼人員或最優秀的編碼人員。

對於比較大的開發團隊，像評審過的程式碼行數（LOC）和評審耗時這樣的指標可以提供評審流程的更高階檢視。例如，如果評審過的LOC數量非常高，而缺陷密度非常低，則說明你們的編碼人員都是全明星，或者你們的評審人員評審得太粗太快。獲得所有這些指標後，你就可以檢查個人或團隊花在評審上的時間，並做出改進。

引入行業基準，更好地瞭解這些指標的實際意義。例如，根據SmartBear和思科開展的一項 調查 ，在一個小時內評審的理想LOC數量大約是500。這種行業基準可能並不完全適合你的團隊，因此，隨著時間推移，開發自己的內部基準。把團隊當前的效率和行業基準以及本團隊的歷史評審數相比較，團隊負責人可以更好地評估例外情況。

你的同行評審流程反映出團隊的什麼狀況

我前面提到過，像電子郵件、即時通訊應用這樣，不同工具的特點不一樣，它們對使用者行為和預期的影響也不一樣。這也適用於團隊的同行評審流程。如果你的流程具有嚴密的結構，那麼，在某種程度上，你的團隊就會採用你強調的行為。

那不是說每個開發人員都會立馬成為程式碼評審的聖徒或者所有的評審總是會有恰當的記錄。而是說，你的團隊有機會建立溝通預期，提出明確的質量值，促成跨團隊協作，推動開發。在完工定義框架中引入程式碼和文件評審的敏捷團隊能夠確保每個人都瞭解每一個作為更大使用者故事和專案組成部分的工件。

使用同行評審交流這些資訊的特別之處在於，評審是一個活生生的過程。從一次衝刺到下一次衝刺，每位編碼人員和評審人員都面對著這些檢查清單和規則。作為敏捷團隊，你自然會反覆調整，直到它們符合團隊的獨特需求和偏好。然後，你建立自己的生存宣言，反覆重申優先事項和價值，直到它們嵌入到團隊文化和程式碼中。

關於作者

Patrick Londa 是SmartBear軟體公司Collaborator數字營銷經理。他有在Clean科技公司及數字健康領域培育敏捷創業公司的背景，現在專注於軟體質量、流程追溯和同行評審系統，面向的是高度監管、影響大的公司。

檢視英文原文： Peer Reviews Either Sandbag or Propel Agile Development