敏捷開發「鬆結對編程」實踐之四：平常工做篇

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

團隊中常見的一種狀況計劃、估算、設計的時候你們還在一塊兒，但編程的時候就會分開。分開看似是安全的，可是卻充滿隱患。

2001年，一位招聘考試前三名（一共120員工）的程序員的兩個月的成果被完全放棄重寫，緣由是裏邊包含3000多個常數，並且很難修改（碼流參數），重寫的人座位距離他只有4米，重寫也只花費了2周；2002年，一位月薪7000（那時候北京房價才3000多）的程序員編寫了一個月的4000多行代碼，在一個下午被重寫爲50多行，座位距離他只有5米的項目經理疑惑加驚訝地問：「你真的沒學過c++ template？」。

這就是團隊的距離，即便是高薪聘請來的程序員也不免犯錯。難道咱們只能避免下一次問題發生，而不能避免此次問題發生？

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

前檢查點

前檢查點就是在作某功能的最初一段時間，師傅與徒弟結對編程，完成最初最重要的設計。

「開始作X功能的時候叫我一聲，我們敲定一下具體怎麼作。」這個是師傅的前檢查點標準語法。儘管在共同估算的時候你們仍是略有共識，可是限於計劃會的有限時間，徒弟未必真的知道怎麼作。在剛開始的一兩個小時裏邊，師傅帶領徒弟一塊兒把基本的結構理清楚，最好寫上一些基本代碼，讓徒弟有一個直觀的概念。

在上面提到的2周的重寫工做中，重寫者和被重寫者一塊兒工做了1.5天，從新設計了打包類、遞歸函數等最難纏的部分；被重寫者在剩下的兩週裏邊完成了工做，並且很出色。假若這一切發生在兩個月前該多好。那次事故以後，咱們訂立了更嚴格的代碼審查制度，全部代碼均由部門技術最好的人審查後才進代碼庫；以後再來的新人，均指派師傅，並由師傅保證其代碼質量；將人員劃分爲需指導的/免於指導的/可指導的/可培訓的四級（10年後我在NEC參觀交流時發現了幾乎徹底相同的分級制度）。

前檢查點的工做做用是打下設計的基礎，保證工做順利進行。若是一切按照前檢查點的設計進行，徒弟能夠繼續獨立工做，若是有偏離，要詢問師傅。

前檢查點的學習做用是顯而易見的，師傅平時工做的精華都展現在徒弟面前。並且這種展現是動態的，在結對編程的狀態下，徒弟能夠完整地看到師傅是怎樣入手工做，怎樣思考，怎樣解決問題的。

後檢查點

後檢查點就是某事作完後，師傅檢查一下徒弟的結果，保證達到驗收標準。

曾經分配給我一個剛畢業半年的組員，剛來沒多久就常常看到他上網玩，過去一問，原來工做作完了（真的很是快），驚奇之餘趕忙看看結果：功能是有了並且實現得也很好，就是總有點瑕疵：要麼按鈕不正，要麼界面上有錯字。後來就改爲每次任務完成都趕忙喊我去看看，修正後繼續下一個。他後來能力超羣，在此公司做爲「臺柱子」10年，如今還在。

其實多數新人在大學中都造成了「能運行就行」的概念，並不懂商業軟件開發的標準。本人也同樣，畢業5年還不知道delete內存（C++），每次都是多預留點C盤空間，這樣程序就能多運行一段時間，下班以後關機重啓就能夠了……這樣的軟件確定沒法在服務器上長期運行的。

在後檢查點，師傅能夠提出改進要求，也能夠當場改動。徒弟在此過程當中會發現本身和師傅的差距，並所以而獲得改進機會。

後檢查點的工做做用是可用來進行代碼審查，以確保軟件產品的質量，以後會提到。

後檢查點的學習做用是幫助新人學習商業軟件的開發標準，逐步養成好的習慣。

平常工做

除了在任務先後的時間點外，平常8小時也應該保持良好的溝通。在一次極端的環境中，咱們曾經將其發揮到極致。

當時咱們以很高的日薪臨時聘用了兩個不錯的程序員。他們技術雖然很好，可是卻對業務一無所知，也沒有提早看過文檔。由於總共也沒有多少天，固然不能把任何一分鐘花費在熟悉業務上，因此……

1. 天天早上（包括第一天）

整個軟件被大體分爲三類功能區，互相關聯。組長（我）也本身編程，負責其中一類功能。

有20分鐘的晨會，組長會把一個簡單的設計文檔的一部分拿出來說解給兩我的，同時指出今天要作的工做要給予其中的哪些內容，他們提問我回答。散會前咱們會就每人的工做作一個簡單的估算（當年還不會撲克牌估算，太惋惜了），確保當日是能夠完成的。

晨會會提到技術問題，而不是每日立會中說的只說進度。但技術問題通常只涉及到要求，好比「作分段計價模型的時候，不要在C++裏邊作For循環，看能不能在SQL裏邊解決，若是解決不了來找我」「好，我試試。（或）這可能嗎？」凡有問題的就會稍微深刻一點；凡是「我試試」的，都放過，但若是試驗的結果不通就必須找組長討論而不能自行解決。

小組加組長只有3我的，因此全部人都參加這個20分鐘會，包括確定不作某任務的人，也聽組長和別人的討論。

2. 天天下午1：30點左右

就是吃飽飯犯困的時候，組長會分別和你們在計算機前碰頭一下，主要是看當日的工做是否可能在下班前完成（堅持不加班）；另外就是看是否和晨會上預想的同樣。

其實就算是短短的半天時間，事情就可能有變。有一次其中一個程序員在一上午寫了大約4屏幕的代碼（通常天天才寫這麼多），而功能卻遙遙無期。原來他不知道有個函數能夠快速實現這些功能，正在本身造輪子，他本應該告訴組長所遇到的困難。

程序員不多在這個時候求助，他們老是相信本身能最終解決問題……所以在轉型爲自組織團隊的時候，擔憂程序員會偷懶的想法總體上是多餘的，更須要預防的是蠻幹/過於樂觀/激進/需求鍍金/消息閉塞/沒法互相學習等問題。

3. 天天下午下班前

當時6點鐘有《七龍珠》（工做場全部臺電視），兩位對此都很着迷，因此咱們基本到點就看片，看完後散夥回家。

由於也不能讓電視臺調整播出時間，基本上下午5點就要開始打掃戰場：組長分別找兩位，看最終結果是否完成，並作一下修改。同時還要作代碼審查（請看下一篇詳述）。

因爲估算不會太準確，咱們專門把全部三無論的小功能梳理出來，誰提早作完了，誰就找其中一個把剩下的閒工夫占上，結果其中一位幾乎包攬了所有。

4. 晚上

對，組長晚上還要工做。在他們走後組長會在晚上作個集成，把幾我的作的功能合成在一塊兒運行。當時也沒有持續集成工具，因此只能手工。

在正常項目的正常團隊中，這個工做應該在工做時間完成，也就是說或者找專人（或輪流），或者讓組長作，或者讓自動工具作最好。推薦小組內輪流負責此事，所以可讓你們理解別人的工做、總體的工做，乃至與組外人員的集成工做等內容，爲組員成長爲組長打下基礎。

5. 隨時

可能已經注意到咱們沒有「每日立會」，一則當年還不知道Scrum，二則感受一個3～5人的團隊還要靠開會交流實在迂腐。好比在篇首提到的兩次事故中，團隊都沒有少開會，但都由於缺乏隨時的溝通而致使大錯。

其實任何伸伸懶腰的時間均可以進行溝通。不過通常不要「太隨時」，應該以師傅的時間爲主，也就是若是徒弟遇到了問題，但能夠繞過去先走着，就先來一句「我這有問題，有空幫忙看看」+「好，再過15分鐘」。這樣既不會讓徒弟被卡住，也不會讓師傅由於常常被打斷而致使沒法工做。但師傅能夠隨時發起交流，由於他們是去幫助徒弟的，聊的也是徒弟的事情，不存在打擾的說法。

在多數狀況下不管徒弟學得多好，小組的主要產出仍然可能一大半來自師傅。所以不能把師徒團隊變成一個簡單的學習團隊，而要經過保證師傅的時間，來保證其首先是一個工做團隊。

這個工做習慣一直保持到後來我管理一個市場/銷售/支持團隊的時候：我選擇坐在開放空間的最中央的一張大桌上（各部門經理也都在中央桌上而非獨立辦公室裏），若是有人有事來找，都會問：「有空麼？」答案是有空，或者某個時間以後。尤爲是天天有10個以上不一樣的人會找你的時候，時間管理方法是很關鍵的。

注：上述部份內容僅限於特定環境中，但思路不少時候都是可取的。

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

前檢查點的基本做用是保證後續工做有大體的方向，並且徒弟能從師傅的設計過程當中受益。

後檢查點的基本做用是保證完成的工做符合要求，並且徒弟能從師傅作出的改進中受益。

在平常工做中，師傅要常常過問徒弟的工做，但以保證本身的產出爲前提。不能由於已經進行了共同設計和估算，或開了例會就放棄平常跟蹤，問題每每出在小處。

下一篇，將就代碼審查作一些探討，也就是師傅怎麼幫助徒弟改進本身代碼的過程。