敏捷中的文檔：寫多少、何時寫?

　　敏捷的目的是盡量減少浪費(fèi)，所以采取了極端的邏輯，所有的文檔都是浪費(fèi)的東西。這并不意味著文檔可以(或應(yīng)該)被完全拋棄掉。文檔對于團(tuán)隊來說是有用的(特別是當(dāng)團(tuán)隊要擴(kuò)展規(guī)模時)。但宣言建議，減少文檔是一件好事，而設(shè)計者應(yīng)該尋求利用最少量的文檔溝通設(shè)計決策。

　　Jonathan 針對如何盡量減少文檔提供了如下建議:

　　1) 在你的團(tuán)隊中普及“越少的東西會更好”的理念。

　　2) 時刻思考這個問題：我們馬上需要交付的最少量的交付物有哪些?

　　Ashish Sharma 在《敏捷的本質(zhì)、價值和及時的文檔》一文中，提到如何在文檔和討論之間取得平衡：

　　敏捷的目標(biāo)應(yīng)該是在文檔和討論之間的適當(dāng)平衡。文檔是每個系統(tǒng)的重要組成部分。無論是否采用敏捷或其他方法，相當(dāng)全面的文檔并不能保證項目的成功。事實上，它會增加失敗的機(jī)會。

　　他提到當(dāng)考慮要寫多少文檔和什么時候去編寫的時候，可以參考下面三個標(biāo)準(zhǔn)：

　　必不可少：文檔應(yīng)該僅夠用但詳細(xì)。

　　有價值的：編寫文的確所需要的文檔，而不是我們想編寫時才編寫的文檔。

　　及時：文檔應(yīng)該當(dāng)我們需要的時候，以及時的方式(JIT)編寫。

　　Michael Nygard 描述了對文檔相關(guān)流程的看法。他建議用一開始就考慮結(jié)果的方式去思考流程：

　　我經(jīng)常發(fā)現(xiàn)很多流程都沒有消費(fèi)者。這純粹就是浪費(fèi)!從表面上看沒人使用輸出物，但過程的負(fù)責(zé)人根本沒意識到。

　　Michael 建議，流程包括它們的輸入和輸出都能從消費(fèi)者的角度去描述。他分享了可以下面的問題去協(xié)助描述：

　　誰是最終消費(fèi)者?

　　他們的需求是什么?

　　你如何交付給他們?

　　你如何知道他們?nèi)绾螠?zhǔn)備好?

　　你如何生產(chǎn)?

　　你需要什么輸入去生產(chǎn)產(chǎn)品?

　　Tom de Lancey 于 2013 年早些時候在 LinkedIn 中開展的關(guān)于《緊急的文檔：敏捷與瀑布模型的一個重要區(qū)別》中說道：

　　很多人對于放棄他們熟悉經(jīng)常使用的文檔感到不舒服：系統(tǒng)需求、系統(tǒng)設(shè)計、愿景和范圍、用例、模式、工作流程圖、Rational 統(tǒng)一過程文檔等。很多人都不能將這些文檔分拆成五個句子的故事。

　　他描述了一種稱為“緊急文檔”的分析方法用于編寫文檔：

　　(…)我們不會浪費(fèi)時間和精力在編寫那些我們未曾發(fā)現(xiàn)如何去做的文檔上。當(dāng)我們發(fā)現(xiàn)問題的時候才編寫文檔。我們編寫實際所需要的文檔，而不是那些我們想去寫的文檔。

　　TOM 說的緊急文檔的其中一個好處是：

　　文檔變成開發(fā)過程的一個部分，而不是單獨(dú)的活動。因為文檔實際上是十分有用的，整個團(tuán)隊都有興趣去維護(hù)它。每一個用戶故事都有單獨(dú)的任務(wù)需要去更新 WIKI(使用一個將每個用戶故事相互連接的 SharePoint 網(wǎng)站)。

　　Mario Moreira 寫了一篇關(guān)于《敏捷世界的正常文檔規(guī)模》的博文。正如 Mario 說的，適當(dāng)調(diào)整規(guī)模是對過去或現(xiàn)在有大量的文檔的軟件項目的響應(yīng)：

　　文檔的正常規(guī)模意味著，編寫和維護(hù)文檔的精力投入加上所寫文檔自身的價值，相比沒有該文檔(比如，重新組織信息的投入和沒有文檔對當(dāng)前決策帶來的影響)，應(yīng)該能獲得更好地投資回報率，

　　他的博文提供了在正常文檔規(guī)模的建議。他的部分建議如下：

　　文檔應(yīng)當(dāng)采取合作的性質(zhì)。它不應(yīng)只由一人編寫得那么完美，而應(yīng)該與他人分享。應(yīng)當(dāng)在草稿階段就進(jìn)行分享以獲得足夠的信息。

　　關(guān)注僅僅夠好的文檔并且避免太多的前期細(xì)節(jié)，因為那樣意味著很多的猜測并且會浪費(fèi)時間。僅僅夠好意味著只針對當(dāng)前所了解的編寫文檔。

　　文檔應(yīng)該以多種形式存在。不但只是 Word 格式的文檔，還可以存在于 wiki、存在于敏捷工具，或代碼中的注釋或其他。