l

2014年3月14日 星期五

談談XP(3c):Primary Practice

Mar. 05 14:04~15:10

image

 

介紹完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。

***

友藏內心獨白:用小時估啊沉思

1 則留言:

  1. Pair Programming恐怕是我在公司內最難推動的一件事。

    回覆刪除