如果敏捷是反文件的，為什麼會釋出一個宣言？
2001年，17位軟體開發、測試人員（其中包括Ward Cunningham、Jim Highsmith、Alistair Cockburn以及Bob Martin）共同釋出了《敏捷宣言》，並正式提出敏捷開發方法，作為傳統文件驅動、重量級軟體開發過程的替代方案。《宣言》提出了以下基本原則：
- 個人和互動高於過程和工具
- 工作軟體勝過全面的文件
- 客戶協作高於合同談判
- 響應變化而不是遵循計劃
似乎預見到這種簡單可能會導致誤解，《敏捷宣言》也對此進行了澄清：“也就是說，雖然右邊的東西有價值，但我們更看重左邊的東西。”
即便如此，業內對敏捷開發方法的誤解和困惑仍然存在。“over”被“instead of”所取代，原本《敏捷宣言》的意圖是“最好把更多的注意力放在軟體上，而不是把時間花在過於詳細的前期文件上”，現在似乎變成了“讓我們完全拋棄文件，並希望我們記住討論的所有事情。”
一、敏捷神話：“文件並不重要”
採用傳統IT專案方法的團隊會在專案的早期階段定義並記錄需求。隨後，這些需求將會被提交給開發人員，開發人員收到需求後便立即開始實施。
雖然敏捷開發方法是作為這種文件驅動開發過程的替代方法而建立的，但它並不打算完全消除內部文件。由於軟體開發在本質上是動態的，因此，敏捷開發更重視工作軟體而非綜合文件。
敏捷開發方法中沒有任何內容會阻止團隊建立專案所需的文件。事實上，在某些情況下，文件是絕對需要的：將使用者故事新增到待辦事項列表中，以及建立流程圖、做會議記錄等。敏捷只是——敏捷只是建議在這方面團隊要聰明一點。
文件應該“剛剛好”。太多或過於全面的文件會浪費時間，而且開發人員很少相信詳細的文件，因為它通常與實際程式碼不同步。另一方面，經驗表明，文件太少始終是困擾溝通、學習和知識共享問題的根源。
二、投資敏捷文件的原因
敏捷文件的建立和維護對某些人來說是“不可避免的災難”，但對另一些人來說，這是一項愉快的任務。同樣，會有一些合理的理由讓你相信，值得在敏捷文件上投入時間：
- 專案的利益相關者需要它。從根本上來說，建立文件是一個業務決策，團隊將利益相關者的資源投入到文件開發中，因此他們應該對是否以這種方式花費他們的錢有發言權。
- 支援與外部團隊的溝通。開發團隊總是位於同一地點是不可能的，並且讓利益相關者隨時待命也是不可行的。共享文件通常是與偶爾的面對面討論、電話會議、電子郵件和協作工具相結合的解決方案的一部分。
- 也不可能總是讓專案涉眾隨時待命。共享文件通常與偶爾的面對面討論、電話會議、電子郵件和協作工具結合在一起，是解決方案的一部分。
- 支援組織記憶。敏捷建模的原則之一是“實現下一個努力是你的次要目標”，這意味著與“工作軟體是你的首要目標”的原則相平衡。這意味著，團隊在開發軟體時，還需要開發使用、操作、支援和維護軟體所需的支援文件。
- 把事情想清楚。把想法寫在紙上的行為可以幫助自己鞏固它們，並發現自己思維方式中的問題。那些在腦海中看起來清晰而直接的東西，往往會被證明是非常複雜的，所以可以先把它寫下來。
雖然以上所有的理由可能都是文件化的合理理由，但我們總是問自己這樣一個問題：我們目前需要的最少可交付量是多少？
三、如何在敏捷中編寫文件
1.敏捷文件的4條原則
- 敏捷中的文件是“可變的”，需要整個團隊協同維護。為了充分利用我們在文件上投入的時間，我們可以遵循一些簡單的原則：
- 確保它總是“剛剛好”。請記住，建立的任何文件都必須在之後進行維護。如果文件簡單、不復雜、不太詳細，就更容易理解和更新。
- 用“just in time”來寫。在記錄之前先耐心等待——這是避免積累錯誤和過時資訊的最好方法。在需要的時候再生成文件，而不是在需要之前生成。
- 將文件放在一個容易獲取的地方。文件只有在可訪問的情況下才有用，將產品文件儲存在團隊成員可以輕鬆找到的地方。
- 與團隊合作。在敏捷團隊中維護文件是一個協作過程，應該鼓勵每個團隊成員對此做出貢獻。
2.何時記錄
敏捷中工作軟體的迭代交付有效地取代了很多（儘管不是全部）全面的前期需求文件。其理念是儘可能保持文件的簡單和輕量級，特別是在專案的早期階段。那麼在什麼情況下值得在文件中投入時間呢？
一個常見的敏捷實踐是儘可能推遲所有可交付文件的建立，在實際需要交付文件之前建立文件。例如，系統概述和支援文件最好在軟體開發生命週期（SDLC）的結束時編寫。從本質上講，這種方法是在等到資訊最終確定後再捕獲它。
另一種敏捷文件的策略是持續文件化。在整個專案中編寫可交付文件，在更新程式碼的同時更新文件。這種方法符合敏捷的方法，即持續生成潛在的可交付的解決方案。
然而，由於需求可能在專案的過程中不斷髮展，因此需要相當多的時間來讓可交付文件的保持最新狀態。從敏捷的角度來看，這又是一份“沉重的負擔”。
在實踐中，敏捷通常會推遲編寫文件，直到他們有時間這樣做，實際上，即使他們最初決定持續更新文件，也會逐漸轉向文件的後期實踐。
3.記錄什麼
- 敏捷文件中可能用到的文件示例包括案例研究、圖表、表格和站點地圖。以下是在專案過程中會考慮建立的一些文件：
- 產品願景：它是對產品核心的描述，是對當前的成本估算、預期收益、風險、人員配備估算和計劃里程碑的總結。這一文件的要求是：保持簡短，直切要點。
- 專案概述：這是與專案相關的關鍵資訊的總結，例如主要使用者聯絡方式、技術和用於構建系統的工具等。將其作為團隊新成員的起點，並在整個開發過程中對其進行維護。
- 設計決策：這是團隊在整個專案中做出的與設計和架構相關的關鍵決策的概述。
- 操作文件：這通常是對系統所涉及的依賴項的描述，以及對備份過程的參考、故障排除指南等。運營部門可能會有此類文件的標準格式。
- 需求文件：它是對系統功能的概述，包括用例、使用者故事或基本使用者介面原型等。旨在將需求捕獲為可執行規範。
- 支援文件：這包括專門為支援人員提供的培訓材料、故障排除指南等。與運營部門一樣，支援團隊可能有標準模板或示例來使用。
- 系統文件：提供系統的概述，包括技術體系結構、業務體系結構和其他高階需求。系統文件有助於確保關鍵資訊的留存。
- 使用者文件：它包括使用者參考手冊和支援指南。這一文件的要求是保持簡單、易懂。如果需要採用大量的培訓來教會使用者如何使用該產品，那麼解決方案文件的設計就是有缺陷的。
四、結論
“我們接受文件，但不接受數百頁從未維護過以及很少使用的大部頭。”
敏捷開發方法絕不是反文件的。它只是提醒團隊不要編寫多餘的文件，並且在必要時儘可能保持文件的簡單性。通過敲定某種格式和細節級別的，允許更改並能交付足夠價值的文件，以保持團隊在正確的方向上前進。