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