在 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 課程助教時有感而發～與大家分享！
發表文章
沒有留言:
張貼留言