iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 24
0

剩下最後一小時,每天都有截稿壓力
今天破例不談Ruby on Rails
來談談專案管理上會用到的 Pair Programing
聽說這個方法是「敏捷式開發」的一種
感覺用上的會讓專案飛天的樣子
因為今天工作上有使用,所以來聊一聊

顧名思義,
所謂Pair Programing就是兩人一組開發,
一個人動手、一個人動口,
就好像在開車時,一個駕駛一個導航,
動口的人確實蠻像是導航的角色。

大部份人看到這個可能心中會有一個疑問:
如果以人力工時來看,兩個人一起開發的效率一定是分別開發的二分之一
那為什麼這會是一種管理方法呢?(如果說教育訓練方法還說得通)

先轉換個場景,各位工程師即使沒學過外科手術
大概也看過電影、影集或是怪醫黑傑克
知道醫學訓練裡面的最後一年,就是跟診
一群剛出醫學院的年輕醫師,跟在資深醫師的旁邊
觀察怎麼開刀、怎麼看診
其實情境有點類似。

兩人一組的開發,不一定開發者資淺、也有可能相反
資深者開發,資淺者在旁邊觀察
如何搭配要依團隊實際狀況而定

最重要的精神,其實是:
「開發品質重於開發速度」

兩人開發雖然較慢,但是在思緒形成的過程中
兩位工程師彼此交流、溝通
當然更容易發現盲點,避免埋地雷

畢竟當code review時,程式都已經完成
有一些思緒上的錯誤可能不容易發現
也就是雖然code對,但觀念或精神可以優化的情況
藉由兩人一組,適度的問答、介入
會將每一段邏輯釐清得更完整

也有一種情況是企業邏輯熟悉者與開發者的搭配
類似:PM與developer兩者一組
開發的過程中,不斷確認使用情境
確保成品是最終端使用者所需求的

對我個人來說
這當然不會是常態性的一種開發模式
我還是傾向把這當作教學的一種方法

今天的情境是新手卡關卡很久
但是問卡在哪裡又問不出個所以然
所以乾脆放下手邊的工作
一動一動的了解目前的開發流程
有點半強制或是趕鴨上架的完成進度

相比於直接要新手看參考的code
在旁邊的引導的好處是真的想過撞過牆
這個時候才去導引效果更佳
否則參考現成範例,有點像是上課複製貼上
但是不懂其中原理的感覺

在導引的過程中,需要注意的是:
不斷提醒自己要保持耐心,不要生氣
在腦中不斷回想自己很菜的時候,去問前輩被冷落的畫面
盡力保持愉悅
不然可能會在情緒上收到反效果
不可不慎!

每個人都當過新手,所以當可以回饋的時刻
更要萬分注意~


上一篇
避免重複render錯誤
下一篇
淺談Concern -- 相同的方法要好好收納
系列文
Ruby礦工的Rails地圖30

尚未有邦友留言

立即登入留言