Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Sprint週期 v.s. 驗收測試週期
在完美的Scrum世界中, 你不會需要驗收測試階段, 因為每個Scrum團隊, 在每次sprint結束後, 會發佈一個新的, 已經產品化就緒的版本
嗯, 這裡有張更真實的圖片
在sprint 1後, 一個充滿錯誤的版本1.0.0被發佈. 在sprint 2期間, 錯誤報告開始大量湧入, 團隊花大量的時間在除錯, 並且在sprint中期被迫發佈了錯誤修復的版本1.0.1. 然後在sprint 2結束後, 他們發佈一個有新功能的版本1.1.0, 當然啦, 會有更多的錯誤, 因為他們受到上次發佈版本錯誤的干擾, 這次他們只有較少的時間去確保品質. 這樣的情形會一直重複發生.
在sprint 2中紅色斜線代表混亂的狀況
並不怎麼好吧? 嗯, 悲慘的是這問題會持續下去, 即使你有一個驗收測試團隊. 差別僅是大部分的錯誤報告來自於測試團隊, 而不是生氣的使用者. 從商業的角度來看, 兩者有很大的差別, 但是從開發人員的角度來看, 它們是相同的. 不過測試人員沒有像使用者那樣積極, 通常是這樣.
對於這個問題, 我們還沒有發現任何簡單的解法. 不過我們試過許多不同的模型
首先, 再一次強調, 還是要提高Scrum團隊所發佈程式碼的品質. 在sprint中, 早一點找出和修復錯誤的費用, 比在sprint結束後找出和修復錯誤的費用, 要低的很多.
但是事實仍然是事實,即使我們能減少錯誤的數目, 在sprint結束後, 仍然有錯誤報告被產生, 那我們是如何處理呢?
方式 1: "不要開始建立新的東西, 直到舊的東西已經產品化了"
聽起來不錯, 不是嗎? 你是否也有溫暖,模糊的感覺?
我們好幾次差點採用這個方法, 還畫出想像我們如何進行的模型. 然而, 當我們了解到它的缺點後, 我們就改變了心意. 如果我們採用這個方法, 我們必須在sprint之間, 加了一段沒有時間框的發佈時段, 在這段時間內我們只做測試和除錯, 直到我們能發佈一個產品為止.
我們不喜歡在sprint之間, 有一個沒有時間框的發佈時段, 主要是因為它打破正常的sprint心跳節奏. 我們不再能號稱"我們每三周會開始一個新的sprint". 此外, 它不能完全地解決問題, 即使我們有一個發佈的時段, 但是隨時還是會有緊急的錯誤報告出現, 我們必須準備好去處理它,
方法 2: "可以開始去建構新的東西, 但是要對舊有功能的產品化這件事給排出優先順序"
這是我們比較喜歡的方法, 至少現在是這樣
基本上, 我們完成一個sprint後接下一個sprint. 但是我們希望在下一個sprint中, 能花些時間去修復上一個sprint中的錯誤. 如果我們花太多時間去修復上一個sprint所產生的錯誤, 那下個sprint將會被嚴重的破壞. 我門會評估為什麼會發生這樣的事情, 以及我們如何改善品質. 我們會確認sprint的時間,是長的足夠去完成上個sprint中, 相當數量錯誤的修復.
一般來說, 經過幾個月後, 花在修復上個sprint所產生錯誤的時間會減少. 此外, 當錯誤發生時, 我們要參與的人員變少, 所以整個團隊不需要每次都被干擾. 現在我們已經到一個較可以接受的程度
在sprint規劃會議期間,我們設定較低的投入程度, 以讓我們能有時間去處理上個sprint來的錯誤修復. 經過一段時間後, 團隊已經相當擅長去評估這樣的事情. 速度的評量可以幫助許多(請看"團隊如何決定哪些故事要被放到這次sprint中?")
不好的方式 - "著重於建構新的東西"
"著重於建構新的東西, 而不去讓舊的東西能產品化". 誰會去做這樣的事呢? 我們一開始就經常犯這樣的錯誤, 我確定其他公司也是這樣. 它是一種和壓力有關的病狀. 許多經理實際上並不了解它: 即使所有的程式碼都已經完成, 你通常還是離產品化很遠. 至少複雜的系統是這樣. 所以經理(或是產品負責人)會要求團隊繼續增加新的東西, 可是舊的幾乎快發佈的程式碼的包袱越來越重, 拖垮每件事的進行.
不要讓最慢的一個連結從你的環節中斷掉
假設驗收測試是你最慢的連結, 你沒有很多測試人員, 或是因為令人沮喪的程式碼品質, 導致驗收測試的時間過長.
假設你驗收測試的團隊每週最多能測試三個功能(不, 我們不用"每週多少個功能"來衡量, 我只是使用它來當作例子). 而你的開發人員能每週開發6個功能.
它會誘使經理或產品負責人, 去規劃每週六個新功能的開發.
千萬不行, 現實終將會讓你嚐到苦頭, 並且帶來傷害.
相反的, 我們規劃每週做3個功能, 剩下的時間花在減輕測試的瓶頸. 例如:
# 讓一些開發人員作測試人員的工作(哦, 他們一定會喜歡你的...)
# 實作一些工具和腳本讓測試更容易.
# 增加更多自動化程式
# 增加sprint的長度, 把驗收測試加到sprint中
# 把有些sprint定義成"測試的sprint", 當中所有團隊都變成驗收測試團隊在做事
# 僱用更多的測試人員(即使這意味著減少開發人員)
我們曾試過這些解決方案(除了最後一個以外). 最好的長期解決方案當然是第二和第三點, 也就是有更好的工具, 腳本和測試自動化
回顧是一個很好的論壇, 可以找出你環節中最慢的連結.
回到現實
或許我給你一個錯覺, 我們在所有scrum團隊中都有測試人員. 並且我們對每個產品, 有一個很大的驗收測試團隊. 在每個sprint完後我們都會發佈, 等等.
嗯, 事實上我們並沒有
我們曾經有做到這樣的地步, 也看過它的正面影響. 但是我們離驗收品質保證流程所要求的還很遠, 我們仍然還有很多東西要學習
下一篇: Scrum and XP的實戰經驗 Ch15 (1): http://www.wretch.cc/blog/kojenchieh/15284687
上一篇: Scrum and XP的實戰經驗 Ch14 (2) http://www.wretch.cc/blog/kojenchieh/15282475
留言列表
