[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 的資格，文件都是有目的在寫的！老實說，身為工程師我想沒有人是喜歡寫文件的，畢竟寫文件是一種吃力不討好的工作。但是如果文件與系統沒有同步，一百頁的文件也形同浪費硬碟空間的垃圾～文件太多，同步所花費的時間與力氣就越多，所以要精簡文件的數量。

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