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

曾經在不同情況看過、聽過會議中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，每天，開發團隊都能朝向客戶價值導向的方向前進，我覺得是很有意義的一件事。