敏捷開發「鬆結對編程」實踐之二：計劃與設計篇

本文是「鬆結對編程」系列的第二篇。

新人其實不多偷懶，由於一方面正處於入門學習的高峯期，另外一方面工做時間不長鬚要獲得企業和團隊的承認。可爲什麼他們工做老是不得力呢？

新人的真正問題在於無意辦錯事和好心辦錯事。

無意辦錯事包括沒學過某種好的方法、不知道企業已經有某些可用代碼或庫、不懂業務等種種問題。

好心辦錯事包括想作一個比領導想一想的更好的功能、過分思考了可複用性可維護性等。

這兩個問題筆者都經歷過（做爲新人和老人），「避免」是最好的方法，而不是過後改正，這就須要在設計階段和計劃階段從技術、管理兩個方面來提早預防。

--------------------------

技術：輕量級設計

若是要把一個任務分配給一個「不放心的人」，有兩種辦法保證成功：師傅把設計作出來交給徒弟作，可是「設計文檔」的詳細程度很難把握，寫少了作不出來，寫多了等作出來了不少內容又多餘了；師傅徒弟結對編程，可是很佔用師傅的時間，尤爲是假若徒弟「實際上」（惋惜只有上帝知道）徹底能夠勝任這個任務。

有兩種解決方法。

1. 事前輕量級設計：預想陳述（有點隱喻的意思）

預想陳述是微軟好久之前就使用的一種方法，任何人（不僅是徒弟）有什麼設計，不用寫下來由於太費時間了並且還可能被拋棄，而是給你們講一下。你們會給出評價和意見，以保證其正確性。而後此人就按這種方法去實現了，假若成功了也被承認了，就簡單寫下來以供往後參考使用。因爲系統已經存在，這個簡單寫下來的設計能夠真的很簡單。

在「鬆結對編程」裏邊，有兩種相似的作法。

一種是師傅把本身的想法告訴徒弟（通常用一個白板，或一張白紙），徒弟提問師傅回答，到差很少爲止。

二種相反，徒弟講給師傅聽，師傅師傅質疑和指導，到差很少爲止。

二者都不要事先造成永久文檔，但都在被證實可行（就是編碼完成後）寫一個簡單文檔記錄。任何代碼以外的能幫助理解當時作法的文字/圖片均可以稱爲文檔，沒有字數限制。若是能和用戶故事放在一塊兒則更好，一個描述作了什麼，一個描述怎麼作的。

2. 前檢查點

就是在某事開始的時候進行臨時結對編程。通常發生在某個功能剛開始作的時候，詳情會在以後的「平常活動篇」作詳細描述。

管理：共同計劃（共同估算，撲克牌估算）

預想陳述、前檢查點雖然已經很輕量級了，可是若是師傅和徒弟都剛剛對需求（用戶故事）有所瞭解，還給不出很清晰的思路的時候，好比在Scrum計劃會上，怎樣快速知道徒弟有沒有理解需求，有沒有大體的實現思路呢？那就是共同估算（撲克牌估算是共同估算的一種最好的實現形式）。

1. 共同估算

共同估算的原理和作法仍是很複雜的，這裏只簡單說說，之後會有文章詳細講述。

共同估算就是師傅和徒弟基於相同的信息（通常是在計劃會上聽PO講完故事的時候），一塊兒說出本身認爲作完這件事情須要多久。基本原理是：若兩我的對某件事情的工期認識是相同的，那麼他們的實現方法不分高下，用哪一種方法都差很少。

爲了防止人云亦云，通常須要採用匿名方法，而撲克牌估算就實現了高效有效的共同匿名估算（另有文章詳述）。

2. 驗收標準

爲了基於相同的目標創建共同估算，也爲了防止需求鍍金或最終軟件不能知足需求，師傅和徒弟要創建對需求的共同理解。

簡單方法就是二者（實際上是師傅和多個徒弟）一塊兒參加估算會，一塊兒聽PO講解故事。但最好是在此以後，創建一個「文檔化」的驗收標準。好比在一張故事卡/Excel表裏……上寫上「需集成；無性能要求……」等最簡單的描述（請參考本博客的敏捷開發分類下一片關於驗收標準的文章）。

共同估算+驗收標準，使得師傅和徒弟（推廣爲高手和新手）使用大體相同的方法，作大體相同的東西。共同估算既是一個工做的過程，也是一個學習的過程，由於在理解作什麼和怎麼作的同時，徒弟也向師傅學到了東西。

--------------------------------------------

這裏描述的基本上都是前期工做方式，基於莫非定理（只要事情能出錯，就必定會出錯）只在事前預防仍是不夠的，在平常工做中仍須要師傅與徒弟進行配合工做，具體細節將另有文章描述。