軟體開發過程文檔如何寫作？——“文檔==雞肋”？

“雞肋——食之無味，棄之可惜”，軟體開發過程文檔遭遇了雞肋一樣的境遇。

目前敏捷式軟體開發 (Agile Software Development)過程非常流行。相對於軟體開發過程文檔，敏捷式軟體開發 (Agile Software Development)過程更加重視可啟動並執行程式。
關於軟體開發過程文檔，兩個極端都是不可取的：一是嚴格要求過程文檔，把過程文檔作為開發過程的一個必然輸出，而不考慮文檔是否真正的起作用，即“過度文檔”。二是完全放棄文檔，不進行任何的記錄。“過度文檔”偏離軟體開發的實質，會造成人力的極大浪費；放棄文檔則會丟失開發中的關鍵資訊，不利於產品後期的維護。
我們需要在上面兩者之間做一個權衡。這裡可以引用“二八定律”：用20%的文檔，記錄80%的內容。這樣用最小的投入，擷取最大的價值。
20%的文檔要記錄那些東西？
1、產品需求描述。
毋容置疑，這是最重要的一個資訊。關於產品需求描述，可以寫兩個文檔，一個是需求的整體描述；一個是功能特徵表文檔。功能特徵表對整體需求進行分解，便於後期跟蹤需求。

2、軟體架構描述，軟體實體作用及相互聯絡。
系統整體結構描述，包括系統包括多少實體，每個實體的作用，實體間的互動機制等。一般要配備圖形說明。

3、程式內部結構，邏輯模組，互動。
軟體實體內部邏輯模組的劃分，各個模組的作用，以及各個模組間的互動機制。

4、資料庫設計。
資料庫，表達，欄位的設計。

5、通訊協定。
軟體實體間互動訊息描述，比如，SIP，XML等。

6、關鍵資料結構函數。
能夠反映軟體實體邏輯結構的關鍵資料結構定義，函數。

7、複雜問題解決方案。
對於複雜需求的解決，需要多個軟體實體，或者多個邏輯模組互動實現。這些方案非常值得記錄，可以方便後續產品的維護。

文檔寫作時間可以靈活一些，可以在項目開發過程中進行，如果開發進度非常緊張，也可以開發完成後在補充文檔。如果維護過程中，對產品進行了大的更改，要及時的重新整理文檔，保持文檔與程式的同步。

寫文檔過程中，文檔的內容要放在首位，不可以在美工，格式上浪費過多的時間。