敏捷中的文檔：寫多少、何時寫?
英文原文：Documentation in Agile: How Much and When to Write It?
敏捷開發宣言強調“可以工作的軟件勝過面面俱到的文檔”。該核心價值要求我們去及思考要編寫多少文檔，需要編寫什么類型的文檔以及什么時候需要去編寫文檔。
在 Jonathan Berger 的博文《最低限度交付物》一文中，提到關于在設計階段的決策溝通。他對有關編寫文檔的觀點如下：
敏捷宣言更喜歡“可以工作的軟件勝過面面俱到的文檔”，那么，為什么設計者還要花時間在用戶將永不會看到的東西上？敏捷的目的是盡量減少浪費，所以 采取了極端的邏輯，所有的文檔都是浪費的東西。這并不意味著文檔可以（或應該）被完全拋棄掉。文檔對于團隊來說是有用的（特別是當團隊要擴展規模時）。但 宣言建議，減少文檔是一件好事，而設計者應該尋求利用最少量的文檔溝通設計決策。
Jonathan 針對如何盡量減少文檔提供了如下建議:
1) 在你的團隊中普及“越少的東西會更好”的理念。
2) 時刻思考這個問題：我們馬上需要交付的最少量的交付物有哪些？
Ashish Sharma 在《敏捷的本質、價值和及時的文檔》一文中，提到如何在文檔和討論之間取得平衡：
敏捷的目標應該是在文檔和討論之間的適當平衡。文檔是每個系統的重要組成部分。無論是否采用敏捷或其他方法，相當全面的文檔并不能保證項目的成功。事實上，它會增加失敗的機會。
他提到當考慮要寫多少文檔和什么時候去編寫的時候，可以參考下面三個標準：
必不可少：文檔應該僅夠用但詳細。
有價值的：編寫文的確所需要的文檔，而不是我們想編寫時才編寫的文檔。
及時：文檔應該當我們需要的時候，以及時的方式（JIT）編寫。
Michael Nygard 描述了對文檔相關流程的看法。他建議用一開始就考慮結果的方式去思考流程：
我經常發現很多流程都沒有消費者。這純粹就是浪費！從表面上看沒人使用輸出物，但過程的負責人根本沒意識到。
Michael 建議，流程包括它們的輸入和輸出都能從消費者的角度去描述。他分享了可以下面的問題去協助描述：
誰是最終消費者？
他們的需求是什么？
你如何交付給他們？
你如何知道他們如何準備好？
你如何生產？
你需要什么輸入去生產產品？
Tom de Lancey 于 2013 年早些時候在 LinkedIn 中開展的關于《緊急的文檔：敏捷與瀑布模型的一個重要區別》中說道：
很多人對于放棄他們熟悉經常使用的文檔感到不舒服：系統需求、系統設計、愿景和范圍、用例、模式、工作流程圖、Rational 統一過程文檔等。很多人都不能將這些文檔分拆成五個句子的故事。
他描述了一種稱為“緊急文檔”的分析方法用于編寫文檔：
(…)我們不會浪費時間和精力在編寫那些我們未曾發現如何去做的文檔上。當我們發現問題的時候才編寫文檔。我們編寫實際所需要的文檔，而不是那些我們想去寫的文檔。
TOM 說的緊急文檔的其中一個好處是：
文檔變成開發過程的一個部分，而不是單獨的活動。因為文檔實際上是十分有用的，整個團隊都有興趣去維護它。每一個用戶故事都有單獨的任務需要去更新 WIKI（使用一個將每個用戶故事相互連接的 SharePoint 網站）。
Mario Moreira 寫了一篇關于《敏捷世界的正常文檔規模》的博文。正如 Mario 說的，適當調整規模是對過去或現在有大量的文檔的軟件項目的響應：
文檔的正常規模意味著，編寫和維護文檔的精力投入加上所寫文檔自身的價值，相比沒有該文檔（比如，重新組織信息的投入和沒有文檔對當前決策帶來的影響），應該能獲得更好地投資回報率，
他的博文提供了在正常文檔規模的建議。他的部分建議如下：
文檔應當采取合作的性質。它不應只由一人編寫得那么完美，而應該與他人分享。應當在草稿階段就進行分享以獲得足夠的信息。
關注僅僅夠好的文檔并且避免太多的前期細節，因為那樣意味著很多的猜測并且會浪費時間。僅僅夠好意味著只針對當前所了解的編寫文檔。
文檔應該以多種形式存在。不但只是 Word 格式的文檔，還可以存在于 wiki、存在于敏捷工具，或代碼中的注釋或其他。
各位是如何編寫文檔的？要編寫多少和何時開始呢？歡迎討論。
<span id="shareA4" class="fl"> </span>
</div>