談談XP（3c）：Primary Practice

Mar. 05 14:04~15:10

 

介紹完Sit Together、Whole Team、Informative Workspace、Energized Work，今天繼續介紹下面兩個XP Primary Practice：

• Pair Programming（雙人編程、結隊編程）：先解釋一下這個翻譯，「編程（編寫程式）」這個詞原本是對岸用語，相當於我們的「程式設計」。一開始覺得用「編程」取代「程式設計」有點怪怪的，但是目前對岸用語已經多到氾濫的境界，久了之後倒也覺得習慣了。至少「編程」兩個字比「程式設計」四個字來的簡短一些，如果翻成「雙人程式設計」、「結隊程式設計」，雖然比較符合我們習慣用語，但念起來感覺好像稍嫌繞口。

言歸正傳，Pair Programming這個實務做法應該是XP最為人所熟知的實務做法之一。關於Pair Programming的看法Teddy已經講過好幾次了，請參考〈Pair Programming 成本太高，嗎？〉、〈Pair Programming 沒人性？〉、〈Teddy 的 Pair Programming 之旅〉、〈喝看看就知道〉。Kent Beck在書中提到Pair Programming的一些優點，像是可以讓雙方都專心於目前的工作、腦力激盪想出好的解法、互相討論釐清想法、當對方卡住的時候可以接受繼續做，減少對方的挫折感（有時候一個人卡住很久，真的是會很挫折，覺得自己跟白癡沒兩樣…Orz）、互相監視對方有沒有依照「大清律例」（團隊規範的方法）辦事。

關於Pair Programming有一個常見的誤解，就是配對的雙方在工作完成之前必須要「相愛相守，至死不渝」。「法律」並沒有規定Pair Programming的雙方隨時隨地都要年再一起。當任何一方需要獨自思考，或是雙方要分頭尋找資料，有人需要休息片刻等，都可以隨時分道揚鑣，等準備好之後再繼續雙人合體。

還有一點就是Pair Programming是一件很累人的工作，Kent Beck提到一般人約5~6小時就精力耗盡。這一點和Teddy的經驗很類似，Teddy一天最多pairing約5小時就腦力與體力耗盡。所以規劃Pair Programming的時候記得一天不要安排什麼8小時或12小時，開發人員會受不了啊。

• User Story（用戶故事）：User story在談Scrum的時候已經介紹過很多次了，不過XP所說的user story並沒有特別要求寫成「身為使用者，我可以XXX以便YYY」或是「為了YYY，身為使用者我可以XXX」這樣的格式。XP的user story有一個名稱，一個簡短代表功能的名稱，例如「處理客戶訂單」、「存檔並且編密」、「傳送認證郵件」等。將這個描述變成user story的標題，寫在一張小卡片上（Story Card），在卡片上可以補充說明這個user story的內容，以及估算完成時間。

Kent Beck在書上建議，user story寫好之後儘快幫它估算實作所需時間。Kent Beck強調早期估算user story的好處，因為可以讓business people與technical people雙方早點互動，以便決定user story的價值。經過討論之後，也可以對user story加以合併、切割、擴展，甚至是丟棄。XP的建議和Lean的作法有點不太一樣，有些「精實」到極致的人認為「估算也是一種浪費」，所以不需要事先估算，等真的要開發的時候在估算就好了。

在書上的例子估算的單位是採用小時，而不是Scrum所採用的Story Point。XP建議把user story貼在牆上，如果公司或顧客需要進度回報，再另外製作他們需要的報告，但是不要用將user story電腦化之後而捨棄原本實體的Story Card。

***

友藏內心獨白：用小時估啊。