邀請團隊成員相互複查工作。複查的形式並不重要，結對程式設計（pair programming）、夥伴複查（buddy review）、同行複查（peer review）、走查（walk-through）、正式**檢查（formal code inspection）都可以。複查能夠為專案方方面面帶來好處。專案經理要為團隊提供多種方法。這些方法以特定順序介紹：從最不正式到最正式。以我的經驗來看，這也可以從最有效和易於保持的，到最沒有效果和難以維繫的。
結對程式設計。先不要假定「這裡沒人願意這麼做」，要允許大家這麼做。（而且可以提醒大家，他們已經完成過結對除錯了。）我會問大家誰自願進行結對。我建議他們在開始之前，先去閱讀一些相關資源，比如［wk02］和［sh06b］，還有
不出意外的話，會有人願意嘗試結對的。相對獨自工作來說，他們可以學到如何通過結對程式設計使工作變得更有效率。
除了減少缺陷、加快開發速度外，結對程式設計還能帶來很大的好處：有兩個人完全熟悉並知道如何處理同一塊**。而且，如果人們經常切換不同的結對物件，他們就會深入了解目前團隊正在開發的系統的各個部分。此外，對**作者的反饋也沒有延遲。
用哪種生命週期都沒有關係。結對這種技術總是可以用來讓更多人了解**。
夥伴複查。夥伴複查無法達到與結對程式設計同樣的學習效果。沒錯，每個人都可以了解產品某個功能的**，但是不會像作者那樣深入。作者得到的反饋也會有一點點延遲——即完成複查所需的時間。
同行複查。同行複查與夥伴複查的意思差不多（把你的**給別人看看），但是很多人傾向於一次複查乙個完整的模組，不管是乙個檔案還是幾個檔案。複查大量**要更難，很難找出需要進行複查的大塊時間，而且很難記住腦子裡面所有的想法。
同行複查很難達到與夥伴複查同樣的學習效果。以我的經驗來看，這樣做經常只能複查**風格，而不是內容。對於作者的反饋延遲可以長達一星期。
走查。用走查的方式，一些人會集中在乙個房間之內，由**作者說明產品，過一遍文件。這裡幾乎沒有團隊學習的過程，而作者得到反饋的延遲時間也相當長——也就是用來組織會議需要的時間。
正式檢查。如果做得好，正式檢查可以幫助團隊通過討論了解產品。不過我很少看到正式檢查能夠在組織內長久實施下去。即使是啟動檢查的人，也很難維持檢查的動力。
費根式檢查（fagan inspection）是一種在開發文件中試圖發現缺陷的結構化過程。這些文件可以包括**、需求說明、設計文件以及其他軟體開發過程涉及的文件。其命名**於麥可·費根（michael fagan）——正式軟體檢查的發明人。詳情可檢視：譯者注。
文中來自：