iT邦幫忙

DAY 20
3

30天快速上手TDD系列 第 20

[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來管理使用者需求,是一種輕量級、又相當具備彈性的方式。

上一篇文章:[Day 19]Refactoring - The End is the Beginning
本系列文章專區
@前言
TDD系列到這邊,只是獨立介紹了測試與重構,接下來要介紹的部分,則是筆者認為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中,可以看到基本上開發流程的幾個階段就是:

  1. 使用者需求蒐集與分析 (RA)
  2. 系統分析 (SA)
  3. 架構/系統設計 (SD)
  4. 程式開發 (PG)

接著每一個階段有對應的測試來進行verify與確認執行無誤。

(註:上面這張V-model的圖,在後面幾篇文章中,會有不同的進化)

從V-model中也可以看到,在軟體開發流程中,第一步基本上就是蒐集與分析使用者需求,而驗證系統是否符合使用者需求,則是透過User Acceptance Testing。這也是為什麼,筆者一直強調使用者需求管理與驗收測試,在TDD中這麼重要的原因。

因為:系統的存在目的,是為了滿足使用者需求,而不是給開發人員寫爽的。

因此在講ATDD,介紹Acceptance Testing之前,筆者想先介紹一下user requirement管理(或是稱為「定義」)的方式。

@User Requirement
在需求蒐集的過程中,我們需要透過一種方式,將使用者的需求以某種方式紀錄或定義,其目的如下所示:

  1. 用來供整個團隊與使用者確認,是否這些需求滿足之後,這就是他們要的系統。(參與的人員,可能包括了使用者、Product Owner、需求分析師、系統分析師、開發人員、測試人員)

  2. 供分析人員、測試人員、開發人員可以繼續往下進行系統開發的共同基底資訊

  3. 用來檢視目前完成進度與驗收範圍

這邊則針對user story, use case與一般常見的功能清單來進行說明。

@User Story
使用者故事(User Story)是一種輕量級且相當靈活的使用者需求管理方式。

在系統開發之前,整個團隊都應該思考預期的系統行為,是否能夠滿足使用者的需求,這就是user story可以幫助我們的地方。

透過相當簡單好懂的方式,用大家都懂的語言,記錄下來使用者的需求。(大家都喜歡聽故事,不是嗎?)

這邊舉出wiki上的幾種user story格式,供大家參考一下:(來源

  1. 最原始的範本:點出role, goal跟benefit,格式如下:
    "As a <role>, I want <goal/desire> so that <benefit>"

  2. Mike Cohn覺得上面的 so that...不一定需要存在,但重點是goal一定要出來,格式如下:
    "As a <role>, I want <goal/desire>"

  3. Chris Matts覺得,系統開發的重點在於可以給使用者帶來什麼價值,所以將benefit拉到最前面,格式如下:
    "In order to <receive benefit> as a <role>, I want <goal/desire>"

  4. 5個W的格式,也就是人事時地物,格式如下:
    "As <who> <when> <where>, I <what> because <why>."

(註:筆者自己認為1,2,3在使用上都挺OK,5個W的格式則是太冗長)

例子如下圖所示:

注意事項:
user story的撰寫重點在於,用最簡單的方式,讓大家都可以瞭解這個需求是什麼。通常會focus在What,而不是How。一旦user story關注地太詳細,可能會導致開發流程中無法因應需求的變化。也額外的花費了太多的成本在於可能會一直變動、重工的部分。

筆者自己習慣的方式:

  1. 簡單的點出,這個需求的目的,由誰使用,需要什麼樣的功能。

  2. 如果user story的描述有10句話,拿掉其中3句話,仍能清楚表達需求,能瞭解目的、功能、誰,那就把這些多餘的話拿掉。

  3. 確定使用者看的懂、測試人員看的懂、開發人員看的懂,可以用最簡單的資訊,來當作彼此之間溝通的基底,用最快的速度完成共識,或是在需求變更時,用最快的速度、最小的成本推翻它 (笑)

User story因為簡短,所以蠻多團隊會準備一些小卡:user story card,將user story寫在上面,這樣的方式有幾個好處:

  1. 篇幅有限,可以限制廢話太多

  2. 實際物體形式存在,讓大家更有參與感與透明感。搭配白板,也很方便可以呈現狀態的轉移

  3. 可在上面標記priority

  4. 可在上面標記目前負責人員

使用user story時,也有個3C原則可以參考一下:

  1. Card
  2. Conversation
  3. Confirmation

簡單的說,user story記錄在Card上面,可以拿來當作溝通的基底,最後user story要搭配對應的acceptance test cases,才能說明這個user story,也就是這個不包含太多細節的使用者需求,該怎麼確認完成(done)。

User story切記不要寫太長,把步驟或細節都列上去,只會失去其最主要的意義與目的,如下圖所示 (from wiki):

  1. 簡短版

  2. 冗長版

讀者覺得上面兩個例子,哪一個好懂呢?哪一個有彈性呢?

想瞭解更多user story的眉角,建議大家可以參考Mike Cohn的User Stories Applied,(書上寫得相當完整,但許多都是實務上眉角的探討,並不適合當入門書)這邊因為篇幅限制,就不講太細太深,而是透過user story來當作ATDD的入口點。

@Use Case
有透過UML來進行SA/SD的團隊(尤其是使用MDA的團隊),肯定對Use Case不會陌生。

Use Case基本上分為兩段,一個是Use Case Diagram,如下圖所示:

透過連使用者都看的懂的圖示,來說明:

  1. 系統邊界
  2. 參與角色
  3. 使用案例

夠抽象,就會穩定。

然而,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的宗旨,如下圖所示,已經講得很清楚了,筆者就不在這著墨太多。

@三種方式簡單的歸納與比較

  1. User story:
    建立的成本最低,著墨的資訊也幾乎是最少,主要拿來溝通與管理使用者需求。需搭配acceptance test cases當確定怎麼樣可以認定為done。

  2. Use case diagram搭配use case description:
    一張圖可以快速的表象出人事物的關係,但只有圖容易太抽象,加上description則太冗重。建議可以選擇性的加入pre-condition與post-condition。好處當然是針對某一個使用案例,可以詳細的描述相關的步驟,但寫越多,需求異動的成本就越高。(後面文章有機會的話,會提到pre-condition與post-condition,可以對開發、測試上有什麼幫助)

  3. 功能清單:
    傳統的開發方式,學習成本較低,就只是一種文書整理的方式。可讀性較差,只能拿來當作驗收、請款、派工、需求異動管理的一份文件,對系統從需求要繼續往下延伸至分析、設計、開發的幫助最低。

@小結
在TDD的流程中,講究的是小步前進,快速回饋,擁抱變化,重視溝通,滿足需求。所以基本上建議搭配Scrum的流程、Agile的精神、Extreme Programming的基礎建設。

User story在這三者中,最適合拿來當TDD的user requirement文件,因為建立容易、好懂、成本低,且可以表達使用者需求,搭配acceptance test cases來輔助後面的ATDD、BDD,進而進入開發人員最擅長的TDD循環。

所以,這系列文章,將會以user story為例子,說明完整的TDD開發流程。

註:擁抱變化,需求變更是系統進化的原動力,科技始終來自於人性。嚴禁需求異動,最終只會做出一個開發團隊自爽的產品,而不是滿足使用者需求的產品。

@補充
補充一下一些term的全名:

  1. TDD: Test-Driven Development
  2. ATDD: Acceptance Test-Driven Development
  3. XP: Extreme Programming

上一篇
[Day 19]Refactoring - The End is the Beginning
下一篇
[Day 21]ATDD - Acceptance Testing
系列文
30天快速上手TDD31

2 則留言

0
ted99tw
iT邦高手 1 級 ‧ 2012-10-28 20:14:13

好爽好過癮的文章呀,簡直是比鑽石更值得的恆久收藏品!!!

哭哭哭

0
pajace2001
iT邦研究生 1 級 ‧ 2012-11-05 20:52:27

一直以來都是以Use case為主..迫不及待想找個範例來用 user story 來試試看了~~
不過我有3個小疑問:疑惑
1.user story會不會很容易走火入魔變成只見樹木不見林的窘境呢?
2.是不是一開始就會有一大堆的小卡片,那要怎麼整理呢?
3.每個 user story 是不是也會跟 use case 一樣可以平行開發呢?

最後還是要感謝前輩分的分享阿~~自己看書有時候真的是要看很久才看得懂
(因為作者都沒寫 user story 嗎? 噗哧....偷笑..我沒言外之意..哈哈)

就是91 iT邦研究生 4 級 ‧ 2012-11-05 21:12:06 檢舉

第一點的部分,不會,因為Scrum team基本上是隨時會sync進度,持續的回饋。寫好一小段程式,就應該能跟PO確認是不是他要的,如果不是,就迅速調整。所以,只怕林子太大,不會看不見林。

第二點的部分,Scrum也有很多電子/e化的系統輔助記錄這些東西,如果都有寫成可閱讀的測試案例/feature/scenario,那最後看這個可以執行的測試案例,跟驗收最後的系統即可。根本不需要那種冗長、沒啥意義的function list或check list。

第三點的部分,當然可以,設計user story在上面的INVEST原則中有提到,第一條就是獨立。user story彼此之間要能獨立,既然獨立沒有相依性,當然就可以平行開發囉。

pajace2001 iT邦研究生 1 級 ‧ 2012-11-06 20:26:26 檢舉

原來如此~~筆記
謝謝

我要留言

立即登入留言