敏捷開發學習總結: 思考開發文件的利與弊

文件是個好東西，這是不可否認的，但是太依賴文件也有弊端，下面我從不同的度來分析一下文件的利與弊，然後思考在敏捷開發時，文件又是如何進行的。


從 公司的角度來看，編寫文件有如下好處： 
a1) 公司使用的是瀑布生命週期（或序列式開發，傳統開發），所以必然的，在某一個階段，需要編寫大量的文件作為進入下一階段的輸入。
a2）過程改進的 需要，認為只要過程控制得足夠細，例如只要文件編寫得足夠詳細，那麼人員是可以被替換的，也就是說，有了文件，人員的流動不會給專案帶來大的風險。
a3） 受到其它行業的啟示，例如建築行業，圖紙製定好並確否沒有問題後，施工隊才能準確無誤地施工，所以要求在編碼之前先編寫HD、DD文件,除了方便交叉 REVIEW，同時，文件用於指導資淺工程師的編碼工作，文件只有編寫的足夠詳細(DD最好給出虛擬碼)，工程師才不至於走偏。
a4) 企業知識庫的建設需要，沒有文件，技術就沒有得到積累。


從工程師的角度來看，為什麼工程師有時不願意寫文件呢？

 
b1） 程式碼與文件的同步問題，很多設計文件在寫完後就被程式碼遠遠地拋在後面了，開發人員只有二個選擇，要不更新文件，要不任由文件逐漸地開始撒謊，如果選擇維護 文件與程式碼同步，那麼就會耗費大量的時間和精力在文件更新上面，而維護這份文件目的只是為了將來有可能有人需要閱讀---也有可能無人問津。
b2） 任務的工時安排得很緊，但編寫文件又導致進度太慢。
b3）認為文件太枯燥，不比編寫程式碼有成就感。
b4）沒自信，怕文件寫不好會誤導別 人。
b5）本身沒有搞清楚思路，所以也就寫不出文件。


從敏捷開發思想的角度去看待上述的一些問題： 
對應 a1) 這就是敏捷開發反對瀑布模型的原因之一吧。
對應a2) 首先寄望於通過過程控制來達到開發人員可替換性目的這個想法，是有爭議的 ，另外，極限程式設計中使用“程式碼整合所有權屬於團隊”的實踐方法來保證團隊內部的知識共享，從而減少人員流動對團隊帶來的風險。
對應a3) 敏捷開發的建議是隻寫有用的文件，例如編寫整個系統的HLD或架構文件是值得的，因為整個團隊的成員以及新人都要閱讀它來了解整個系統的架構和設計，而某 個模組的DD文件，它的讀者只是負責該模組的程式設計師，敏捷開發的建議是面對面進行交流來傳達設計比較來得快捷，不編寫過於詳細的DD文件的原因是它太容易 與程式碼脫節了，另外，面對面交流，並不是資深人員傳達設計給資淺人員，而是讓資淺人員參與到設計中來，是以平等的方式與資深人員一起討論和確定最終的設 計。可是文件畢竟比起程式碼易於閱讀，總得要有個載體描述模組的DD設計啊，一般來說是推薦“Self-Documenting ”的形式來代替DD文件。
對 應a4) 輕量級的文件不代表不編寫文件，所以這一點與知識庫的建設不衝突。
對應b1) 儘量使用“Self-Documenting”的形式，即將文件以註釋的形式插入到程式碼中，來解決文件與程式碼的同步問題，需要文件時，再用工具從程式碼中提 取出文件，例如Java中的JavaDoc工具，而Qt的API文件也是這麼幹的，Qt的文件是用doxygen來生成的。
對應b2) 這就是輕量級文件的原則所要解決的問題，除了避免編寫無用的文件外，如何避免長篇大論的文件也是要解決的問題，我從UP開發方法的產出物（製品）中瞭解 到，UP開發方法使用的“用例驅動”方法將需求分析文件以“用例(Use Case) ”的形式來編寫，減少了出現長篇大論的可能性。
剩下的 b3,b4,b5是開發人員自身的原因。


最好做個總結，文件是好東西，但它的弊端就是要花時間（包括寫作和維護的時間），如果專案時間都比較緊，如何把握文件的量和細緻程度，確實是值得思考和權衡的問題。