短衝目標 (Sprint Goal) 是怎麼產生的?

2018/09/02閱讀時間約 2 分鐘
曾經在不同情況看過、聽過會議中3種短衝目標產生的方式:
1) 產品負責人導向
產品負責人在規劃會議一開始先和團隊說一下現況,然後說 “這個sprint的目標是完成story A, B, C“

2) 開發團隊導向
產品負責人向團隊展示排好優先順序的產品待辦清單,先讓團隊選出這個sprint 可以完成的部分story, 然後根據團隊選出的那些story能帶出的重要價值,訂出短衝目標。

3) 產品負責人與開發團隊協作導向
產品負責人說出這個sprint 需要產出的概略目標 (例如: 這個sprint我們要完成遊戲的基本射擊與和敵人的互動),然後讓團隊從產品待辦清單中選story,團隊以那些選出的story達成產品負責人的目標。 團隊會盡力挑選story達成目標,但目標的範圍是可以討論的,從產品完成度的高低到價值的設定。

我不覺得這3種方式有哪一種特別”正確”,或是哪一種特別好。這3種都是團隊和產品負責人可以有的選項,根據不同的狀況,產品負責人可以做不同的決定。前提是產品負責人和團隊都很清楚目前的情況,知道做了這個決定會把產品帶到哪個方向,有意識的選擇某一個方式。

關於scrum為什麼要訂短衝目標,我有2個想法:
1) 確保團隊每個人都知道這個sprint需要交付給客戶的價值,在sprint的每一天都方向清楚地朝向目標前進。

2) 團隊產出效能衡量的標準
提到 ”產出效能”,可能大家心裡都有很多選項: 程式碼越多產出效能越高、程式碼越”乾淨”產出效能越高... 等等。 這些都很重要,但是我們的軟體開發工作應該是以客戶價值導向對吧? 而最瞭解客戶的產品負責人在設定短衝目標時有較高的權重,我們為何不試試以每個短衝目標的達成率來衡量團隊的產出效能? 我也覺得乾淨易維護的程式碼很重要,最美好的狀態是兩者兼顧。 但當兩者無法兼顧的時候,我會覺得,先重視帶給客戶的價值,會是一個比較能讓產品生存的選擇。


軟體開發工作既複雜也無法完美預測。

在每個sprint,每天,開發團隊都能朝向客戶價值導向的方向前進,我覺得是很有意義的一件事。

    贊助支持創作者,成為他繼續創作的動力吧!
    如果要發表留言,請先登入註冊會員
    打造你的創作天地
    在這裡尋找共鳴,與方格子的 35 萬格友分享觀點與生活。
    領取見面禮
    只要設定追蹤作者,即可享有 48小時
    Premium 閱讀權限