敏捷的文件

件專案中有很多種文件，包括需求文件、設計文件、API文件、缺陷報告、進度報告、移交文件、驗收文件等等。

 在傳統的軟體專案開發中，每個團隊成員都要花費很多時間和精力去維護文件及填寫各種表格和報告。第二條敏捷宣言是"可工作的軟體勝於詳盡的文件"，據此很多人想當然認為敏捷開發不重視文件。更有甚者，有人為逃避寫文件而藉口敏捷開發不需要文件，成為所謂的PAP（Pretty Adventuresome Programming）。其實這些人忽略了敏捷開發中有很多實踐（比如坐在一起、現場客戶、測試驅動開發、客戶測試、結對程式設計、資訊化工作間等等)，敏捷藉助這些實踐進行資訊交流，起到了文件在傳統軟體開發中的作用。本文通過分析專案開發中的文件型別與作用來說明敏捷開發中為什麼很多文件是不需要的。

首先，需要明確文件的用途，文件是用來交流資訊的。關鍵是團隊中資訊分享是否及時準確，而這與文件的多少沒有必然的聯絡。就比如James Shore在博文"文件之謎"（http://jamesshore.com/Blog/The-Documentation-Myth.html）裡面指出的，很多人指責敏捷開發的文件不夠。其實他們忽略了問題的實質，"豐富的文件並不一定是好事，能及時得到答案才是好的"（Myth: Document is good; Reality: Answer is good）。

專業知識或者資訊主要分為兩類：

• 可以被整理，文件化的知識，一般只佔所有知識的30%。
• 佔70%的存在於人腦中的隱含(Tacit)知識，只能通過人與人之間的交流來分享，口口相傳。因此促進團隊內部以及團隊之間的交流對資訊的傳播更加有效。

軟體專案文件通常有三種：

• 專案文件，用於專案組內部資訊交流，比如需求文件、設計文件、進度報告等。
• 產品文件，通常是有業務價值的，是客戶需要的，比如使用者手冊或者API文件。
• 移交文件，在專案移交或者專案不同階段之間移交的成果物。

產品文件是客戶需要的，是產品的一部分，有業務價值，絕對不能省略。應該在迭代中為其安排一個文件任務。

從敏捷角度來看，另外兩類文件中的很多種是可以簡化或者省略的。

在敏捷開發過程中，

• 整個團隊坐在一起，移交文件變得多餘了。精益思想認為移交（Transportation）是很大的一種浪費（參見Mary Poppendieck，精益思想的原則 http://www.poppendieck.com/papers/LeanThinking.pdf），首先移交文件會花費很大的精力，其次很多資訊會在移交過程中丟失，另外每個階段還總會新增一些新的資訊。所有團隊成員（PO, Dev, QA, Doc）坐在一起，用白板進行面對面的溝通，既省時又省力，還有效。（參見Alistair Cockburn，敏捷專案中的溝通 http://www.agilemodeling.com/essays/communication.htm）
• Product Owner跟團隊坐在一起，隨時回答團隊成員的需求問題，是活的文件。
• 在Sprint計劃會議中，團隊選擇要完成的使用者故事（Sprint Backlog上的小卡片），形成Sprint backlog，這其實就是迭代計劃。
• 在釋出計劃會議中，Product Owner會確定釋出內容，形成故事牆，這其實就是較為長期的開發計劃。
• Dev和QA一起設計客戶測試（一般用Fit類工具）。重要的使用者邏輯被設計成客戶測試。這種需求（客戶測試）是可以執行的，因此永遠不會過時（如果出現問題，持續整合系統立刻就會發出警報）。這比傳統意義上的需求文件要有效得多。傳統文件有太多的問題，比如很少會有人去測試文件的正確性，很少有人去及時更新文件，很少有人去檢查需求覆蓋率（其實根本沒有辦法檢查，很多工具想當然的提供一些從需求到實現的追蹤，但這豈不又是一種形而上學？）。
• 在開發中微觀的具體的邏輯可以設計成TDD（或者BDD，行為驅動開發http://behaviour-driven.org/)）的用例，起到了詳細需求文件或者設計文件的作用。
• 開發人員使用結對程式設計（很多好處，參見"我喜歡結對程式設計" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/，以及 "結對程式設計：到底有多重要？"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/）。健康的系統架構應該是動態的，不斷演進的。因此如果把它用文件固定下來，也會出現過期或者不全面的問題。在設計具體模組的時候，團隊利用白板設計大體框架並確定方向，然後通過結對程式設計來具體實現。通過結對程式設計，可以很好的在團隊中分享和演進系統架構資訊。
• 團隊在每日站立會議中彙報進度，更新狀態以及遇到的問題，所有資訊會立刻反映到Sprint Backlog，Burdown chart以及各種圖表上，成為資訊化工作間的一部分，團隊可以據此進行自我調整。
• 每一次迭代之後舉行反省會議，團隊自我改進，也可以設計各種各樣的手畫表格（Ron Jeffries在個人網站上給了一些例子，http://www.xprogramming.com/xpmag/BigVisibleCharts.htm）來監控團隊自身的問題。因此傳統的審查及統計的文件就變得多餘了。
• 敏捷中高層次的需求通過願景(Vision)文件體現，這種文件一般只有一頁，變化的可能性不大，很容易維護。
• 高層的系統架構圖還是必要的。這種高層次系統架構變化的可能性也是很小的，維護成本也比較低。
• 程式碼即文件。很多敏捷大師十分注重架構清晰度以及程式碼的可讀性（比如Robert Martin總結的S.O.L.I.D原則，Robert Martin的Clean Code，以及Kent Beck的"實現模式"）。在某種意義上我們寫的程式碼其實就是指導計算機完成任務的式樣書。式樣書就是為了讓別人容易讀懂（要不然為什麼不用二進位制去編寫程式，放到機器上就可以執行）。

正如James Shore總結的，獲得資訊的手段有很多。

最優的手段，程式碼清楚、單元測試完備、命名規範，因此根本不需要問；

其次，只需要問一下旁邊的人，或者打一個電話，就可以立刻得到答案，這也就是為什麼敏捷鼓勵“坐在一起”和“現場客戶”r；

再次，Google一下找到答案，這也不錯；

……

很次，可以通過讀文件找到答案。可是為了找到答案，需要讀的文件越多，效果越差...

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566760/，如需轉載，請註明出處，否則將追究法律責任。