[size=medium]
[b]緣起[/b]
「我們產品已經做完了，客戶說要補上需求文件，可我們只有使用者故事，這個文件應不應該寫呢？」
「沒有這個文件，客戶能驗收嗎？」
「不能，客戶要開課題評審會，這個是評審會材料之一。」
這個文件要不要寫呢？寫，為什麼？不寫，為什麼？寫怎麼寫？不寫，怎麼不寫？
[b]為什麼敏捷不寫文件？[/b]
先把話說絕點，敏捷就是不寫文件。那為什麼不寫文件？
[b]為了減少浪費。[/b]
敏捷認為所有中間產品，需求，計畫，設計，測試用例……都缺少客戶價值，客戶最想要的價值，無疑是最後的可執行的軟體。因此所有中間文件都應該省略省略再省略，直到不寫。
[b]不在對客戶沒有價值的東西上面浪費時間，這是敏捷不寫文件的真實含義。[/b]
只是從實踐上看，最浪費時間的無疑是那些無用的文件。但倘若文件是有用的，而且甚至是客戶價值的重要部分，一切就變了。
[b]怎樣寫這個需求文件？[/b]
就這個文件而言，它是為了驗收所用，和開發沒有關係（已經開發完了），和日後維護沒有關係。
那怎麼寫？這個問題就不回答了，當然是按驗收的寫法寫。
所以，所有文件的所有寫法，在每個企業都不相同，不應該問「敏捷開發應該怎樣寫xx文件？」，而是應該問「應該怎樣寫上面那個文件？」，而若能這樣發問，答案已經明確了。
[b]「寫不寫文件」的常見做法[/b]
常見的文件雖然很多，但下面幾個維度幾乎永遠存在，具體某個文件通過幾個維度的分析，處理方法各不相同：
[b]首席資訊官期/短期有效的文件[/b]
長期有效比如競爭對手分析文件，架構設計文件，需求管理文件（使用者故事），產品路線圖……
長期文件適合詳細描述，用語應完整（就是寫word那種寫法），甚至可以動用圖形和建模工具。
短期有效比如評審發現的問題，po在計畫會上講解的內容等。
短期文件適合粗略描述，典型的就是用紙或word凌亂地寫一些關鍵內容，無需長期儲存，月末一般就無用了。
[b]不可/可被」可執行軟體「替代的文件[/b]
上面舉例的文件中，競爭對手、架構設計、使用者故事、路線圖都無法從**中看出來，適合文件化。此外，一些科學計算的公式、複雜的設計也屬於此列。
而介面設計、資料庫表結構設計、流程圖、偽碼等，一旦軟體做好了，更容易在可執行軟體中看出，就不要著大量筆墨於此。
若感覺後者處於」沒有就做不出軟體，但做出軟體又沒用了「的尷尬境地時，應採用輕量級設計。
[/size]
ref：
敏捷開發之設計文件
對於設計文件的一點體會就是，明確需求 精簡語言 並繪 相輔 易於溝通。下文援引 在產品研發過程中經常需要編寫很多文件，例如 需求文件 設計文件 api文件 驗收文件等等。團隊成員要花費很多精力去維護眾多的文件，甚至有 兄弟，我替你寫 你替我寫文件 的無奈。敏捷開發宣言 個體和互動 勝於 流程和工具 ...
敏捷開發之設計文件
對於設計文件的一點體會就是，明確需求 精簡語言 並繪 相輔 易於溝通。下文援引 在產品研發過程中經常需要編寫很多文件，例如 需求文件 設計文件 api文件 驗收文件等等。團隊成員要花費很多精力去維護眾多的文件，甚至有 兄弟，我替你寫 你替我寫文件 的無奈。敏捷開發宣言 個體和互動 勝於 流程和工具 ...
敏捷開發的使用者故事怎麼寫？
以下是近期對敏捷開發中由以往 調研 文件 討論 文件 開發 文件 向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。如何編寫使用者故事？1 使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。2 格式 ...