Pair Programming例子(二)
Anthony Tsai
前工作上的一些系統及我們現有的一些主機, 網路等環境向這位同事說明後, 交給他一些相關文件, 讓新進同仁參閱, 請他有問題時再問他.(最差的溝
通方式)
過了三個月, 我問他對於我們廠內現有的一些系統是否可以理解, 他說還不是很清楚, 我問他你有問你的輔導員嗎? 他說有時候問輔導員, 覺得他不太
喜歡被打斷的樣子, 所以不好意思問.我問他是否輔導員有拿目前工作上比較簡單的維護需求讓你試著做? 他說也沒有, 可能是還要跟他說明如何去做,
不如自己來做還比較快(課本中資深程式設計師上班時不講下班後再來改其他人寫的程式碼的例子)
我請他搬張椅子坐到我旁邊, 並以一個實際工作上的需求為例子, 從工具的使用到程式碼的修改實際完成一次給他看, 並請他有問題就提出來, 之後我找
了一個簡單的需求讓他嘗試去完成, 我則坐在他旁邊一起看他要改的程式碼, 並隨時回應他所提出的問題, 當有錯誤時也即時提出改正. (Pair
Programming ?)
雖然他跟我有資深資淺之分, 但所謂的資淺也許只是工具及程式語言的熟悉程度之分, 對於問題的解決想法則絕對沒有所謂的資淺資深的分別, 有時向他說
明完我想用何種方法來完成這一個工作時, 他會提出更好的想法, 像之前我們想將目前廠內的白紙板改為以棧板為單位來管理出入庫的工作而不是以包數的作
法, 每一棧板賦予條碼來直接識別其紙別,基重,規格,包數等資料而不用人工去清點, 但馬上遇到一個問題就是現有庫存有成千上百個棧板要如何納入管
理, 後來他提出一個想法就是將相同紙別,基重,規格,包數的現有庫存成品給予一個相同的虛擬棧板號碼(課本中女工提出PC Board上的錯誤的例
子)
之後此位新進同仁對我提及我們的主管曾請他不要時常跑來問我, 會打擾到我, 我聽了之後不勝唏噓, 有時一些好的作法與想法時常斷送於上層主管的短見
之中, 所以在目前工作的場合只見大家眼睛死盯著電腦螢幕, 手劈哩啪啦的敲著鍵盤, 嗯, 很努力, 很好...而工作上主管對於軟體系統的績效評核
還是停留在量的上面, 你列的越多完成的越多好像就比較有績效, 而不是以程式的困難度及解決的完善度來衡量, 就像課本中軟體公司以送入測試部門的程
式行數來決定你的績效一樣.
Anthony Tsai
Pair Programming在我的工作環境算是滿常見的，會須要做Pair Programming可以分成二類。一種是因為專長不同須要二人合
作才可以來完成一份工作，另一種則是軟體人員間的合作來?成目標。利用下面二個案例來說明
我是在一家手機製造商工作，因為手機生產時須要對每一支手機做RF(Radio Frequency) Calibration(調校)，使得每一支手
機的性能可以達到一個標準。Calibration 在手機是一個必要的流程，因為手機會使用到很多硬體的元件，每個元件都有誤差，雖然這些誤差都不
大，但是組合起來時誤差可能因為累加的作用而造成一個較大的誤差，為了避免這樣的 形，我們透過一些可以參數調整的與一些法則(Rule/
Algorithm)來改變整體的誤差，使這些誤差可在一個範圍內，可確保產品的品質。
而RF Calibration牽涉到RF的特性，須要具有RF專才的人(通常是具通訊背景) 才會知到如何去做調校，但是要將這樣調校的流程實現則須
要有程式設計師的協助。所以一位RF工程師與我一起負責開發，一開始我們因為屬於不同的部門，所以坐在不同的區域，所以當有 題時，大部份以電話溝
通。有時因會錯意而造成錯誤開發。所以我們將開發的地方改到會議室，將所須要的儀器及設備都移至會議室中，二個人一起在會議室中來開發程式。這樣的調整
讓我 的開發效率明顯的提高，不但解決了因為電話溝通所造成的誤解，而且有問題時可以直接詢問不明瞭的地方，加上電腦及設備的輔助，可以更快更清楚的了
解問題的所在。
會議室的白板也提供了我們討論問題的重要幫手，我們可以列出有問題的項目及須要完成的工作清單，以及要撰寫的演算法的流程規劃。
這樣的改變讓我們開發的時程大幅的縮減，從之前開發一個項目要一個月(文件閱讀、程式規劃、撰寫、測試、除錯、發行) 縮短至二個禮拜，整個專案的開發
時程也由6個月縮短至2個月，大大的縮短了開發的時程。
在這樣的改變中，我們用到了 Agile Method 中的幾個方法
01. Interactive, face-to-face communication is the cheapest and
fastest channel for exchanging information
=>面對面的溝通可達到最大的收益，且可避免會錯意，減少溝通間的障礙。
02. Increasing feedback and communication reduces the need for
intermediate deliverables.
=>因為 Pair Programming 雙方可以取得最快的回應。
03. 加強溝通以減少文件的產出。之前 RF工程師會先草擬構想(GUI,要達到的功能，調校流程) ，在由軟體工程師來實現。而這樣的流程可以經過
面對面的溝通及白板的輔助來移除。減少文件的撰寫與閱讀相對的也代表了開發時程的縮短。
04. 交期縮短。因為二人在一起工作，可以針對每天撰寫的程式作測試，一旦RF工程師發現問題，可以即刻修改，減低錯誤的擴大。這樣的作法大大的縮短
了每個階段的交期，所以我們這部份在 個手機專案的時程表是最早完的的一個部份。而我們不但提前完成工作，而且可在整個專案中協助其他人員的進度，
讓專案的進展更加順利。
第二個案例是軟體人員的 Pair Programming。狀況是當我們開發完Calibration 的流程後，須將這樣的流程導入產線。因為產線
有自己的產線程式來控管整個生產的流程，所以我們須要提供 calibration library 給產線的軟體工程師。產線工程師負責UI化及整合
至產線程式的工作。在我們提供 library 後，產線工程師在開發的過程並無發生問題，但在將程式移至生產線後，調校一隻手機的時間由原本的
120秒變成 480秒。經過軟硬環境的比對後發現工廠的作業系統是 Win98，而我們工程師都是用 Win2000 的環境來開發的。雖然知道是因
為作業系統差異造成的，但因為工廠不換作業系統的情況下，我與產線工程師必須解決時間差異的問題。因為在產線，時間的長短代表產量，也代表其獲利能
，所以這樣的問題對產線是很重要的問題。
因為上次的經驗，所以我們又使用一會議室來做 Pair Programming，因為產線程式太大了，對我們不是負責這方面程式的人是很難依其架構作
模擬的實驗，必須要產線工程師對產線程式熟悉直接在程式上修改測試。我們會針對產線工程師懷疑的問 一一的測試與澄清，如 library 呼叫花
費時間的問題等。而產線工程師也會針對我們懷疑產線程式的一些現象做測試與澄清。經過幾天的 co-work 後，一些我們可以想到的問題點都被澄清且
驗証是沒有問題的。我們陷入了我們所無法解釋的一個況狀。所以我們開始閱讀相關的文件與Programming 技巧，一連二三天我們都毫無進展。在一
個偶然狀況，我注意到了產線上的時間，在測試的過程中，這個時間的秒數執行的很順暢，完全不受測試程式在測試其他項目的影響。我很好其的問 如何
作到的，產線工程提到是利用執行緒達成的。經過細問後才知到程式開了好幾個執行緒，有的作UI 的更新，有的作底層的演算法流程，所以時間才不會有延遲
的現象。這時我突然想到前幾天一本書上寫有關執行緒程式設計應注意的事項，其中有一項提到在 Windows CE 上使用執行緒時應該注意若是使用
while loop 時，應加入 sleep(0) 來釋放該執行緒佔用的CPU timeslot，若是在此 while loop 的程式沒有被
呼叫時。我立刻翻開書本給產線工程師看，他看了之後就在程式加了這一行程式，時間就這樣降下來了，跟在 Win2000 上的時間差不多了。而造成這樣
的差異只能說 Win2000 對於這方面處理的比較成熟，而 Win98 處理的比較不好。
在這個案例中，我學習到了一個軟體人員須要時時的加強自己的基本技能，才能在發生問題時利用本身的知識來解決問題，就如 Agile Method 中
所提，01.人員多並不代表產能就高，因為相對的人員管理的問題等也會浮現。
02.每個人要能獨當一面，才能解決該領域的問題。
03.高素質的人員代表高效率。