寫發布文件的原則就是要寫的盡可能詳細，需求是什麼，實現了哪些功能，發布時的步驟，注意事項，聯絡**，發布日期等，最好是傻瓜式的，標準就是：只要按照發布文件寫的進行操作就算在大街上隨便抓個人過來部署都不會出問題。
這才是好的部署文件，很多人在寫發布文件的時候很敷衍，基本用的都是模版，大綱都是有的，然後內容大概改一下就 ok，甚至文件編寫人和**都不改！有人會說很多運維和測試人員基本不看發布文件，浪費太多時間沒必要，其實發布文件寫的詳細一些，不但會省很多時間，還會避免很多麻煩：比如避免測試人員部署或運維上線過程中出問題在聯絡開發人員去除錯；而且發布文件寫的詳細也對開發人員自己有好處，可能過了很長一段時間後程式出問題了或者有人詢問這個功能，開發人員可能自己都忘了，這時候，拿出發布文件一看清晰明了，會省很多時間！
更重要的是對接的人也會對這樣的開發人員有乙個靠譜的好印象，這裡又涉及乙個詞：信任度，試想如果 qa 每次測你開發的程式都有很多問題，運維上線你開發的程式成功率很低，那很自然對你的信任度就會很低，即使是協同開發的專案出問題了，第一時間想到的可能就是你，而不是別人。
時間評估：
開發階段大概只是花費整體開發時間的三分之一左右，評估開發時間的時候把自己的編**時間大概乘以 2 或 3 基本是合理的。
用過即專家，這才是程式設計師的自我修養！
專案文件編寫總結
最近幾周都在根據新的功能需求編寫相對應的文件，先編寫專案立項報告，編寫結束後開始編寫需求規格說明書，之後便是詳細設計說明書，下個階段便是編寫階段了。以前也編寫過需求規格說明書和詳細設計說明書，因為以前經驗少，寫的東西不夠深度沒有特點，有一種為了完成文件而寫。這次完全把自己當做設計，想要讓自己設計的功...
編寫專案需求文件
color darkred b 需求分析文件要點 b color color darkred 以下需求文件要點適合瀑布式開發過程。color 一般在最前面有編寫者及文件版本和變更記錄等。color darkred b 引言 b b 編寫目的 b color 術語及縮寫解釋 預期的讀者和閱讀建議 co...
如何編寫介面文件
乙個簡單的介面文件，寫完給組長看後，發現漏洞百出。下面總結一下寫文件需要注意事項 封面最好是本公司規定的封面，有logo，內容標題，版本號，公司名稱，文件產生日期。錯誤地方在於，文件的標題要和頁首中的標題一致 形式較好些。包括，版本，修訂說明，修訂日期，修訂人，審核時間審核人。我錯誤的地方在於，中其...