敏捷開發是否意味不用寫文檔

　　如果理解為敏捷開發后不用寫文檔是對敏捷開發很大的誤解。敏捷開發的重點是輕文檔，而不是不要文檔。而這種輕我原來也講過，對于全新的系統開發最好是在有總體方案或架構后再開始輕。

　　對于怎么理解輕文檔，我建議你好好看下scrum里面的product backlog和sprint backlog。注意這就是文檔的一種形式，而且這種文檔包括了需求，業務場景，實現思路，驗證和測試方法，估算等多個內容的按user story的追溯。而不是按傳統軟件工程思路拆分為多個文檔。

　　敏捷開發是重溝通，輕文檔。文檔要適度，既不能成為項目團隊的累贅，也要出現爭議的時候有具可查。

　　先說需求文檔，分為兩部分，一方面是框架性的需求文檔，對功能、交互方式、出錯或邊界情況的表現進行總體描述，這種文檔不需要過于細致，因為產品經理組織語言寫文檔，開發讀文檔，理解文檔都要消耗大量時間，最好是以總體概括的方式來做，開發在做需求設計時候與產品人員進行頻繁密切溝通，最終一起形成完整文檔，這中間開發、測試人員對于文檔嚴謹性是有很大貢獻，不必要求產品經理全部把邊界細節都寫出來。

　　另外一方面，作為良好的協作習慣，任何溝通產生的結論都應該存檔!郵件是一種比較好的形式。每次會議結束，問一句結論呢?誰出紀要?不是說文檔不重要，而是通過見面溝通，把需要文檔描述很細節的內容達成共識。

　　概要設計詳細設計，視需求邏輯難易，規模大小而定。邏輯復雜的項目，概要設計作為幫助開發理解需求的一種手段。大型項目，詳細設計架構設計不可避免。一句話規模的需求，隨便做做就算了。這其中都要不斷的當面溝通!前提是項目成員不能太死板，也有一定磨合，并能力較強。