敏捷宣言裡有一具：『可用的軟體重於詳盡的文件』。大家聽到都會背了。然而，我認為這句話是四條宣言裡最容易被誤會的一條。敏捷要不要執行、執行得好不好，跟你寫不寫文件一點關係都沒有。

一般人學習敏捷開發框架時，總是喜歡拿敏捷跟傳統Waterfall管理方式來做比較。其中總是會提到傳統瀑布式的專案管理，在一開始就把所有的細節都規定好，因此有常常做到一半才發現這設計超難實現，或是做出來的東西客戶根本不要的情況。然而，卻有很多人因此而誤會，以為『敏捷開發不寫文件』，這實在是讓這個框架蒙上不白之冤。

敏捷不是不寫文件，敏捷是只寫『有需要的文件』。

就像User Story一樣，我們有一定數量的庫存backlog，依照重要程度排序著，時間到才依序拉一些進sprint來動手做。文件又何嘗不是？文件為何不能比照辦理？其實可以的。寫程式需要時間，測試需要時間，寫文件也需要時間啊！憑什麼程式可以被排序、估算，與檢討，文件卻不行？

文件也能測試

更有甚者，你知道文件也有測試嗎？試想，程式是人寫的，有正確與否與是否吻合客戶需求的問題，那麼，難道文件不是嗎？寫得不好的文件，無法教使用者用正確方式使用產品，也無法讓使用者簡單地了解功能。因此，文件當然也可以安排測試啊！

如果你的客戶需求與契約中，包含了文件，你就應該在產品成長過程中，大方地 『把文件當成產品的一部份』生成並檢驗品質。簡而言之，你應該像對待程式功能一樣對待文件。為什麼？因為那是妳產品的一部份啊！不然咧？

如果客戶重視，那就寫吧

身為軟體工程師，我一直認為，對待測試與文件，要像對待功能一樣慎重。而在敏捷流程哩，你就要去評估這些需求比次間的優先順序。這個優先順序有賴PO、SM與各Stakeholder的溝通與討論。如果這個客戶這麼重視文件，那就寫吧！出一張User Story，排入Sprint，寫吧！

記得Code Review :)