技術性的故事
 
這裡有個很複雜得問題: 技術性的故事。或者非功能性項目,或者你想怎麼稱呼它都行。
 
每當某些人提到”非功能性需求”, 我就不禁咯咯地笑. 聽起來好像這個東西不是個功能 :o)
 
我所指的是需要完成,但是不屬於交付項目,和任何故事沒有直接的關連,並且不會帶給產品負責人直接的價值。
 
我們稱它做 "技術性的故事"。
 
例如:
•    安裝 continuous build server
      o    為什麼需要完成它:因為它可以節省開發人員許多時間,並且降低在循環結束時,大規模整合所帶來的風險。
•    撰寫系統設計概述
     o    為什麼需要完成它:因為開發人員常常忘記整體設計的方向,因此而寫出不一致的程式碼。所以需要有描述整體方向的文件,讓每個人都對設計有相同的認知。
•    重構DAO層的程式
      o    為什麼需要完成它: 因為DAO層的程式已經相當混亂,每個人都因為無謂的困惑,或是bug浪費不少時間。整理這些程式碼可以節省大家的時間,並且改進系統的強健性(robustness)。
•    升級 Jira (錯誤追蹤系統)
     o    為什麼需要完成它:目前的版本太多bugs,並且速度又慢。升級後可以節省大家的時間
 
這些故事是正常的狀況嗎? 或是這些任務和其他故事沒有任何關聯嗎? 誰要來排優先順序? 產品負責人需要參與其中嗎?
 
我們曾嘗試過許多不同的方法來處理技術性的故事。我們曾經把他們視為第一級的(first-class)故事,就像其他故事一樣。但是這樣不好,因為當產品負責人在排產品backlog的優先順序,它就好像拿蘋果和橘子在比較一樣。事實上,基於某些明顯原因,技術性的故事通常會是比較低的優先順序,因為有人可能會說: "喂,大夥們,我知道continuous build server是非常重要,但是我們先完成一些可以帶來收入的功能,之後我們再來處理這些技術性的補強,好嗎?" 
 
有些時候,產品負責人是正確的,但是,通常這只是少數狀況。我們得到的結論是,產品負責人通常無法勝任的,去做出這方面正確的判斷。所以我們會這樣做:
 
1)    試著避免技術性的故事。努力尋找一種方式,把技術性的故事轉換成一個正常的故事,和可衡量的商業價值。這樣的方法會幫助產品負責人,有更好的機會去做出正確的決定。
 
2)    如果我們不能把技術性故事轉換成一般的故事,看看是否這項工作能夠被當作另一項故事中的某個任務。例如: "重構DAO層"應該可以當作"編輯使用者"這個故事中的一項任務,因為這個故事包含到DAO層。
 
3)    如果以上兩種都不行,那就把它定義成一個技術性的故事,並且用另一個列表來放這些故事。讓產品負責人可以看到它,但不能編輯它。使用"投入程度"和"估算速度" 這兩個參數,來跟產品負責人協商,從Sprint中偷一些時間來完成這些技術性的故事。
 
我仍然認為技術性故事是一個很好的樣式,並且常常使用這樣的說法。較小的技術性故事會含在日常的工作中,而較大的故事會放到技術性的 backlog 中,讓產品負責人知道,可是是由團隊來管理它。團隊和產品負責人同意這樣的準則,像是 10-20% 的時間畫在技術性故事上面。不需要像投入程度或工時報告這樣精心設計的追蹤機制,只要憑感覺就好。在回顧會議時詢問, “在 sprint 中,我們大約花多少精力,在技術性故事上面,那感覺對嗎?”
 
下面是一個例子 (這個對話類似我們之前某一個Sprint規劃會議中的談話)。
•    團隊: "我們有一些內部的技術性工作需要被完成,我們要抽出10%的時間來處理它,也就是把投入程度從75%降到65%,你覺得可以嗎?"
•    產品負責人: "不行,我們沒有時間"
•    團隊: "好的‥那看一下上次的Sprint(所有人轉向看板上的生產率草圖)。我們估算的速度是80,但是我們只有30,對嗎?"
•    產品負責人:"相當正確,所以我們沒有時間做那些內部技術的工作,我們需要新的功能!"
•    團隊: "嗯,之所以我們速度變得這麼糟的原因,是我們花太多時間,試圖去弄出一個穩定的版本,以供測試使用。”
•    產品負責人: "嗯,然後呢?"
•    團隊: "好的,如果我們不做些事情,我們的速度還會繼續便糟下去"
•    產品負責人: "嗯,接下來呢?"
•    團隊: "所以,在這個Sprint中,我們打算大約花10%的時間,來建立一個continuous build server,這樣我們就可以擺脫整合時所帶來的痛苦。這樣接下來的每個Sprint,我們的速度大概會至少提高20%左右"
•    產品負責人: "哦,真的嗎? 那為什麼上個Sprint我們沒有這樣做?"
•    團隊: "嗯……因為你不要我們這樣做……"
•    產品負責人: "哦,嗯,好吧,這主意聽起來不錯,就這樣做吧。"
 
當然,另外一種選擇是把產品負責人排除在外,或是給他一個無法協商的投入程度。但是,沒有理由不去和產品負責人先達成共識,就自己蠻幹。
 
如果產品負責人能力比較強,並且通情達理(這點,我們比較幸運)。我會建議讓他盡可能知道所有事情,並且讓他決定所有的優先順序。透明化也是Scrum的核心價值,不是嗎? 
 
如果你和產品負責人, 無法老實談論有關於: 技術性故事, 品質和技術債的問題, 那你有很大的問題需要被解決!這個徵狀是在說明, 你發現到你自己刻意對產品負責人隱瞞訊息. 當然啦, 你不需要每次的對話都邀請產品負責人加入, 但是這樣的關係是根據於信任和尊重. 沒有這些的話,無論你打算建造什麼, 你不可能會成功.
 
 
錯誤追蹤系統vs. 產品 backlog
 
這裡有一個詭異的地方,Excel雖然是一個管理產品backlog的好工具,但是你還是需要一個bug追蹤系統,Excel可能不適合。我們使用的是Jira。
 
那我們如何把Jira上的問題帶到Sprint規劃會議中? 我的意思是,我們不能只注意故事,而忽略了這些bugs。
 
我們嘗試過幾種策略:
 
1)    產品負責人列印出Jira中,最高優先順序的項目,把他們帶到Sprint規劃會議中,把它們和其他故事一起貼到牆壁上(因此,就暗地裡說明了這些錯誤,和其他故事的比較後的優先順序為何)。
2)    產品負責人建立一些參考到Jira項目的故事。例如: "修理最嚴重的後端系統報表的bug,代碼是Jira-124,Jira-126,和Jira-180"。
3)    Bug的修復被考慮當做Sprint以外的工作,也就是,團隊保持較低的投入程度(例如50%),讓剩餘的時間來確保他們有空去修復錯誤。所以可以單純假設,團隊在每個Sprint中,會花一些時間來修復Jira上報告的錯誤。
4)    把產品的backlog放到Jura(也就是拋棄Excel)。把bugs和其他故事同等看待。
 
我們還沒有結論,那一種策略對我們最好。事實上,不同團隊,不同Sprint,會有不同的作法。我傾向使用第一個策略,它又好又簡單。
 
八年後我只能同意,沒有單一最佳的做法,上面每個做法,在某些環境下可能是很好的。保持實驗,直到你發現那個對你最好的。
 
 
Sprint規劃會議終於結束了!
 
哇啊,我從沒想過,Sprint規劃會議這一章會是這麼的長! 我想這應該會反映我的想法,Sprint規劃會議真的是Scrum中最重要的事。花很多精力在這裡是對的,這樣之後的工作才會比較簡單。
 
或者反之亦然 – 其他的東西準備好,則 sprint 規劃會議就只是小菜一碟。:o)
 
如果每個人都帶著微笑離開會議,並且隔天起來時也面帶微笑,或是在第一次每日會議中面帶微笑,這樣Sprint規劃會議就是成功的。
 
當然,所有事情都有可能會出現問題,但是至少你不能都歸咎於Sprint計畫 :o)

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()