快速溝通

[Anthony Tsai]

上禮拜五6/ 15跟同事參加完這次研討會後，在開車回公司的一路上，跟同事兩人就很興奮的討論起研討會的種種觀念，很想把其中的一些觀念馬上應用在目
前工作上，體會節省並加快程式開發時程的快 ，因為除了剛畢業的時候，每天還可以朝氣勃勃的去公司上班之外，現在慢慢工作久了以後，隨著工作量的加
大，以及不正確的工作方法，幾乎每天下班都已經出現老師說的”滿臉倦容、神 情呆滯”的情況。連結所以，一回到公司，雖然已經是接近下班時間，但是想到
可以早日脫離苦海，兩個人仍然興致勃勃地憑著記憶跟討論的結果，各自看看哪些方面可以立刻應用上Agile method的觀念與做法，並且打算這禮拜
一上班就實施。

由於我們的職務是SA(System Administrator)，工作內容跟重要性依序為軟/硬體維護，檔案/資料管理，以及系統開發，通通都是只
要對內部負責就好的事項，所以看起來基本上沒有所謂的”客戶”可言，這樣一來，Agile method好像就英雄無用武之地了嗎？仔細想一想，其實不
然，跟我們要求服務的user也可以算是”客戶”的一種，完成了一個老闆或是user的要求就是一種”產品”了；他們提出需求，而我們開 他們的需
求，不正類似一間小型軟體公司的縮影。

而恰巧上禮拜有接到一張新的系統開發需求單，以往的做法是，當user如果有新的系統需求，上網申請完成簽核後，我們就會從e- mail中收到通知，
根據各自負責的部分，自己評估一下大約所需的時間，回信告知給user後，就根據e- mail裡面記載的需求開始撰寫程式，時間一到，就通知user
驗收，user沒問題就結案，有問題就繼續修改，直到完成為止。如今，有鑑於學到了Agile method的一些觀念，於是我們開始進行以下的一些改
變；首先，由於獲得了老闆初步的支持，願意讓我們試看看Agile method，所以我們先將座位搬靠近在一起，以便進行面對面的溝通；連結再者，不
要看著需求單就開始盲目工作，而是先去借一間會議室，讓user跟我們來溝通需求，請他所想要的功能、特性、 限制仔細說明一番，利用草稿圖的方式在白
板上討論，最後將結論跟使用情節，用一張白紙紀錄下來；連結還會跟他溝通，告知整個系統將不會一次給他，而會一個功能一個功能的局部釋出 並且每
一次等他測試完一個功能後，會再開一次review meeting，修改需求方向，再進行下一階段的開發。連結另外，改變程式的寫法，不再先寫出程式
碼，之後再回去補簡單的說明或註解，而是試著先把Pseudo code用淺顯易懂的方式寫出來，然後逐行去將所需的code補齊。連結更進一步的，由
於以往每一個人都是一樣的職務，不但要開發程式，也要軟/ 硬體維護，所以遇到user電腦有問題或是工作站當機時，根據急迫性，通常都必須放下手邊的
開發工作，先跑去處裡緊急的情況，但這樣一來，常常就會出現開發到一半，結果整個思考被打斷 ，導致程式要重想一遍的窘境，現在，我們決定試看看
pair programming的方法，將工作做新的切開，一個人負責專心寫程式--drive，另一個人負責review，寫test code，
以及應付所有的軟/硬體維護的突發問題；雖然這樣一來，第二個人的工作量看似加重，但沒想到實際上運作後發現，突發問題沒想像中的多，所以第二個人花在
review跟寫test code的時間是足夠的，更意外的是，第一個人由於可以不受打擾，專心一致在程式開發上，結果新系統開發的時間不但比較快，
在加上review跟test code的幫忙，錯誤也比較少，使得原本預估要兩個禮拜時間的功能，不到一個禮拜就完成，現在順利交給user測試中，
產生了win-win的情形。