怎樣看待活文檔“ATDD”---記敏捷中國2012 open space

爲什麼要有一份活文檔？
在現實中有太多這樣的情形：新介入一個項目，老人會丟過來一堆的文檔或者鏈接地址，並告訴你說，這些是與這個項目相關的一些文檔資料，這些資料裏有些內容是已經過時了的，項目有些最新的需求還沒人補充，先借鑑着看吧，不看文檔還好一點，看了文檔更暈。產品經理悶着頭吭哧吭哧寫了半個月的需求說明，然後招集大家開會，在會上打出投影對幾十頁的需求說明一個字一個字的過，產品經理在上面講的口吐白沫，下面的聽會人員昏昏欲睡，4個小時過去了，文檔終於過完了，開發工程師按進度完成開發任務了，提交測試，測試人員看着實現出來的功能直撓頭，這不對呀，叫來產品經理三方對質，產品經理說，我寫的需求說明要表達的意思是這樣這樣這樣的，不是現在這個樣子的，聽完這句話，開發人員直接口吐白沫暈倒過去，產品經理嘆氣搖頭“唉，這些東西我在那天的需求評審會上都說過的，怎麼就不記呢，需求又有變更了，我還得抓時間把文檔修改一下”，合上電腦悄然離開，揮一揮衣袖不帶走一片雲彩。
ATDD是什麼？
ATDD即驗證測試驅動開發，文鄒鄒的定義是“在準備實施一個功能或特性之前，首先團隊需要定義出期望的質量標準和驗收細則，以明確
而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試腳本開發”。
ATDD的開發過程：
簡單來說，有新的需求時，產品、開發、測試三方坐在一起，先由產品人員講解需求，解答開發與測試提出的疑問，三方對需求達成共識，即三方對需求的看法和達成的標準是一致的；
接下來，開發人員根據已有的設計、代碼等設計開發策略，測試人員分析並列出驗證的場景和標準；
開發人員與測試人員共同評審測試人員設計的驗證測試場景和標準，就此達成共識；
開發人員就此設計單元測試用例，測試人員設計驗收測試用例及測試數據；
開發人員完成開發，提交測試前先運行單元測試和已達成共識的驗證測試，驗證已完成的功能是否準確；
提交測試後，測試人員進行驗證，就發現的問題向開發人員反饋；
如果想引入工具，現已有基於FitNesse的驗收測試驅動開發 ，這個鏈接地址介紹的簡單易懂，沒必要再把人家的東西原樣的搬過來了。簡單說，就是在wiki中寫出需求並舉實例（也許應該說成是實例化需求吧），這些實例的列表可以通過某些手段直接與代碼接口相連，代碼完成後，但可“運行”這份需求文檔來驗證實現的是否符合標準。
ATDD的好處：
1.減少因爲溝通不一致，而返工的時間浪費；
2.提高交付產品的質量；
3.可快速進行自動化測試；
4.提升個人在團隊中的責任感；