iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 12
0

在 Molly 要開始講故事前,佳麗趕快問:”剛剛提到 User Story,真可以光靠『身為採購者,我需要找到符合規格性價比較高的商品,因為我是實用主義者』這樣的敘述就驅動開發團隊做出好產品?在公司強力要求,我已經很習慣利用 Use Case,可否在 Scrum 採用 Use Case”

Molly 雖然沒幹過所謂的系統分析師,但是參與過幾次採 Scrum 的專案,多少也有需求分析這樣的經驗。採Scrum的專案中每個開發成團隊的員都必須是多元,因為它的核心思維是團隊彼此合作解決問題,而非依照職務或是頭銜來分工。她看其他人也相當有興趣了解此問題,剛好吻合她期待大家多了解 Scrum,再聽故事。畢竟她的故事都是有深度的,她這樣定位自己。

"我有一個專案是 Product Owner,又兼開發團隊成員,再次強調我不推薦如此,這讓我吃了好多的苦。一開始大家也都說好要用 User Story 這工具,但是隨著專案進行,居然發展到後來有接近六十多個User Story,我們要跟客戶一起討論整個專案的需求,發現條列數十條的 Story,很難有全貌的視野。我們就採用 Use Case Diagram,不到一個小時,我們就把 五十多條的 User Story 轉換成一張Use Case Diagram。神奇的是當我們與客戶討論需求,他看著圖上的『用戶』這個Actor有連結到哪些 Use Case,馬上發現自己居然一直沒提出『身為用戶,我要知道我還有多少儲值餘額,以免讓我發生不足額,後續無法賺到獎勵』這樣的需求"

Use Case Diagram from Wiki

佳麗是Use Case專家,馬上發現一個小問題:”我猜你們雖然畫了Use Case Diagram,但沒有寫 Use Case Spec,通常像這麼顯著的需求,很容易在撰寫其他的 Use Case ,我猜原來可能會有『身為用戶,我要查詢累計獎勵額度』,如果有幫這個我虛構的Use Case寫Spec的過程中,很容易就會找到這個被遺漏掉的需求。”

“佳麗姐,你有接觸到那個專案喔?這麼神,的確是有那個你說是虛構的 Use Story。我如何從其他Use Case Spec 找到被忽略掉的需求?有技巧嗎?”

“通常分析師在寫使用案例,Use Case時會將所謂的 Happy Flow每個步驟寫得很順暢,只要多想一下,萬一發生意外時,系統該怎麼辦,通常會產生新的使用案例。這又是一個好大的話題,這樣好了,等專案進行時,有實際需求,我帶著大家寫寫 User Case Spec 好了,你們會發現還門檻還蠻低的。” 佳麗承諾。

Gavin 也馬上發現一個小問題:“我直覺 User Story 因為較無全面性的視圖,很難判斷每個 User Story 的規模大小,Sprint Plan會議裡要不要排進去某個 User Story,可能也是一個糾紛來源。但是如果是在UP,這個問題如何控制 Use Case 的規模方便排進 Iteration裡,是有個方法論。我知道佳麗也是很有經驗了,到時候也請佳麗跟大家分享。”

其他人對此領域的討論雖然也頗有興趣,但沒太多的深入,只能聽聽,無法太多交流,就當作學習。

會議隨著傍晚到來,準備要結束前,突然一通電話,RJ已經從歐洲趕回到公司了,要找 Gavin 聊聊。


上一篇
進一步了解UP, Scrum 差異
下一篇
哪個合適這個專案
系列文
UP, Scrum 與 AI專案23

尚未有邦友留言

立即登入留言