[30天快速上手TDD][Day 20]ATDD - User Requirement
前言
TDD 系列文章到這邊，只是獨立介紹了測試與重構，接下來要介紹的部分，則是筆者認為 TDD 整個流程中，影響成敗的一環，也就是從 user requirement break down 到 acceptance testing 。
TDD 可能可以幫助開發人員產出 high quality 的程式碼、物件、甚至模組，這些程式碼有高可維護性、可擴充的彈性，但使用者對程式碼的開發流程、工具、方法並沒有興趣，使用者只想滿足他們的需求，透過我們的系統提高生產力、解決問題，或是創造更多的利潤。
這也是這整個系列文章的主旨：一切都是為了滿足使用者需求而存在。
這篇文章會先從使用者需求管理的方式開始說明，也將常見的幾種方式，如 user story, use case ，以及功能清單三種，簡短地做個比較。
瞭解 user requirement 之後，後面我們才能開始進行 ATDD（Acceptance Test-Driven Development），因為 test cases 不會憑空產生。
註：本系列文章，會以 user story 為主軸，因為在 Scrum 中，透過 user story 來管理使用者需求，是一種輕量級、又相當具備彈性的方式。
介紹
如前言所說，接下來要介紹的部分，是筆者認為TDD整個流程中，影響成敗的一環，也就是從 user requirement break down 到 acceptance testing 。這也是一般文章或書籍中，比較少提及的部分，然而也是筆者認為大家對 TDD 在實務上應用，最缺少的一環。
正因為少了這一環， TDD 的起手式，會導致大家認為：TDD 不就只是個先寫測試的開發方式罷了。
當把 user requirement ，串到 ATDD ，輔以 BDD ，搭配 TDD ，一路打通任督二脈之後，在 Scrum 的流程中， Agile 的精神中， XP 的基礎建設上，整個開發流程，每個階段，每個角色的串接順暢，資訊基底一致，筆者才體會到了 TDD 的美妙之處。
也希望接下來幾篇文章，不會讓讀者們失望。
V-Model
一般軟體開發流程中，常見的 V-Model 如下圖所示：
(出處: http://www.testingexcellence.com/v-model/)
V-Model中，可以看到基本上開發流程的幾個階段就是：
-
使用者需求蒐集與分析 ( RA )
-
系統分析 ( SA )
-
架構/系統設計 ( SD )
-
程式開發 ( PG )
接著每一個階段有對應的測試來進行 verify 與確認執行無誤。
上面這張V-Model的圖，在後面幾篇文章中，會有不同的進化。
從 V-Model 中也可以看到，在軟體開發流程中，第一步基本上就是蒐集與分析使用者需求，而驗證系統是否符合使用者需求，則是透過 User Acceptance Testing 。這也是為什麼，筆者一直強調使用者需求管理與驗收測試，在 TDD 中這麼重要的原因。
因為：系統的存在目的，是為了滿足使用者需求，而不是給開發人員寫爽的。
因此在講 ATDD ，介紹 acceptance testing 之前，筆者想先介紹一下 user requirement 管理（或是稱為「定義」）的方式。
User Requirement
在需求蒐集的過程中，我們需要透過一種方式，將使用者的需求以某種方式紀錄或定義，其目的如下所示：
-
用來供整個團隊與使用者確認，是否這些需求滿足之後，這就是他們要的系統。（參與的人員，可能包括了使用者、 Product Owner 、需求分析師、系統分析師、開發人員、測試人員）
-
供分析人員、測試人員、開發人員可以繼續往下進行系統開發的共同基底資訊。
-
用來檢視目前完成進度與驗收範圍。
這邊則針對 user story , use case 與一般常見的功能清單來進行說明。
User Story
使用者故事（User Story）是一種輕量級且相當靈活的使用者需求管理方式。
在系統開發之前，整個團隊都應該思考預期的系統行為，是否能夠滿足使用者的需求，這就是 user story 可以幫助我們的地方。
透過相當簡單好懂的方式，用大家都懂的語言，記錄下來使用者的需求。（大家都喜歡聽故事，不是嗎？）
這邊舉出wiki上的幾種 user story 格式，供大家參考一下：（來源）
-
最原始的範本：點出role, goal跟benefit，格式如下：
"As a <role>, I want <goal/desire> so that <benefit>" -
Mike Cohn 覺得上面的 so that ...不一定需要存在，但重點是 goal 一定要出來，格式如下：
"As a <role>, I want <goal/desire>" -
Chris Matts 覺得，系統開發的重點在於可以給使用者帶來什麼價值，所以將 benefit 拉到最前面，格式如下：
"In order to <receive benefit> as a <role>, I want <goal/desire>" -
5 個 W 的格式，也就是人事時地物，格式如下：
"As <who> <when> <where>, I <what> because <why>."
筆者自己認為 1, 2, 3 在使用上都挺 OK ， 5 個 W 的格式則是太冗長。
例子如下圖所示：
User story 的撰寫重點在於，用最簡單的方式，讓大家都可以瞭解這個需求是什麼。通常會 focus 在 What ，而不是 How 。一旦 user story 關注地太詳細，可能會導致開發流程中無法因應需求的變化。也額外的花費了太多的成本在於可能會一直變動、重工的部分。
筆者自己習慣的方式：
- 簡單的點出，這個需求的目的，由誰使用，需要什麼樣的功能。
- 如果 user story 的描述有 10 句話，拿掉其中 3 句話，仍能清楚表達需求，能瞭解目的、功能、誰，那就把這些多餘的話拿掉。
- 確定使用者看的懂、測試人員看的懂、開發人員看的懂，可以用最簡單的資訊，來當作彼此之間溝通的基底，用最快的速度完成共識，或是在需求變更時，用最快的速度、最小的成本推翻它 （笑）
User story 因為簡短，所以蠻多團隊會準備一些小卡： user story card ，將 user story 寫在上面，這樣的方式有幾個好處：
- 篇幅有限，可以限制廢話太多。
- 實際物體形式存在，讓大家更有參與感與透明感。搭配白板，也很方便可以呈現狀態的轉移。
- 可在上面標記 priority 。
- 可在上面標記目前負責人員。
使用 user story 時，也有個 3C原則 可以參考一下：
- Card
- Conversation
- Confirmation
簡單的說， user story 記錄在 Card 上面，可以拿來當作溝通的基底，最後 user story 要搭配對應的 acceptance test cases ，才能說明這個 user story ，也就是這個不包含太多細節的使用者需求，該怎麼確認完成( done )。
User story 切記不要寫太長，把步驟或細節都列上去，只會失去其最主要的意義與目的，如下圖所示 （from wiki）：
-
簡短版
-
冗長版
讀者覺得上面兩個例子，哪一個好懂呢？哪一個有彈性呢？
想瞭解更多 user story 的眉角，建議大家可以參考 Mike Cohn 的 User Stories Applied ，（書上寫得相當完整，但許多都是實務上眉角的探討，並不適合當入門書）這邊因為篇幅限制，就不講太細太深，而是透過 user story 來當作 ATDD 的入口點。
Use Case
有透過 UML 來進行 SA/SD 的團隊（尤其是使用 MDA 的團隊），肯定對 Use Case 不會陌生。
Use Case 基本上分為兩段，一個是 Use Case Diagram ，如下圖所示：
透過連使用者都看的懂的圖示，來說明下列的元素：
- 系統邊界。
- 參與角色。
- 使用案例。
夠抽象，就會穩定。
然而， Use Case 有時還會搭配 Use Case Description/Use Case Specification ，其中包含了 pre-condition 與 post-condition ，如同上圖的註解所簡單點出的部分。也可以參考一下這篇文章的簡介：[系統開發生命週期]Use Case Diagram補完。
實際的 Use Case Description/Use Case Specification 其實要包含的東西相當多，讀者可以參考 wiki 上的說明：用例模版
Use Case Diagram 筆者也會使用，但使用的時機通常是拿來當作 SD 的開頭，而不是拿來當使用者需求管理的目的。例如：將 user story 透過一張 use case diagram 來圖示系統邊界、角色以及功能，三者之間的關係。
功能清單
這個在有導入 CMMI 的公司中，絕對是相當常見的東西，格式不一，但基本上就是長的像下圖所示：
格式不一，目的就是需求管理，驗收清單。記錄著將使用者抽象、漫無邊際的需求，轉化成一支一支的功能清單，並且針對該功能進行簡單的描述，可能還會延伸出拿來派工( task arrangement )，即可看出由誰負責開發、測試、驗收等等資訊。
功能清單主要拿來做需求管理，在瀑布式開發方式與 CMMI 所重視的精神中，需求是需要追蹤以及妥善的管理，這都是對的，但是很容易就變成：需求需要在一開始就明確定義清楚，才能往分析階段前進，全部分析完成，才能往開發階段前進。
每一次的需求異動，都是一整個流程階段狀態的改變，也就是重工的範圍是會影響整個團隊中不同角色，甚至把開發階段回推至先前的狀態。這也容易導致階段、角色之間的對立，導致開發團隊並非一整個團隊，並非全力的為了滿足使用者需求而開發，而是責任歸屬、互推皮球，食物鏈式的往下壓榨。
這些，在 Agile/CMMI 的比較或 Agile的宗旨 ，如下圖所示，已經講得很清楚了，筆者就不在這著墨太多。
三種方式簡單的歸納與比較
-
User story :
建立的成本最低，著墨的資訊也幾乎是最少，主要拿來溝通與管理使用者需求。需搭配 acceptance test cases 來確定如何可以認定為 done 。 -
Use case diagram 搭配 use case description :
一張圖可以快速的表象出人事物的關係，但只有圖容易太抽象，加上 description 則太冗重。建議可以選擇性的加入 pre-condition 與 post-condition 。好處當然是針對某一個使用案例，可以詳細的描述相關的步驟，但寫越多，需求異動的成本就越高。（後面文章有機會的話，會提到 pre-condition 與 post-condition ，可以對開發、測試上有什麼幫助） -
Function list :
傳統的開發方式，學習成本較低，就只是一種文書整理的方式。可讀性較差，只能拿來當作驗收、請款、派工、需求異動管理的一份文件，對系統從需求要繼續往下延伸至分析、設計、開發的幫助最低。
小結
在 TDD 的流程中，講究的是小步前進，快速回饋，擁抱變化，重視溝通，滿足需求。所以基本上建議搭配 Scrum 的流程、 Agile 的精神、 Extreme Programming 的基礎建設。
User story 在這三者中，最適合拿來當 TDD 的 user requirement 文件，因為建立容易、好懂、成本低，且可以表達使用者需求，搭配 acceptance test cases 來輔助後面的 ATDD 、 BDD ，進而進入開發人員最擅長的 TDD 循環。
所以，這系列文章，將會以 user story 為例子，說明完整的 TDD 開發流程。
試著擁抱變化，需求變更是系統進化的原動力，科技始終來自於人性。嚴禁需求異動，最終只會做出一個開發團隊自爽的產品，而不是滿足使用者需求的產品。
補充
補充一下一些 term 的全名：
- TDD: Test-Driven Development
- ATDD: Acceptance Test-Driven Development
- XP: Extreme Programming
參考資料
blog 與課程更新內容，請前往新站位置：http://tdd.best/
