Scrum and XP的實戰經驗 Ch4 (7) @ David Ko的學習之旅

Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html

技術性的故事

這裡有個很複雜得問題: 技術性的故事. 或者非功能性項目, 或者你想怎麼稱呼它都行.

我所指的是需要完成, 但是不屬於交付項目, 和任何故事沒有直接的關連, 並且不會帶給產品負責人直接的價值

我們稱它做 "技術性的故事"

例如:
# 安裝continuous build server
* 為什麼需要完成它: 因為它可以節省開發人員許多時間, 並且降低在循環結束時, 大規模整合所帶來的風險

# 撰寫系統設計概述
* 為什麼需要完成它: 因為開發人員常常忘記整體設計的方向, 因此而寫出不一致的程式碼. 因此需要有描述整體方向的文件, 讓每個人都對設計有相同的認知.

# 重構DAO層的程式
* 為什麼需要完成它: 因為DAO層的程式已經相當混亂, 每個人都因為無謂的困惑或是bug浪費不少時間. 整理這些程式碼可以節省大家的時間, 並且改進系統的強健性(robustness).

# 升級 Jira (錯誤追蹤系統)
* 為什麼需要完成它: 目前的版本太多bugs, 並且速度又慢. 升級後可以節省大家的時間

這些故事是正常的狀況嗎? 或是這些任務和其他故事沒有任何關聯嗎? 誰要來排優先順序? 產品負責人需要參與其中嗎?

我們曾嘗試過許多不同的方法來處理技術性的故事. 我們曾經把他們視為第一級的(first-class)故事, 就像其他故事一樣. 但是這樣不好, 因為當產品負責人在排產品backlog的優先順序, 它就好像拿蘋果和橘子在比較一樣. 事實上, 基於某些明顯原因, 技術性的故事通常會是比較低的優先順序, 因為有人可能會說: "喂, 大夥們, 我知道continuous build server是非常重要, 但是我們先完成一些可以帶來收入的功能, 之後我們再來處理這些技術性的補強, 好嗎?"

有些時候, 產品負責人是正確的, 但是, 同常這只是少數狀況. 我們得到的結論是, 產品負責人通常無法勝任的, 去做出這方面正確的判斷

所以我們會這樣做:
1) 試著避免技術性的故事. 努力尋找一種方式, 把技術性的故事轉換成一個正常的故事, 和可衡量的商業價值. 這樣的方法會幫助產品負責人, 有更好的機會去做出正確的決定.

2) 如果我們不能把技術性故事轉換成一般的故事, 看看是否這項工作能夠被當作另一項故事中的某個任務. 例如: "重構DAO層"應該可以當作"編輯使用者"這個故事中的一項任務, 因為這個故事包含到DAO層.

3) 如果以上兩種都不行, 那就把它定義成一個技術性的故事, 並且用另一個列表來放這些故事. 讓產品負責人可以看到它, 但不能編輯它. 使用"投入程度"和"估算速度" 這兩個參數, 來跟產品負責人協商, 從sprint中偷一些時間來完成這些技術性的故事.

下面是一個例子 (這個對話類似我們之前某一個sprint規劃會議中的談話)

# 團隊: "我們有一些內部的技術性工作需要被完成, 我們要抽出10%的時間來處理它, 也就是把投入程度從75%降到65%, 你覺得可以嗎?"
# 產品負責人: "不行, 我們沒有時間"
# 團隊: "好的...那看一下上次的sprint(所有人轉向看板上的生產率草圖). 我們估算的速度是80, 但是我們只有30, 對嗎?"
# 產品負責人: "相當正確, 所以我們沒有時間做那些內部技術的工作, 我們需要新的功能"
# 團隊: "嗯, 之所以我們速度變得這麼糟的原因, 是我們花太多時間, 試圖去弄出一個穩定一致的版本, 以供測試使用.
# 產品負責人: "嗯, 然後呢?"
# 團隊: "好的, 如果我們不做些事情, 我們的速度還會繼續便糟下去"
# 產品負責人: "嗯, 加下來呢?"
# 團隊: "所以, 在這個sprint中, 我們打算大約花10%的時間, 來建立一個continuous build server, 這樣我們就可以擺脫整合時所帶來的痛苦. 這樣接下來的每個sprint, 我們的速度大概會至少提高20%左右"
# 產品負責人: "哦, 真的嗎? 那位甚麼上個sprint我們沒有這樣做?"
# 團隊: "嗯...因為你不要我們這樣做...."
# 產品負責人: "哦, 嗯, 好吧, 這主意聽起來不錯, 就這樣做吧"

當然, 另外一種選擇是把產品負責人排除在外, 或是給他一個無法協商的投入程度. 但是, 沒有理由不去和產品負責人先達成共識, 就自己蠻幹.

如果產品負責人能力比較強, 並且通情達理(這點, 我們比較幸運). 我會建議讓他盡可能知道所有事情, 並且讓他決定所有的優先順序. 透明化也是scrum的核心價值, 不是嗎?

錯誤追蹤系統 v.s. 產品backlog

這裡有一個詭異的地方, Excel雖然是一個管理產品backlog的好工具, 但是你還是需要一個錯誤追蹤系統, Excel可能不適合. 我們使用的是Jira.

那我們如何把Jira上的問題帶到sprint規劃會議中? 我的意思是, 我們不能只注意故事, 而忽略了這些錯誤

我們嘗試過幾種策略:

1) 產品負責人列印出Jira中, 最高優先順序的項目, 把他們帶到sprint規劃會議中, 把他們和其他故事一起貼到牆壁上(因此, 就暗地裡說明了這些錯誤和其他故事的, 比較後的優先順序為何)

2) 產品負責人建立一些參考到Jira項目的故事. 例如: "修理最嚴重的後端系統報表的錯誤, 代碼是Jira-124, Jira-126, 和Jira-180"

3) Bug的修復被考慮當做sprint以外的工作, 也就是, 團隊保持較低的投入程度(例如50%), 讓剩餘的時間來確保他們有空去修復錯誤. 所以可以單純假設, 團隊在每個sprint中, 會花一些時間來修復Jira上報告的錯誤.

4) 把產品的backlog放到Jura(也就是拋棄Excel). 把錯誤(bugs)和其他故事同等看待

我們還沒有結論, 那一種策略對我們最好. 事實上, 不同團隊, 不同sprint, 會有不同的作法. 我傾向使用第一個策略, 它又好又簡單.

Sprint規劃會議終於結束了