進度條

[Agile and scrum] 如何準確拿捏開發 Scope (範圍)?你做好 Refinement Meeting (精煉會議)了嗎?

還在抱怨 Refinement meeting 流於形式?不如強化落實 acceptance criteria 來掌握開發節奏吧!

作者: Vincent Ke 更新日期:

[Agile and scrum] 是進度條小編,根據在各種隕石需求與組織改組,以及交織著 run scrum 的經驗中,堆疊出來的經驗分享系列文,但詳閱說明書前小編先聲明,沒有最好的 scrum,只有最適合組織當下目標中的 scrum。也許這個方法不見得可以對你目前的問題對症下藥,但可以透過小編走過的坑,讓各位同學不再重蹈歷史的覆轍。

 

延伸閱讀:瀑布式還是隕石開發法?那不如試試看迭代開發吧!


 

校正小編補充:

本文原稿根本就是完美的晶晶體範例(抱怨),但是可惜的是科技業裡,不管是本土或是外國公司真的就是直接中英參雜(至少台灣是這樣)。所以校正小編會盡量補上英文翻譯。

Run 執行
Agile 敏捷開發
Scrum 敏捷開發的一種方法
 

 

pexels-ketut-subiyanto-4560150.jpg

 

為什麼在敏捷運作的框架之中,還是無法精準的掌握開發 Scope;為什麼已經定義好的 Story,卻總是在交付前夕又有著無限膨脹的需求呢?


這時候先捫心自問一下各位 PO (Product Owner, 產品負責人) 和 Scrum Master,是否一下有確實的招開 Refinement meeting,並且拿到該會議預期的交付結果(acceptance criteria) 呢?

 

校正小編補充:

Scope 範圍
Story 故事

軟體開發要先把功能拆解程小範圍,拆解功能可以使用故事的方式來分拆。
例如用使用者點擊加入購物車這段流程,而非單一購物車按鈕功能來敘述。

延伸閱讀:在寫程式之前,請先搞清楚這程式到底是要解決什麼問題(user story 概念介紹)


product owner = P.O. 產品負責人, Scrum 的團隊角色之一
scrum master 一般不翻譯, Scrum 的團隊角色之一
refinement meeting 精煉會議, 本文主題接下來會解釋。
acceptance criteria 驗收標準,這邊指的是「事先定義的完成」 (中文WIKI)

 

pexels-andrea-piacquadio-3760067.jpg

 

先來看一下 Scrum.org 對 Refinement meeting 的說明吧!
官方說明連結


若從定義中開始解釋,Refinement 最重要的 outcome,就是要對 Backlog 裡面待實作的項目,讓 PO 有一個公開的場合來做故事說明。但若只是說說故事,最後這個會議就會流於形式,而這也是很多 Scrum team 常會犯的錯誤

 

在 Scrum guide 的說明中,也明確地提到 Refinement meeting 最重要的,就是得到 The act of adding detail, estimates and order items in the Product Backlog所以一但沒有對需要 refine 的項目明確的開出 subtask 任務細項(或稱 action item 執行項目),並依據其內容估出 efforts (目標成果),那一切也是白搭。


 

校正小編補充:

Scrum.org 官方網站,org 通常表示無營利機構
Refinement 提煉,精煉 (名詞)
outcome 產出
backlog 待做事項,待出貨訂單
team 團隊
guide 指引,指南
act 動作
detail 細節
estimate 評估
order 訂單
order item 訂單商品
product 產品

The act of adding detail, estimates and order items in the Product Backlog 可以翻譯成
對於待做事項的細節評估以及增減待做工作事項。


refine 提煉 (動詞)
action 行動
subtask 子任務,任務細項
efforts 努力後的成果,專案的目標成果

延伸閱讀:你有刪除功能的勇氣嗎? 別人程式有所以我們也要有?(Task 概念介紹)

 

 

而在小編的經驗裡,會把待 refine 的項目,分成三個階段:
 

1. 精煉使用者故事(Refine user story
簡單來說就是可行性評估,如果需求已經夠具體,可以跳過。
做完後需要產出:待辦事項 (checklist)
 

2. 精煉提案 (Refine proposal)
初步的產出評估,如果需求已經具體到可以直接寫進規格書,也可以跳過
做完後需要產出:待辦事項 (checklist), 粗估的細項任務 (rough subtask), 目標成果 (efforts)


3. 精煉規格書 (Refine spec)
實作的產出結果評估
做完後需要產出:細項任務 (subtask), 目標成果 (efforts)
 

 

 

在 PO 拿到的需求之中,有些可能過於明確,可以直接開出 spec 做 refine,但我們不能把握每一次客戶都可以精準地說出期望與目標,但如果一開始 PO 就把模糊的需求硬幹,那可能就會犯了 RD 的大忌,所以通常小編會在第一步時,就先把 user story 跟 background 就先帶回團隊分享,在需求不夠具體前,讓團隊共同 review 這個需求可能帶來的風險與 side effect。


 

校正小編補充:

spec 專案、產品規格書
user story 使用者故事
background 產品背景
review 評論
side effect 副作用
rough 粗糙的


 

pexels-victor-freitas-841130.jpg

 

但若只是分享故事,這樣的會議也當然不夠聚焦,所以在開出 subtask 之前,可以先讓團隊針對需求提出各種問題,並透過待辦事項(checklist)的方式,讓團隊的問題可以被確實記錄,讓 PO 在草擬具體提案前,可以先避開一些雷坑;一但提案經客戶同意後,就可以進入階段二,讓團隊依據提案來開出 rough subtasks & efforts,當然如果還是要釐清問題也可透過待辦事項紀錄;等到一切明朗化,可以寫出 spec 後,開出真正的 subtasks 時評估出的 efforts,才是準確不失真的。

 

 

而開出 subtasks 和 efforts 還有一個好處,就是讓 PO 和團隊先對這個 story 的大小有一定程度的掌握,未來跟客戶談判時程與優先順序(Priority)時,才會有一個依據和準則。

 

那一個好的【精煉會議】要開多久?這就要依據團隊的大小以及需求的量來斟酌,如果需求多且頻繁,那不如就留個一個下午的空檔,甚至是一天的時間,在 【精煉會議】中確認代辦事項, 並把開 subtasks 以及估 effrots 的時間留在會議後大家各自討論,也是一個不錯的方式,只要期許在 deadline 到期時間前完成交付成果,加上團隊的自律,相信一定是可以完成 scrum guide 的目標和期許。但如果是那種需要實驗性質的 story,例如實驗 app 在新裝置上的可行性,那還是建議另外開一個評估實作票 ticket 放到 planning (計畫中的項目)吧!

 

校正小編補充:

deadline 死線, 到期時間
ticket 票,英文上常用 ticket 表示一張小紙張,可能是罰單,或是記錄某個項目的代辦事項
planning 規劃中,這邊指的是專案規劃中有一個欄位叫做「規劃中」
 

 

brown-wooden-opened-door-shed-2869565.jpg

 

所以如果你還在抱怨 【精煉會議】Refinement meeting 流於形式?不如強化落實 acceptance criteria 來掌握開發節奏吧,不要害怕浪費時間,畢竟共同討論的結果,只要產出明確,絕對不是浪費!

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧