軟體開發文檔重要麼，什麼方法可以讓開發人員在完成好項目的同時，提交相關文檔？

01-18

要看是什麼規模的軟體項目。

大規模，超大規模的項目，並且歷時很長，需要協同開發的項目。沒有文檔的話簡直是不可想像的。

中小規模，且發布後很少有修改的需要的話，不如把更多的精力放在代碼自注釋上，詳細設計文檔沒有也罷。

既然很重要，那麼怎麼能夠讓開發人員很好完成呢？我的看法是無利不起早。一定要為文檔編寫預留出充裕的時間，並且納入績效考評。其次，如果可能的話，要對詳細設計文檔進行審批，做到文檔先行。審批不一定要多麼正式，以小組討論的形式展開效果也很好。

有一些文檔是非常重要的，資料庫的設計文檔，涉及到不同系統的介面設計文檔，一些複雜系統的編譯安裝文檔。這些個是比較重要的，應當要保留下來。

軟體開發文檔實現不是很難，不是不可能，不是隨意。

關鍵取決於企業一貫作風習俗，高管態度，用戶是否要求。

至於必要性，答案是必要。但未必拘於形式。

文檔的作用是讓大家對項目結構、對邏輯有共同的、統一確定的認識。

這就是為什麼產品設計、開發、測試如果都是一個人來做的小項目，不需要文檔。

程序員的煩惱之一寫文檔

程序員的煩惱之一缺少文檔

安排一個有技術背景的，文字、總結、記錄能力比較強的文檔工程師，專門配合項目經理及開發人員整理、編寫文檔。

我之前接觸過的團隊有不寫需求文檔的,也不能是說不寫！...他們把所有的功能描述和說明全部寫在AXURE原型里了,這個怎麼說呢,看團隊之間的配合來決定了,如果開發團隊,一開始就不寫開發文檔,你現在想去修改別人的習慣,挺難的,這個時候需要你的個人影響力去決定

書寫剛剛好的文檔，避免補文檔，我剛好有篇文章講這個話題，參見 Just enough（剛剛好）的軟體開發文檔什麼樣？

http://blog.csdn.net/zhangmike/article/details/6786503

第一個問題，軟體開發文檔很重要，需求文檔、資料庫設計文檔、模塊介面說明文檔，不論項目大小，這幾個文檔也都是必須的。不能說它能夠發揮多大的作用，只能說有了它們更有利於項目按期、高效率完成。

第二個問題，我個人認為讓所有參與開發的人員寫文檔不大可能。文檔的作用就是能夠讓大家在開發中有文可依，做一個參照和了解業務及實現原理、流程。不說不能寫，只是怕寫的只有寫的人自己能夠理解，而其他開發人員卻看不懂。與其這樣不如在團隊中安排一個相對文采較好，並參與整個項目需求分析、架構設計、編碼實現的開發人員撰寫。

推薦ABT軟體工程文檔生成工具。文檔寫作效率提高百倍！如果您開展的項目多，這就是降維打擊工具。

ABT軟體工程文檔生成工具，規範文檔樣式結構，快速生成: 1需求規格，2設計說明，3測試報告，4用戶手冊，5用戶聯機幫助，6其他文檔。

用戶自己寫文檔核心內容，即自動或定製生成插圖，uml圖（用例圖，結構組成圖，功能類圖，類包圖，數據類圖，流程圖等），表格，章節目錄，順序編號，列表項段落等等。

版本管理十分方便，支持合併、導入，文檔模塊化、重用性非常好。

根據需要增加功能，定製模版。可生成word，powerpoint，pdf，html，htmlhelp等常見文檔。

開始不做,後面在來寫,就十分十分的摳腦殼!

寫不寫設計文檔應從能否提高團隊開發效率角度考慮，如果不需要文檔也能保持溝通順暢，那就不寫，小型的敏捷開發過程就是這樣。如果團隊規模較大，周期較長（中間會有人員變更），那就應該寫文檔。應該去幫助開發人員寫文檔（比如提供合適的模板、例子，很多開發人員語文水平遠遠差於代碼水平），而不是一味的去提要求。

軟體開發文檔的作用(寫文檔的目的)：整理思路；統一認識；以備維護。

redmine很好的項目管理軟體，開源很好用結合subversion

每周更新下文檔，每天查看下注釋，但是如果開發周期緊張的話，這些會敗給時間

少些點文檔就好了。所有的東西最後都是垃圾一堆，少寫點更環保。

這個，基本上。。。很難