敏捷開發“松結對編程”實踐之二：計劃與設計篇

本文是“松結對編程”系列的第二篇。

新人其實很少偷懶，因為一方面正處于入門學習的高峰期，另一方面工作時間不長需要得到企業和團隊的認可。可為何他們工作總是不得力呢？

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

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

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

這兩個問題筆者都經歷過（作為新人和老人），“避免”是最好的方法，而不是事后改正，這就需要在設計階段和計劃階段從技術、管理兩個方面來提前預防。

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

技術：輕量級設計

如果要把一個任務分配給一個“不放心的人”，有兩種辦法保證成功：師傅把設計做出來交給徒弟做，但是“設計文檔”的詳細程度很難把握，寫少了做不出來，寫多了等做出來了很多內容又多余了；師傅徒弟結對編程，但是很占用師傅的時間，尤其是倘若徒弟“實際上”（可惜只有上帝知道）完全可以勝任這個任務。

有兩種解決方法。

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

預想陳述是微軟很久以前就使用的一種方法，任何人（不只是徒弟）有什么設計，不用寫下來因為太費時間了而且還可能被拋棄，而是給大家講一下。大家會給出評價和意見，以保證其正確性。然后此人就按這種方法去實現了，倘若成功了也被認可了，就簡單寫下來以供日后參考使用。由于系統已經存在，這個簡單寫下來的設計可以真的很簡單。

在“松結對編程”里邊，有兩種類似的做法。

一種是師傅把自己的想法告訴徒弟（一般用一個白板，或一張白紙），徒弟提問師傅回答，到差不多為止。

二種相反，徒弟講給師傅聽，師傅師傅質疑和指導，到差不多為止。

兩者都不要事先形成永久文檔，但都在被證明可行（就是編碼完成后）寫一個簡單文檔記錄。任何代碼之外的能幫助理解當時做法的文字/圖片都可以稱為文檔，沒有字數限制。如果能和用戶故事放在一起則更好，一個描述做了什么，一個描述怎么做的。

2. 前檢查點

就是在某事開始的時候進行臨時結對編程。一般發生在某個功能剛開始做的時候，詳情會在之后的“日常活動篇”做詳細描述。

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

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

1. 共同估算

共同估算的原理和做法還是很復雜的，這里只簡單說說，以后會有文章詳細講述。

共同估算就是師傅和徒弟基于相同的信息（一般是在計劃會上聽PO講完故事的時候），一起說出自己認為做完這件事情需要多久。基本原理是：若兩個人對某件事情的工期認識是相同的，那么他們的實現方法不分高下，用哪種方法都差不多。

為了防止人云亦云，一般需要采用匿名方法，而撲克牌估算就實現了高效有效的共同匿名估算（另有文章詳述）。

2. 驗收標準

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

簡單方法就是兩者（其實是師傅和多個徒弟）一起參加估算會，一起聽PO講解故事。但最好是在此之后，建立一個“文檔化”的驗收標準。比如在一張故事卡/Excel表里……上寫上“需集成；無性能要求……”等最簡單的描述（請參考本博客的敏捷開發分類下一片關于驗收標準的文章）。

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

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

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