歷史背景
起初, 是在 Ward Cunningham 在 A Pattern Language of Competitive Development (http://c2.com/ppr/episodes.html) 一文中提到這個概念. 然後由Martin Fowler 把它命名為 spec by example (http://martinfowler.com/bliki/SpecificationByExample.html). XP 團隊利用這種方法來進行客戶的驗收測試.
後來 Ward Cunningham 還發展出 FIT 來進行自動化. 同一時期, Brian Marick, 在 Agile testing decisions: tests and examples (http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2) 也有提到這件事情.
什麼是實例化需求
它是一種協同合作的方式, 用來定義軟體的需求和商業導向的測試. 它會利用實際範例(example or test cases), 來說明和確定所要做的事情的範圍. 而不是只用抽象的文字敘述(statement), 來說明軟體的行為.
它通常被使用在敏捷開發環境中, 尤其是使用 BDD(Behavior-Driven Development) 做法的團隊中. 特別是針對複雜度很高, 特別重要的元件, 或是大型的專案. 可以用來確保需求和功能測試, 能夠有效地被管理.
感想
如果根據上面實例化需求的定義, 個人覺得有以下重點
1. 協同合作
個人覺得實例化需求是一種溝通方式, 要讓大家有共同的認知, 知道這個功能最後應該要怎樣運作. 如果能夠自動化, 會是大大的加分.
2. 是不是敏捷並不重要
實例化需求是不是要和敏捷方式搭配並不重要. 因為問題的重點是在於需求不清, 如果需求可以儘早釐清, waterfall 或是 agile 都可以把事情處理得不錯.
3. 不一定所有需求都要實例化
80/20 法則永遠都是對的. 先早最重要, 最複雜的項目開始, 並且做任何事情都要付出代價, 才能得到成果. 只是有些代價你可能不一定能承受. 雖然有共識很重要, 但是共識是需要花時間的, 不可能無限制付出這樣的代價.
我想實例化需求是一個很好的工具, 值得團隊來學習使用, 但是也需知道世上沒有銀製子彈, 必須知道每個工具的精華和重點是什麼, 並且搭配團隊文化, 適當調整來導入, 這樣才能水到渠成, 真正發揮作用.
留言列表
