工作室安祥的氣氛....
Anthony Tsai
在讀了這篇簡報之後，我才知道原來我之前打工的工作室也是採用此法，而我在裡面做的工作便是工讀生，負責寫test code。這間工作室的氣氛就很
好，是在咖啡廳裡面coding，在裡面工作時，真的有一股安祥的氣氛，不是死氣沉沉的。所以我在看了這篇簡報之後，得到了許多共鳴。
Agile Method給我大致上的感覺是，顛覆了傳統軟工的開發流程，重新定位其性質，敏捷正好非常符合其性質。在傳統軟體工程常會計畫趕不上變
化，一開始分析的跟後來實做的產品，常會有很大的 入。針對這點，我想敏捷開發的優勢就會完全的展現出來，系統分析固然重要，但仍然不可能將全盤
計畫擬定完整，正因為此特性，順勢採用隨機應變，我想這就是敏捷方法，化被動為主 。
文中所提得敏捷方法是個觀念，搭配了TDD這個測試帶動法，讓整個敏捷方法有系統的運作，其中pair programming是我覺得最有趣的一個。
的確在寫程式的時候，很容易因為某個盲點，而疏忽了一些基本的事項，pair programming兩人一組(driver+review)，對此類
錯誤，定有很大助益。對於實做細節也可以互相探討，就像文中所提可以增加工作時的成就感，我相信成就感是寫程式的一大助力！
另外，Unit Test也是一個很不錯的工具，以往寫程式，最怕的就是，錯過了某個小地方，導致留了一個不易發現的bug。爾後，當程式越寫越大，就
越難找出那個問題了，從小地方開始預防是很好的出發點 。且用Unit Test來改善，可以讓創意奔放，做大幅度的修改(re-
factoring)，放手去做的結果，當然是越容易做出好的產品。
TDD 介紹的communication cycle中，駐點使用專家是其中的一環，對於駐點使用專家的加入，也是非常新穎的作法。客戶是衡量成果重
要的指標之一，讓產品更接近客戶所需。傳統的客戶甚至可能會不知道自己需求， 能大約講出方向，實際產品符不符合理想也都是個問題，所以採用產品的
分次release，讓產品能夠慢慢調整，對雙方都較有保障。在之前的工作室中，我也有看到這些方式，工作室每天都會 skype開會報告進度，每
隔幾天也都會和客戶做聯繫且報告進度，互相提出建議並改進且持續的整合，且的確可以發現文件變少了。一次一次的test cycle中，產品也就扎實的
堆砌出來。
綿密的溝通也是敏捷的重點之一，其中強調面對面溝通是最容易進入狀況的。就我以往的經驗看來，面對面的討論的確比研讀冗長的文件來的效果好，不過那是要
建立在參與討論的人要有基 的認知，不然參差不齊的人員，效果容易大打折扣。面對面的溝通需要很扎實的群育訓練，大學專題的經驗是，太常面對面容
易導致部份同學相處不愉快。對於因為用面對面溝通讓文件少 許多，我認為應該保有最簡單基本的文件，類似概觀之類的，讓新進人員的訓練比較容易進入
狀況。這樣也解決了傳統軟工文件過於冗長，導致新進開發人員難以進入狀況，甚至文件只是應 付交差的工具。
文中強調優質的開發環境，不可過時加班，讓心思寧靜、神清氣爽，創意才能湧現。這也是很多人容易忽略的，常常為了趕工，欲速則不達，往往會更費時。我也
很贊同工程師不是趕工的工 ，不是拼命就可以的，從事軟體設計的人們，要有自覺的是自己並非施工的工人，而是一位設計師，培養優良的環境是最重要
的。之前待的工作室，在這一點也做的很好，在咖啡廳裡面codin g，放著古典音樂，喝著咖啡，真的非常舒適，這才是"設計師"應有的態度。
myAgile 中的架構設計會議(CRC)、資料結構設計到演算法設計，提供了一整套很有規律的開發方式。架構設計將class寫成卡片，甚至到角色
扮演某個 class，調整整個class的架構，落實OO開發，是非常有趣且實際的辦法；再來資料結構設計強調需在高階層次思考，盡量別用低階的
array等；演算法設計也是相當有趣的設計方式，以虛擬碼為主 code為輔，跟傳統的方法差異甚大。個人認為此設計方法有一定的難度，畢竟需要
平心靜氣的先參考虛擬碼、debug，確定完全無誤之後，才會coding實做出成品，對於急躁的人比較無所適從。不 過能做到的話，好處會非常大，無
論是整個演算法的可讀性、日後維護、開發品質都會有很大的提昇。
在這之前，我不知道這也是一套學問，只是知道明顯工作室的成果都很優質，氣氛很好，我想這些都是敏捷帶來的好處。在知道細節之後，仔細思考了傳統軟工的
問題，我認為這是種革命， 落實是蠻困難的，長久來的習慣是很難一次更改，文中所提"群育"也是很重要的，能接受pair
programming、面對面討論等，都是難點之一。團隊中每人的程度也會影響敏捷度，個人認為這套方法必須建立在優良的開發人員(不只是技術
上) ，能夠接受這些新觀念落實並改進，才有辦法將整個Agile Method發揮出驚人的效果。