解讀敏捷3 - 解讀敏捷實踐之結對Review
程序員A碰到了程序員B。“Scrum糟透了”程序員A說。“為什么啊？聽說Scrum很好啊，我們公司也在準備實施Scrum。”程序員B回答。“千萬別，你們會后悔的。”“你們實施的是真正的Scrum嗎？”“當然，Scrum里面的3個角色、4個會議和3個產物我們都有啊。”
敏捷非常簡單，卻又極其困難。敏捷方法學由一系列敏捷實踐組成，而當人們實施敏捷的時候，卻急于一次性實施整個方法學。他們看重敏捷實踐簡單的形式，卻不了解或者不想花費心思了解任何一個敏捷實踐背后的內涵，從而導致沒有一個敏捷實踐能夠做到位，不能享受到對應的好處。最后卻發現投入那么大，期望那么高，收獲卻那么少。敏捷實施帶來的只是無窮無盡的傷痛，不得已只好告別敏捷。
“誰說我看不見，我只是把視力集中到一點，以改變我以往對事物的看法”——周星馳《大話西游》。讓我們把視力聚焦于單個敏捷實踐，看看能否改變以往對世界的看法。
敏捷實踐之結對Review
1. 是這樣做的
結對Review是由兩個開發人員一起進行代碼Review的方式。它發生在其中一個開發人員完成了一段代碼功能后。兩位開發人員的分工是寫代碼者和Review者。Review者通過與寫代碼者面對面的交流來完成結對Review。Review者依次向寫代碼者提出6個問題：“這段代碼完成什么功能？”“為什么要完成這個功能？”“設計思路是什么？”“符合架構思路嗎？”“符合代碼規范嗎？”“我們一起來看看代碼和你回答的前五個問題能夠對應嗎？”（不限于，還可以有安全性能等方面的問題。）
一次結對Review的時間最好不超過30分鐘，Review的代碼最好是最近1-2天的代碼。
可以簡單描述為2個人，1段代碼，6個問題，30分鐘。
2. 可用于
2.1 代碼Review
結對Review能夠有效地解決傳統代碼Review所存在的問題。傳統代碼Review存在如下問題：1）投入產出比低，檢出的問題大多是低級問題；2）效果不穩定，嚴重依賴于Review人員；3）制度化推行，可持續性差。現實中，沒有幾個軟件企業能夠做好代碼Review，因此我以前說過，這是檢驗軟件企業軟件開發能力的一個基本指標。這里的傳統代碼Review是指由代碼能力更強的人Review寫代碼人的代碼這一傳統方式。
2.1.1 投入產出比
代碼Review有3個級別，1）代碼是規范的：代碼可運行、符合編碼規范、無低級錯誤；2）代碼是正確的：正確理解需求、符合架構、設計正確；3）代碼是可維護的：業務和應用架構清晰、設計簡單、代碼可讀性好。
傳統代碼Review側重于第一個級別，兼顧二三級別，而結對Review則主要作用于第二三個級別，兼顧第一級別。傳統代碼Review在Review頻度上沒有明確的規定，要讀懂并發現二三級問題要求很高，付出的代價很大。剔除偶然因素，傳統代碼Review追求的最高目標就是所有的代碼都符合代碼規范，對促進代碼進化的幫助不大。而結對Review的目標則要高得多，能夠激發思維，促進代碼演進。
結對Review的6個問題考察了代碼實現、業務理解、設計思路、架構理解等各維度的關聯性，除了代碼規范問題外，能夠更有效的發現以前很難找出的業務理解問題和設計缺陷。并且采用雙人相互監督方式，在結對Review過程中兩個人的對話和思維碰撞，能夠活躍思維，從而更好的幫助發現關聯性問題。
結對Review能夠超越正確性，關注可讀性和簡單性，從而提升整個系統和產品的可維護性、可擴展性。在結對Review過程中，要求在短時間內把業務、設計和代碼實現說清楚。這就要求不僅僅做到代碼正確，還要做到思路清晰、代碼簡單，并且能夠有效的避免偶然性編程。
2.1.2 人員依賴
每個軟件企業都希望代碼更好。為了保證Review的效果，使用傳統代碼Review的方式嚴重依賴于代碼能力更強的人員來Review代碼能力更弱人員的代碼。這種方式有極大的副作用。1）代碼能力強的人的時間被大量占用，以至于他們沒有時間去完成他們的工作；2）這甚至會引起權力爭奪，誰有資格誰沒有資格是代碼能力是否得到公司認可的評判標準。如果人們熱衷于去鉆營代碼Review資格，就會大大增加公司的內耗和影響到整個公司開發人員技術能力的提升。
結對Review則不是這樣，它對人員沒有多少業務技術上的依賴。事實上在結對Review過程中，代碼問題往往是寫代碼的人自己找出來的，參見《從小工到專家》中的“橡皮鴨”。第一次看到這一點的時候不會相信，這有點違反直覺。實際上，大多數高級別問題都是關聯性問題，而人的注意力是有限的，在寫代碼時常出現關聯性遺漏。結對Review的6個問題考察的重點就在關聯上，往往是Review的人還沒有反應過來，寫代碼的人都發現了。
當然，結對Review對人員有性格和其他方面的依賴。如果總是批評，或者寫代碼的人不愿意向他人展露自己的理解和設計思路，這時候就會故意找茬，引起爭吵。
2.1.3 可持續性
傳統代碼Review依據的是傳統的管理理念，正確的事情就應該做，應該做的事情就變成制度逼著做，制度帶來的就是抵觸和陽奉陰違。這就是中國最愛的運動式管理。領導重視了，就好一些，領導不重視了，就基本無效了。時間都在運動中過去了，企業卻還是一年又一年的原地踏步。
結對Review一開始就考慮了可持續性。結對Review的成本隨著熟練度會持續降低，到了后期，每天15分鐘足矣。而它帶來的收獲卻是可以持續的，基本每次都可以發現一些問題，而且還有其他的收獲，參見下面的個人學習、團隊建設。相比枯燥的代碼，與人進行交流有趣多了，還可以開開玩笑什么的。有趣又有收獲的事情，又不累人，可以經常做，甚至可以成為習慣。
2.2 個人學習
學習是軟件開發人員必備的能力，然而學習卻是個問題，參見《為未來學習》系列。新人面對的問題人稱“種蘑菇”，很多老人都面臨增長極限的問題。
2.2.1 新人
有一種新人培養方式叫“種蘑菇”。參見蘑菇管理定律：“蘑菇管理”是許多組織對待初出茅廬者的一種管理心態，初學者被置于陰暗的角落（不受重視的部門，或打雜跑腿的工作），澆上一頭大糞（無端的批評、指責、代人受過），任其自生自滅（得不到必要的指導和提攜）。——互動百科
還有種新人培養方式是“導師制”。新人入職后指定一位導師，負責指導新人。而導師無法面面俱到的滿足新人的要求，企業也缺乏足夠多的優秀導師。
還有種脫產式新人培訓，3-6個月給新人集中培訓。這種培訓模式成本超高，大多數小企業均無法承擔。
結對Review是一種工作中培訓的有效方式，可以和上述3種方式形成有效的補充。
那些表現優秀的新人天生就會結對。他們知道自己的代碼有很大的提升空間，他們會主動向團隊中的其他人請教，你會經常看到他們參與討論，積極請教，他們成長的很快。然而中國人比較被動，也有很多新人還不會結對，他們的成長可能不如預期。所以新人為了自己的成長，企業為了新人的成長，有必要推廣結對Review。
結對Review為新人提供了更好的環境，讓新人可以得到更多的指導。新人可以通過參加結對Review了解到更多的業務、架構、設計、代碼等方面的知識，并且因為是實戰代碼，比培訓的效果強很多。新人寫的代碼可以被結對Review，在Review的過程中發現各種各樣的問題，接受各種各樣的指導，從而既可以提升代碼質量，也可以學到更多。
2.2.2 老人
軟件企業中的老人面對的問題是增長極限。經過3-5年的工作，很多人都到了極限，無法從日常的工作中得到更多的收獲。而公司內高端的崗位就那么多，也無法讓每一個人隨意的做實驗，雖然提拔實驗的方式在軟件行業很普遍。
結對Review可以給老人鍛煉的機會，讓他們能夠從日常的工作中得到更多的收獲。
當老人Review新人的代碼時，他們要學會如何提問，如何從信息中挖掘更深層次的內容，同時還不能讓新人覺得難受。結對Review讓老人學會如何鼓勵他人，如何與他人溝通。
當老人的代碼被新人Review的時候，他們要學會如何簡明扼要的說明重點，如何用簡單的方式說明復雜的問題，這將有效的幫助老人們沉淀總結自己的知識技能。
當老人間相互Review的時候，他們要學會如何PK，如何把話題控制在一定范圍內，如何妥協和達成一致，如何更有效的說服別人。
上述的溝通能力、影響力、沖突解決能力和問題解決能力是每一位高端人才必備的能力，但很多人沒有在工作中刻意的培養這些對自己未來發展至關重要的技能。
2.2.3 學習
每個人都想成為終身學習者。能夠在任何環境下都比別人優秀，都能脫穎而出，想想都讓人激動。然而大多數人都放棄了，因為工作的目的是結果，所以他們不得不一天又一天的重復使用自己以前學到的經驗和技能。
結對Review讓工作和學習有效的結合在一起，一方面在同樣時間投入的情況下可以拿到更好的結果，另一方面可以滿足終身學習的期望。
通過結對Review，可以學習知識。無論是新人還是老人，你都可以通過更多人的眼睛看世界，了解到很多業務和技術知識，新人可以快速成長，老人可以避免自己的知識結構變得陳舊過時。
通過結對Review，可以掌握技能。例如設計模式，關鍵不在于設計模式是什么，這種知識可以通過書本學習。在結對Review過程中可以了解到別人關于設計模式的很多思考，了解設計模式在什么情況下適合使用，在什么情況下不適合使用，發現和應用設計模式解決現實中的問題。這種實戰鍛煉是掌握技能的最好方式。
通過結對Review可以鍛煉能力。溝通能力、影響力、沖突解決和應變能力等等都可以通過結對Review進行提升，而很多人都在抱怨平時沒有機會進行這些能力的鍛煉。
通過結對Review可以學習如何學習，養成學習習慣。很難找到能與結對Review比美的學習方式，它簡單、安全、有效、可持續。它簡單，因為只需要找到一個愿意和你談30分鐘的人就可以開始。它安全，你們在找出代碼哪些地方可以提升，不會讓你在大庭廣眾下丟臉，不會影響你的考評。它有效，能夠快速的得到有效的反饋。它可持續，這是一個可以使用一輩子的技能，可以在任何公司使用。
2.3 團隊建設
我們都知道，團隊和一群人是不同的。每個人都期望為一個團隊工作，在這個團隊中人們不僅僅為了完成任務而走在一起，他們是為創造出超越期望的產品，工作有趣而且充滿挑戰，每個人都能感受到尊重和信任，團隊充滿友善的氛圍，每個人都有成長。然而遺憾的是，這樣的團隊可遇不可求。敏捷就試圖向大家描述這樣一種情景，很多人都信了，然而在試驗后他們發現自己做不到。最后的結論是，敏捷對人要求太高了，只有足夠優秀的人才能玩轉敏捷。
其實真正的原因是我們不知道怎么去建設這樣一支團隊，我們不知道如何達成我們的夢想。結對Review可以幫助我們嗎？
軟件開發團隊的關鍵在于協作，而不在于分工。結對Review是兩個人使用的最基礎的協作方式。
2.3.1 暴露團隊問題
在大多數軟件項目中，人與人之間不交流，甚至有點矛盾也只是小問題而已，只要他們能夠完成分配給他們的工作，畢竟軟件開發人員是內向、不善交流并且很難管理的，同時傳統的管理方式更強調分工而不是協作。然而那些我們忽略的最后會傷害我們，從軟件開發中的Bug類型就可以得出結論，70%以上的問題來自于需求誤解、遺漏等問題，而這些問題是可能通過溝通協作解決的。
結對Review強制兩人坐在一起交流，如果他們不能很好的溝通協作，立刻就會暴露出來。提前解決協作問題既可以鍛煉團隊的沖突解決能力，還為未來的工作消除了一個隱患。
2.3.2 團隊氛圍
一個良好的團隊自然有良好的團隊氛圍，但這種氛圍是如何形成的呢？
有一種方式叫“破冰”。破冰是一種讓團隊成員快速相互熟悉的有效手段，不過控制不好就會“又黃又暴力”，會超出有些人的承受底線，反而破壞了團隊的形成。并且因為破冰的內容大多與工作無關，所以人們在工作中能否像工作外一樣很好的合作，還是個未知數。
結對Review是一種融入到工作中的、溫柔的團隊氛圍建設方式。從兩個人開始，在結對Review的過程中，被Review的人需要打開心扉，坦誠自己的思考，Review的人需要努力思索，通過提問激發更多的靈感，雙方共同發現問題，解決問題，并共享Review帶來的小小成就。相互間感恩、尊重、開放透明的團隊氛圍隨著工作中的小細節逐漸開始形成，而這種團隊氛圍通過長期結對Review小心的呵護和培養逐漸成型。
當然，破壞永遠比建設容易。即使結對Review有用，好不容易建起的團隊氛圍也可以被其他措施在幾天內破壞殆盡。
2.3.3 補位備份
主動補位是一種強大的團隊能力，讓團隊能夠從容的面對病事假等多種人員減員意外。但要做到被動補位都很難，可能是由于人們相互間不熟悉對方的工作，也可能是人員積極性不夠，還可能是人員的能力不夠。通過結對Review，上述的3個問題都不是問題，補位的基本難題解決了。
很多公司都有強制的備份措施，其含義就是有人離職了公司不會受到損失。這種措施往往會受到有意無意的抵制，通常是形同虛設。而通過結對Review形成的網狀備份關系則是一種更加先進的備份關系，其建設并不需要額外的強調和努力。
2.3.4 團隊行為規范
每一個優秀的團隊都有自己的默契和行為規范，這些行為規范不是寫在紙上的制度，而是被團隊成員驕傲的宣稱，這就是我們的做事方式。這種行為規范需要長時間緊密的配合才能形成。結對Review就是緊密配合的一種典型形式，它能夠促進團隊統一認識，相對快速的形成團隊行為規范。
“你這種代碼看起來怪怪的，和我們以前的風格不一樣啊。你看，應該這么寫。”“這個業務不是這么理解的。”“這種方法太棒了。”上述的話語通過結對Review在團隊中快速傳播，從而形成執行中的代碼規范。
2.4 組織轉型
很多企業對現狀并不滿意，期望改變。然而企業往往發現，他們自身被自己長期以來形成的組織文化所綁架，所謂的轉型困難重重，能做到的無非是換一換領導，改一改流程，并不能影響到企業內大多數人的行為。
前一段時間做了一個小統計，開發人員的時間都用到哪里去了？發現一個開發人員只用了1/3-1/5的時間寫代碼，其工作有一半以上的時間在申請權限、了解需求的細節、各種各樣的會議、等待測試結果、等待上線、翻查日志等工作中。他們的工作可以優化、效率可以提升嗎？從他們自己那里得到的答案是肯定的，然而企業的領導可能卻無法看見這一切。
結對Review不一定有這么大的效果，它每次只能改變一個人的工作成效和兩個人的合作關系，但我堅信，微觀的優化最后一定會反映到宏觀上。如果任意一個人的工作有做得更好，任意兩個人之間的關系都有改善，整個企業一定會被影響改變。
2.4.1 企業文化/價值觀/復雜系統
具備一定自組織特征的個體以簡單的方式組成的關系網絡往往都是復雜系統，企業就是這樣一種典型的復雜系統。而改變復雜系統有一種簡單的方式，改變這些個體之間的互動關系。常見的組織轉型方式包括組織重構、流程制度轉變，這些方式的根本都在于改變了人與人的互動關系。
結對Review改變了軟件開發人員間的互動關系，當推廣到整個組織，其帶來的涌現效應能夠改變整個組織。
企業文化/價值觀就是這種涌現的樣例。企業文化是一個企業表現出來的，內部員工的做事方式和行為規范，是企業內部所有人共同遵循的價值觀。
最近聽到比較多的“開放、透明、分享、責任”，這些價值觀相信在很多企業的企業文化中都或多或少有提到。如果一個企業本身的管理方式就是建立在信息不對稱、從上至下的基礎上，這種控制式管理方式本身就與上述企業文化違背，最終企業文化要么掛在墻上，要么四不像。
結對Review能夠從微觀上為企業文化打下基礎。被Review的人在結對Review的過程中必須向Review的人開放和透明，講述他自己在這段代碼開發過程中的思考和理解。他們分享他們對業務和技術的理解和認識，共同承擔軟件開發的結果。當結對Review成為習慣，開發人員相互間的信任建立，人們做到更加“開放、透明、分享、責任”，這一切為企業文化打下了很好的基礎，幫助了企業文化落地。
2.4.2 知識管理/學習型組織/社交網絡
企業中的知識管理是指企業針對個人及社群所擁有的顯性知識和隱性知識的確認、創造、掌握、使用、分享及傳播進行積極及有效的管理。彼得圣吉的《第五項修煉》讓學習型組織廣為人知，學習型組織是指企業通過組織學習實現員工知識更新和保持企業創新能力。
不過大多數企業都是心有余而力不足。企業中的知識管理就是形成了一個有一個文檔庫，成立培訓機構和組織了大量的培訓。然而落到微觀層次，員工的成長是否符合預期？是否涌現了足夠多的人才？
知識管理的一個關鍵是知識的流動。當前我們處于知識極大豐富的時代，迷失在知識的海洋是一件很正常的事情。在這種時候，知識的受控有序流動，知識的應用才是知識管理的關鍵。
結對Review在理論上可以成為企業中任意兩個人之間顯性知識和隱性知識流動的途徑。如果我們把企業看做兩兩間關系構成的社交網絡，那么通過定義兩個人之間知識流動的方式，與工作密切相關的知識在企業中流動起來。君不見，通過兩兩間互粉的關系，信息在微博上的流動速度。
還有一種戰術，稱為“信息轟炸戰術”。就是利用頻繁的結對Review，形成以工作為中心的信息彌漫的氛圍，利用員工的潛意識思考時間，說不定有什么好主意從此誕生。
3. 與……相關
3.1 變形
結對Review雖然在描述上是兩人，人員可以增加。例如增加到2-3個人Review一個人的代碼，其中一個人作為主要提問者，另外1-2個人作為附屬提問者。
在形式基本保持不變的情況下，結對Review有多種變形方式。
3.1.1 時間上變形
結對編程：結對Review可以看做編程的后續，向前移動就變成了結對編程。結對Review與XP中的結對編程很像，那是不是應該稱為結對編程呢？不然，在極限編程的維基百科中，結對編程都已經被改稱為結對程序設計了。結對編程那苛刻的實現條件讓人望而生畏，并且不能得到管理層有效的支持。結對Review能夠得到開發人員的認可和管理層的支持，可以為結對編程打下基礎，未來可以在關鍵代碼編寫時部分采用結對編程。
結對設計（敏捷建模）：將結對Review移動到程序編寫之前，就成為了結對設計，甚至是敏捷建模。可以用于關鍵代碼設計，用戶故事設計思路Review。
3.1.2 角色上變形
結對Review可以用于測試與測試之間的測試用例Review，開發與測試之間的用戶故事設計思路、代碼或者測試用例Review，開發測試PO之間的用戶故事Review等等。
3.1.3 內容上變形
結對郵件Review：通常見于外企，多數開發同學缺乏與外國人溝通的英語能力和溝通技巧，結對郵件Review能夠讓你發出有效的郵件并能快速掌握寫好郵件的能力。在第一個外企工作時，我的一個經理每次都和我一起Review發給外國人的郵件，讓我快速掌握了英語郵件的基本能力，非常感謝她。
還有結對方案Review，結對計劃Review，結對總結Review，結對PPTReview等等無數多種變形。
3.2 有助于何種敏捷實踐
在結對Review得以推行后，會對下述的敏捷實踐執行有幫助。
簡單設計（XP）：結對Review有助于簡單設計實踐的推行。什么樣的設計能夠稱得上簡單設計？能夠在短時間內陳述清楚，并達成一致的設計方案很難變得很復雜。并且結對Review可以讓代碼變得更簡單，具有更好的可讀性和可維護性。
代碼標準（XP）：幾乎所有的軟件企業都有代碼規范，放在文檔里的。然而代碼規范只能在一定程度上防止代碼變得更爛。符合代碼規范的并不一定是好代碼，代碼規范只是表明，我們企業受過傷了，我們的代碼不能比代碼規范里面的更爛。結對Review有助于形成執行中的代碼標準，并能夠保證持續的對代碼進行優化，從而可能不斷提升代碼標準。
敏捷建模：在結對Review養成的開放的討論分享習慣非常有助于推行敏捷建模。
3.3 受益于何種敏捷實踐
如果已經執行了下述的敏捷實踐，可以幫助實施結對Review。
每日立會：在每日立會上關注結對Review，是一種有效的推行結對Review的方法。
回顧會議：回顧會議能夠讓團隊更容易達成對結對Review的一致認識，從而有助于推行結對Review。
完整團隊：團隊中的成員不能像資源一樣隨意變動，這會阻礙結對Review的前期推廣效果，完整團隊實踐能夠提供一些幫助。
3.4 采用了何種敏捷方法
從上面的變形就可以看出，結對編程、結對設計、結對Review，結對才是關鍵。從這里我們總結出了一種基本的敏捷方法，結對。看來所謂的敏捷實踐，也許就是幾種敏捷方法應用于軟件開發實踐的結果。而這些敏捷方法也可以應用于非軟件開發領域。
到底存在哪些敏捷方法？如何應用這些敏捷方法？理解敏捷方法是不是更能了解敏捷的本質呢？期待后面有機會來分享一下這方面的認識。
3.5 與敏捷價值觀的關系
參見《敏捷價值觀》和Scrum與XP中的價值觀，在此就不復述了。
這篇文章實在是太長了，請參見上面結對Review與企業文化/價值觀之間的關系。
3.6 應用了何種敏捷理論
復雜系統：敏捷中的自組織、涌現等很多概念和提法都來自于復雜系統理論。現代的學習型組織/知識管理和企業管理理論很多也與復雜系統理論相關。供希望更深入鉆研的同學參考。
4. 實施方法和案例
請參見以前寫的《結對Review》系列文章，考慮在后面推出更完整的敏捷實施方法論和案例。
5. 后記
完全沒有想到這篇文章會寫的這么長，這么累。其實我的本意是想給今年一直在做的結對Review實踐進行一次總結，完整收尾。不多說了，后面還想對相關的敏捷實踐都進行類似的剖析，并以之為依據展開對敏捷的理解和認識，討論敏捷實施方法論和描述一些案例。現在看起來，上述目標完全就是一本書，就把寫這本書作為2012的目標之一吧。祝所有的讀者新年快樂！
PS：在未做特殊說明的情況下，本文的大多數名詞解釋均來自維基百科。
