在 2006 的 CIO Magazine 中提到, 71% 的專案會失敗, 是歸咎於需求沒有管理好. 因此如何得到有品質的需求, 將會決定專案的生死.
 
 
 
 
在傳統瀑布式的開發中, 須先有人須作需求訪談, 然後將得到的內容, 以文件記錄下來, 交給偉大的開發人員繼續處理, 以期待能夠開發出客戶想要的系統. 
 
可是, 正如 Mike Cohn 所說的: Software requirements is a communication problem. 也就是說, 要溝通才能得到較好的需求. 文件只是其中一種溝通方式. 只用這種方式溝通, 是無法加速 SA, RD, 和 QA 的工作. 你不但要等上游的人寫好, 寫完後可能還看不懂, 要問問題還要等一段時間. 這不是一個慘字能了
 
那敏捷如何處理需求的問題呢?
 
敏捷對於需求, 是想要以彈性和方便溝通的方式, 來逐步收集和釐清產品的需求.
 
在這樣的思維下, 各位大神提出了不同的做法, 像是
User Story, Cohn
Agile Product Canvas, Pichier
Scaled Agile Framework SAFe, Leffingwell
Acceptance Test Driven Development, Gartner, Koskela
Agile Modeling, Ambler
Spec by example, Adzic
Discover and Deliver, Gottesdiener
Impact Mapping, Adzic
 
這麼多方法也不用太緊張,  其實他們最主要的目的, 是要幫助大家有共同的瞭解. 也就回歸 Cohn 說的, 需求就是溝通的問題, 如何增強共識, 就是各種方法想要處理的.
 
幸好有人 Daniel 和 Jackson 試著把某些東西串起來, 你可從下面這個圖表了解一二. 
 
 
1. Impact Mapping
先從 why 開始著手, 知道目標(why)是什麼, 要影響哪些角色(who), 以及想要產生什麼 outcome (how/what).
 
工程師最在意的, 是為什麼 PM 要做這個功能, 有了這個 why, who, how , what 的對應關係, 工程師可以知道為何而戰, PM 也可以把思考邏輯攤開來, 讓大家一起討論.
 
 
2. Story Mapping
把系統要提供的解法, 以故事方式, 依時間軸順序來描述. 
 
有時間順序的故事, 對於很多人來說, 會比較容易暸解. 否則以前條列式的功能列表, 一方便很難知道全貌, 另一方面也很難知道大概會怎麼用. 因為太片段, 太瑣碎了.
 
 
3. User Story/ATDD/Spec by example
把每個功能使用情境, 案例, 或驗收標準給敘說出來. 這樣 SA, RD, QA 才不會各說各話, 這樣這個功能的邊界才能被描繪出來. 
 
 
這些工具都有些共同的特徵:
 
1. 很容易被產生: 大多是手寫外加便利貼可以完成, 而非要正式文件.
2. 釐清誤會: 通常是用來幫助某幾方有共同的瞭解
3. 方便共同產生: 這些都是可以大家聚在一起討論產生的, 讓大家在第一時間就有相同的資訊.
 
 
所以, 敏捷需求的做法, 只是著重於加強溝通的便利性和有效性. 因此, 如果你原先的做法也是讓溝通很方便, 我想也是符合 agile 的精神. 誰說換成敏捷, 就一定要換新作法呢? 重點在精神符不符合.
 
 
arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()

    E-mail轉寄