Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
藉由把測試人員放到Scrum團隊中來提高品質
是的, 我聽過完全不同的說法
# "但是, 那很明顯啊! Scrum團隊理應是跨功能職務的"
# "Scrum團隊理應是沒有角色的! 我們不能有一個人僅僅只是在做測試"
讓我澄清一下, 在這裡我所謂的"測試人員"是指"一個主要技能是測試的人", 而不是"一個它的角色只是做測試的人"
開發人員通常是相當差勁的測試人員, 特別是測試他們自己的程式碼的時候
測試人員就是"驗收的傢伙"
除了"只是"團隊的一員外, 測試人員有一個重要的工作, 他是驗收的傢伙. 在Scrum中, 要直到他說完成才算完成, 否則沒有事情能算"完成". 我曾經發現, 開發人員常常說某件事情已經完成, 但是實際上還沒有. 即使你有非常清楚"完成"的定義(你應該如此, 請看"'完成'的定義"), 開發人員還是經常忘記. 我們這些程式設計師常是沒有耐心的人, 只想要很快的進到下一sprint.
那我們的測試先生如何知道某些事情已經做完呢? 嗯, 首先, 他應該(很驚訝吧)測試它! 在許多狀況下, 那些開發人員認為已經做完的項目, 結果是不可能被測試的. 因為那些東西還沒被check-in, 或是還沒被部署到測試伺服器中. 一但測試先生開始測試時, 他應該和開發人員, 從頭到尾確認過那份"做完"的清單(如果你有的話). 例如, 如果在"做完"的定義中, 描述應該有個發佈說明, 那測試先生要檢查是不是有個發佈說明. 如果這個功能有某種更為正式的規格, 那測試先生也要檢查, 等等.
這裡有一個很好的副作用, 因為團隊現在有一個傢伙, 非常適合安排sprint展示的工作.
當沒有東西要測試時, 測試人員要做什麼?
這個問題常常被提出來. 測試先生說: "嗨, Scrum masterm 現在沒有東西要測試, 所以我要做什麼?" 團隊可能需要一個禮拜, 才能完成第一個故事. 那這時候測試人員應該做什麼?
好的, 首先, 他應該要位測試做些準備. 那就是撰寫測試規格書, 準備測試環境, 等等. 所以當開發人員已經有東西可以被測試時, 就不用再等待, 測試先生可以立即開始測試.
如果團隊有做TDD, 那大家從第一天開始, 就會花時間撰寫測試程式碼. 測試人員應該和開發人員撘檔編程, 一起撰寫測試程式. 如果測試人員一點都不會寫程式, 他也應該和開發人員撘檔編程. 即使他只能瀏覽, 而開發人員去敲鍵盤. 一個好的測試人員總是會比好的開發人員, 想出更多不同種類的測試, 所以他們可以互相互補.
如果團隊沒有採用TDD, 或是沒有足夠的測試個案需要去撰寫, 他應該完全地盡他所能, 幫助團隊實現sprint的目標. 就像團隊其他成員一樣, 如果測試人員會寫程式, 那很好. 如果不會, 你的團隊必須找出需要在sprint中完成, 但不用寫程式的工作.
在sprint規劃會議中, 把故事拆解成任務時, 團隊著重於編程的工作. 然而, 通常還有許多非編程的工作, 需要在sprint中完成. 在sprint規劃會議中, 如果你花時間, 企圖找出非編程的工作, 測試先生將會有機會去貢獻許多, 即使他不會寫程式, 或者目前沒有測試工作要進行.
這裡有些非編程的任務, 需要在sprint中被完成:
# 建置測試環境
# 釐清需求
# 和營運部門討論佈署的細節
# 撰寫部署的文件(發佈說明, RFC, 或是任何你組織中要寫的東西)
# 和外部資源進行聯繫 (例如GUI設計師)
# 改善建構腳本(build scripts)
# 進一步將故事拆解成任務
# 從開發人員中找出關鍵的問題, 並解決他們
從另一個角度來看, 如果測試先生變成是瓶頸, 那我們該怎麼辦? 假設我們現在在sprint的最後一天, 突然間有很多工作被完成, 導致測試先生沒有去測試完所有事情, 那我們要怎麼辦? 嗯, 我們應該叫團隊中所有人去測試先生當助手. 他來決定哪些事情他自己要做, 然後把一些平凡的測試交給團隊中其他人來做. 這就是跨功能職務的團隊所該做的事情
所以, 是的, 測試先生在團隊中確實有一個特別的角色, 但是他仍然可以去做其他工作, 其他團隊成員也被允許去做他的工作
藉由在sprint中做較少的工作來提高品質
讓我們回到sprint規劃會議中. 簡單地說, 不要把太多故事放到同一個sprint裏! 如果你有品質的問題, 或是很長的驗收測試週期, 那就在每個sprint中做較少的事情! 這將自動地導致較高的品質, 較短的驗收測試週期, 較少影響使用者的錯誤, 並在長期來說會有較高的生產力, 因為團隊可以所有時間都著重於新的東西, 而不是因修復舊的東西打斷目前工作的進行
與其建構許多東西, 但是需要出些hot-fixes來補救; 還不如建構少一點, 但是建構的比較穩定, 這樣會比較划算點.
驗收測試應該是sprint的一部分嗎?
我們在這裡差距很大. 有些團隊把驗收測試當做sprint的一部份, 大部分的團隊則沒有, 主要有兩個原因:
# Sprint是有時間框的限制, 驗收測試(根據我的定義, 它包含了除錯和再次發佈're-releasing')的時間是非常困難去固定的. 如果時間用完了, 你還有一些關鍵的錯誤, 那你要怎麼辦? 你要去發佈一個有嚴重錯誤的產品嗎? 還是你要等到下一個sprint才發佈? 在大部分的狀況, 這兩種作法都無法接受. 所以我們把手動驗收測試不視為sprint的一部份.
# 如果你有多個Scrum團隊一起開發一個產品, 那手動驗收測試執行的對象, 必須是這些團隊工作的結果. 如果這些團隊各自把驗收測試放在自己的sprint中, 你還是需要一個團隊去測試最後版本, 也就是最後整合所有團隊工作結果的版本.
這並不是一個完美的解法, 但是在大部分的狀況下, 對我們來說已經足夠了.
下一篇: Scrum and XP的實戰經驗 Ch14 (3) http://www.wretch.cc/blog/kojenchieh/15283953
上一篇: Scrum and XP的實戰經驗 Ch14 (1) http://www.wretch.cc/blog/kojenchieh/15280681
留言列表
