[Agile Method] Pair-Programming 與成本

那天去關貿網路面試時，技術長有問道：企業老闆怎麼可能採用 pair-programming，怎麼可能讓兩個同時只做一件事情？有沒有數據研究可以證明兩個人工作至少等於兩個人甚至大於兩個人的成效？

這個問題其實見怪不怪，當我還是個準碩士時，我的指導教授開了一場敏捷方法研討會，內容就是提倡敏捷方法！在會議後半段的提問時間，許多企業也對都於 pair-programming 實行上產生質疑！沒錯～依照台灣對於成本 cost down 的觀念來說，要執行這種不符合成本的作法實在不合邏輯～雖然我在實驗室有採用過這種方法來開發軟體，不過因為我們的軟體規模實在是很小，不能說是一種 product 只是計畫中的一個 project 而已，所以實際的成效很難信服，但是兩個人的討論確實可以減輕很多壓力！

後來我就找我的老師討論，老師應該也已經想過這問題如何在台灣實行的問題，所以他就給我這樣的回答：做軟體的品質一定要第一，成本才是其次；沒有品質的軟體賣不出去，那成本壓的在低也是不符合成本！但是如果老闆真的有成本上的壓力，我們可以部份採用 pair-programming，其實 Agile method 只是一套方法，而方法的內容可以根據實際上得情形加以調整，以便因應不同環境！所以我們可以在軟體的核心元件採用 pair-programming 而其餘的部份像是 UI 就採用傳統的 single role 方式來開發，畢竟軟體的核心元件是整個系統中最重要的，重要的部份就必須要提高其品質！

聽完老師這樣的回答後，對於 Agile method 的可行性又更往前邁了一步！而且我也很贊同老師所說得：品質第一！

[Agile Method] Communication: The key to Agile Method

在 Agile method 中有很多現有的方法被採用，像是 Test-Driven Development(TDD)、Pair programming 等，也有一些新的規範被納入，如：stand-up meeting、on-site customer 等！不過這些方法最重要的基礎就在於 Communication(溝通)！Agile method 中很講究溝通，就像 pair programming 就是最明顯也是強需要溝通的一項方法，溝通必須是基於自己肯分享肯討論的個性為主，不然 pair programming 也會流於形式！

Pair programming 在之前也有討論過，就是兩個人綿密的溝通，一個人的思考畢竟有限，想法也會有缺陷，所以透過 pair programming 的方式可以降低這樣的缺陷，不過這只有降低，並不能完全的消除，畢竟還是會有機率發生在兩個人都剛好沒有想到某個缺陷的存在！因為我在實行 pair programming 時真的是有發生這樣的情況～在 pair programming 中溝通就變得很重要，溝通是基於表達方式，如果表達方式不佳，溝通就容易造成失敗，因為對方聽不懂你在說什麼。

TDD 方法中也是有溝通，很難想像吧！當初我也是沒有想到，不過在某一堂課程中，我們老師點出了這個觀念我就懂了！TDD 就是先將我們的 test code 根據 scenario 完成，當我們完成這部份的功能時，我們就交給電腦去幫我們驗證邏輯，這種就是跟電腦的溝通，因為當 scenario 很豐富時，我們可能要測試的 test case 就會很多，這當然不能由人自己慢慢的測試，我們只能測其中幾個比較重要的，剩下的完整測試就交由電腦幫我們去跑，所以這也是一種溝通，只是不是面對人，是面對機器！

Stand-up meeting 就像是現在有很多公司會每週開會一次，不過在 Agile method 中是希望可以每天早上開會，開會中決定今天的工作，開會中討論昨天可能碰到的問題或是開發中可能遇到的狀況等等，也因為一個開發團隊的人員很少(6~10人)，所以 stand-up meeting 是相對的容易，當團隊擴大時，溝通也會是一個很大的問題！目前有些國外的 conference 也在徵求類似的經驗分享 papers，希望業界中有人可以分享他是如何解決團隊擴大時溝通的問題！

On-site customer 就是希望我們的客戶能夠跟著開發團隊一起工作，因為只有 on-site customer 可以真正的瞭解 customers 的需求，如果開發團隊在開發中遇到問題，就可以馬上請教 on-site customer 回答問題～這也是一種溝通，不過這種溝通是希望可以讓 customer 提早進入軟體開發的生命週期，以往的開發方法中，customer 只會參與到整個生命週期的最早與最晚，也就是 requirement 與驗收，若開發團隊無法與 customer 時時的溝通，產品往往在完成後變成一堆價值很高的垃圾，畢竟 customer 無法在一次會議或一段時間中想到所有想要的 requirement，所以如何讓需求變成 live requirements 是現行開發方法中最重要的 issue。

從這些 Agile method 中很重要的實行方法中，我們可以發現溝通是最重要的元素，不過也會有很多人誤會 Agile method 就是靠溝通而不需要撰寫文件，溝通固然是必須的，但是沒有文件紀錄溝通中重要的資訊，那溝通也就枉然了～人類的腦袋無法記得所有溝通的內容，所以還是需要文件的輔助，不過 Agile method 中又希望文件是有必要才產生，因為當文件的數量一龐大，系統有修正時，修改文件就會變成很粗重的工作，若文件不跟著同步，那文件也是流於形式而成為昂貴的垃圾了～所以如何在文件的數量上取捨，其實也是一種學問跟經驗。

以上是目前當了自己老師的 Agile method 課程助教時有感而發～與大家分享！

[Agile Method] 少量而高品質的Document

今天 meeting 時，老闆剛好有提到 agile method 的 document 觀念，我就順便問了一下上次去英丰寶面試時被問到的其中一個問題：當我們在開發專案時，我們要怎樣知道哪些文件是該寫？當時我回答的內容是：在專案開發時，如果認為某些文件是需要撰寫的，那就去寫，如果有哪些文件是過時或是無法在繼續維護與同步的話，就要大膽的刪除！不過，在 agile method 中強調，最重要的文件其實就是 pseudocode，也就是程式中的註解。因為 pseudocode 才是 developer 當初寫程式時的思維！這點很重要，雖然原先的 agile method 中並沒有硬性規定，但是我在實驗室中開發 ITRI 計畫的實際經驗來看，pseudocode 的確很重要，因為使用者常常會更改系統的需求，如果當初有寫好 pseudocode，修改程式所花費的時間就會大幅的降低！這點我很肯定！

講了這麼多，老闆今天給我的回應是：當我們在開發專案時，無論開發系統是否有特定的使用者，都需要先從 scenario 下手，也就是先將系統的使用情境撰寫出來，這是所有文件的起頭！因為有了 scenario 之後，我們就可以根據 scenario 撰寫出 use cases(跟 use case diagram 一點關係都沒有！)，這些 use case 是將 scenario 中所描述的功能以程式的角度去描述！也就是定好 input, output 與呼叫的關係。接下來就是根據 use case 寫出 class interface ，這裡的 class interface 是指撰寫出空的 class 架構與 method signature(含 parameters)，再來就是根據 use case 中的輸入輸出撰寫 test code，完成了 test code 之後就是寫 class 中每個 method 的 pseudocode，最後才是補上 source code。

上面所說得是基本的文件，如果開發團隊之間的溝通能力較弱的話，可以就得視團隊情況去撰寫需要的文件，如：class diagram 等。但是如果團隊溝通的能力較強，也就是團隊成員之間都清楚這個系統的詳細資訊的話，文件能不多寫就不要浪費力氣，因為修改使用者要變更的需求是需要花更多的力氣！

但是如果使用者要求一些超越基本文件的範圍，那當然還是要撰寫，畢竟使用者是最大的！給錢的永遠是老大～

今天還有問到 UML 圖到底要不要去寫的問題。老闆的想法是：完全不用！因為系統開發完之後，我們可以透過逆向工程工具幫助我們由完成的 code 去產生 class 與 sequence diagram，當然，系統完成後我們也不必多花時間來作逆向工程來產生 UML 圖，而是有需要再去作～畢竟，少量的文件是 agile method 的想法，但是要以高品質為前提！

對於文件的觀念，agile method 與 CMMI 完全是站在不同立場上去思考的！我個人是比較贊成 agile method 的看法，這並不是因為我們實驗室是採用 agile method 的關係，我本身也有上過 CMMI 的課程，雖然不是很專精，不過看到 CMMI 需要撰寫很多的文件就很令人頭疼！在台灣，很多公司為了獲得 CMMI 的資格，文件都是有目的在寫的！老實說，身為工程師我想沒有人是喜歡寫文件的，畢竟寫文件是一種吃力不討好的工作。但是如果文件與系統沒有同步，一百頁的文件也形同浪費硬碟空間的垃圾～文件太多，同步所花費的時間與力氣就越多，所以要精簡文件的數量。

以上是小弟個人淺見～希望有興趣的人可以多多討論！

[Agile Method] Pair-Programming

Pair-programming 顧名思義就是 pair-thinking 或是 pair-doing something

在台灣的公司，幾乎看不到這樣的情形，因為台灣的文化與思想都是一個人獨立思考、獨立作業。

但是，pair-programming 確實是有他的好處，當自己真的去實踐才會有體會！

在我的碩士生涯中，雖然只有短短的兩年，不過我已經自己接下兩個 CASE，一方面是為了賺取生活費，但是目的卻是在於學習。

CASE 通常都是一個人在自行開發的，我也不例外。我在實驗室中被分配到開發工業研究技術院(Industrial Technology Research Institute of Taiwan，以下簡稱 ITRI)的計畫，不過很特別的是我的指導教授 - 陳振炎教授，他特別提到說，我與我的開發夥伴 - Brian 必須一起作同一件事，也就是實行 pair-programming。

所謂的 pair-programming 就是我跟 Brian 要一起寫同一支程式，但不是各寫各的，是要一起寫，所以就是一個人負責 key-in codes 而另一個人負責檢查邏輯。現在市面的不論是付費或是免費的 IDE 都已經具備有程式 syntax 的檢查，但是邏輯的檢查卻是只能靠 programmer 自己去解決，而 pair-programming 就是在解決一個思考漏洞的問題。

實際上這很有趣，因為我們從來沒有這樣的經驗，不過我卻也深深地體會到，一個人的能力真的很有限！因為我跟 Brian 之間的實力在伯仲之間，所以我們的思考與想法都很接近，但是人與人之間一定會存有衝突！那怎麼辦？好在我們兩在進入碩士前就彼此認識，所以在溝通上我們都盡量以雙方意見的結合為最終的結果，所以一直到現在我們都很順利的在開發。

反觀我所接的 CASE，因為只有我一個人開發一個部份，所以所有的問題我只能自己想辦法自己解決，除非我真的想不出來，我才會去請教朋友。

但是問題出現在實際面上，一個企業不可能僱用兩個人去作同一件事，這對於台灣的企業來說是不符合成本的，所以現階段要讓 pair-programming 在台灣實現事很有困難的！