.NET Walker

問題 這幾天在上 敏捷開發與DevOps 課程時，學員問到了一個非常有意思的問題。學員這麼說： “Mike Cohn這類專家，對於User Story抱持一種用完可丟的想法（尤其是用紙本卡片時），但是團隊總會覺得有些討論過的需求沒有在 work item 之外的地方記錄時，只靠記憶力是很不可靠的。想請問老師對於紀錄專案諸項功能的需求文件，有沒有建議的作法?” 這個問題本質上，跟之前很多問到敏捷開發要不要寫文件，其實是有點類似的討論議題。 這個議題的緣由是因為，敏捷宣言中有這麼一條 “ 可用的軟體 重於 詳盡的文件 ” : 自此，開發人員分成了兩派。 一派人員認為這是指文件不需要繁瑣，但並非完全不寫文件的意思。(畢竟宣言中說的是 重於 ) 另一派人員則認為，能用的軟體才是重點，程式碼本身應該就要有高可讀性，讓程式碼足以表達傳統的系統文件想要說明的事情即可，其他文件寫了以後也是會變，寫多了根本沒用。 和以前不同，最近這幾年上課時，我都不太想挑戰大家既有的想法。但既然同學問到了，我就說說我的看法。 真需要文件? 首先，僅用 文件 兩字，來表達軟體開發中所需要記錄下來的東西，其實是不精確的。即便再怎麼概括的分類，至少也能將軟體開發的相關文件分成兩大類。 一種 是用來在開發行為發生前，描述需求的文件，這一類的文件主要是讓開發人員能夠清楚明白該怎麼開發用的； 另一種 則是在開發完成後，用來描述系統建立過程與現況的，這種文件主要是讓後續的維護人員(當然也包含開發團隊自己或後續接手加工的人)，可以方便進行系統維護或功能添加用的。 當天學員所提到的 User Story，指的是前者。你會發現其實這一類的文件，不管是 User Story, Acceptance Critiria, 或是傳統的 Requirement Spec…在敏捷開發認為需求會持續不斷改變的這個前提下，這種文件的有效性其實極低，從寫下的那一刻起，就注定了它會淘汰和快速失效的命運。 因此，你會發現敏捷開發的思路上，對於 “寫” 這類文件，實在沒什麼興趣。所以寫這類文件時，往往是愈精簡愈好，User Story 就是這類的產物， 它的主要目的也不是 “紀錄” 或 “存留”，而是 “引發溝通” 。 User Story 寫出來的東西也不是聖旨，就只是當下那一刻，我們 “對需求的理解”