隨著敏捷革命的興起，各種epic，user story，sprint等被產品圈極度推崇，敏捷要求最小的增量和迭代，應對可能發生的變革，扔掉一切包袱，輕裝前進，遇山爬山，遇水涉水， 根據實際情況及時調整方向。同時，他還提倡輕文檔，重用戶故事。
是的，“輕文檔”！ 輕視文檔，重視實際產出，文檔都是雞肋， 要文檔幹啥，只要能做出用戶滿意的產品來才是王道。做產品，很大一部分時間都用來寫文檔，現在敏捷竟然要求不要寫文檔，這麼好的偷懶的事情，怎麼能不大力推廣下呢。 於是忽，本汪以為掌握了敏捷的精髓，在團隊裡大力提倡可以當面溝通解決的事情，堅決不文檔。以前寫一大堆文檔，還要跟開發同學一條條過文檔，多麼費時費力啊。現在敏捷來了，當面說清楚就行，文檔，是該向你說拜拜的時候啦。
敏捷大法，沒讓我們失望，團隊開發效率顯著提升，有問題就當面溝通，每日站會，同步各自的工作成果，真的很管用。本汪因極力推廣敏捷也得到了團隊成員的一直好評。人生巔峰的感覺真好，可惜，高潮來的快，去的也快。 當我們做了三期sprint後 （二週為一個sprint，也就是六週以後），該來的坑還是來了。
敏捷，需要你不停的根據用戶反饋調整相關功能與配置， 以前在瀑布流中，所有的變更都會記錄文檔，歷史變革一清二楚。敏捷中，有些功能由於沒有相關文檔，並且來來回回改了好多次，本汪開始記不清當前線上的設置是怎麼樣的，回答用戶的問題也是常出現記憶錯亂，錯把上個版本的設置告訴給用戶。有時，作為一個產品，竟然需要開發同學去查代碼邏輯看目前線上的配置是怎麼樣的。 作為一個產品汪，當連你自己都不清楚產品目前的配置時，你其實已經失去了存在的意義。
產品，一個理應對產品瞭如指掌，把每個產品細節摩擦上千遍的人，竟然還需要向開發同學去詢問目前線上的功能是怎麼樣的？諷刺，無地自容，失落，充滿了本汪的內心，當時甚至懷疑自己得了老年痴呆症，為什麼這些最基本的產品細節都記不住。
該產品有六大功能板塊，每個板塊平均有30個功能點，每個功能點都有自己特定的邏輯，功能點之間並非完全獨立，有時功能點之間可能會因為邏輯衝突而採用非常規方式等，這樣粗略算下來，180個功能點，相互聯繫，相互制約，所有功能點都在不停的迭代進化中，如果不用文檔，光靠大腦門就能全部一字不漏的記下來，那該汪的大腦門該快比上計算機了。
虛驚一場，原來不是老年痴呆的鍋啊，為了跟上團隊開發節奏，本汪整整2個禮拜每天加班到11點回家，終於把缺失的文檔補上了。當然，為了迎接敏捷的理念，所有的文檔不拘泥於形式，只要能描述清楚需求和方案就算完成，有時文檔可以是一張流程圖，有時文檔可以是幾行文字描述的用戶故事，有時文檔也可以是自己隨手畫的一張草圖。 只要能記錄產品的功能進化歷程，以後最新的配置項，就算完成任務。
敏捷，它強調的是“輕文檔”，而不是“無文檔”。 再怎麼醜，再怎麼不規範，再怎麼不專業的文檔，只要能達到使用者的目的，他就是一個好文檔。而在“無文檔”狀態下，團隊失去了知識積累，丟失了經驗教訓，更無法掌握產品的最新狀態。
