Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
13. 我們如何結合Scrum和 XP
Scrum和XP結合後, 可以帶來很多好處, 這點是無須爭議的. 網路上, 我看到大部分的資料都支持這個論點, 所以我不用再花時間去爭論為什麼.
好的, 我注意到一件事. Scrum著重在管理以及組織的實踐. 而XP大多著重於實際的編程實踐. 那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題, 並且互補對方的不足.
在此, 我要在現有的經驗證據中, 加上我的聲音: Scrum和XP組合起來是很有成效的.
我將要介紹某些較有價值的XP實踐, 以及他們如何套用到我們每日的工作中. 我們並沒有所有團隊, 都被要求去採用所有的實踐, 但是總歸來說, 我們已經在大多數方面嘗試過XP和Scrum的組合. 有些XP的實踐是直接被Scrum解決掉, 因此可被視為重疊的實踐. 例如: "整個團隊", "坐在一起", "故事", 和"計畫遊戲". 在這樣的狀況下, 我們已經簡化地去直接採用Scrum.
搭檔編程
我們最近在某一個團隊開始採用搭檔編程. 運作的相當好. 我們大部分的其他團隊, 仍然沒有嘗試太多的搭檔編程. 但是在某一個團隊實際使用了幾次sprint後, 我因此而被啟發, 所以願意試著指導更多團隊去試試看
到目前為止, 有些關於搭檔編程的結論:
# 搭檔編程可以改進程式碼的品質
# 搭檔編程可以改進團隊的注意力(例如, 坐在你後面的人說"嘿, 這個東西在這個sprint中真的需要嗎?")
# 令人驚訝的, 那些強烈反對搭檔編程的開發人員, 實際上根本沒有嘗試過它. 可是一旦嘗試過, 便很快喜歡上它
# 搭檔編程會讓人精疲力盡, 不應該整天都這樣做.
# 經常更換夥伴是有好處的
# 搭檔編程可以增進團隊間知識的傳播. 會令人想不到的快速.
# 有些人就是對搭檔編程感到不舒服. 不要因為他不想搭檔編程, 就否決一個優秀的程式設計師.
# 檢視程式可以當作搭檔編程的替代方案
# "領航員"(不使用鍵盤的傢伙)應該也要有他自己的電腦. 並不是用來開發, 而是需要作一些嘗試, 或是當"司機"遭遇到問題的時候查看文件, 等等.
# 不要強迫人們採用搭檔編程. 而是鼓勵他們並提供正確的工具, 讓他們根據他們自己的步調去實驗
測試驅動開發(TDD)
阿們, 對我來說, TDD是比Scrum和XP還要重要. 你可以拿走我的房子, 我的電視,和我的狗.但是不要試圖阻止我去做TDD! 如果你不喜歡TDD, 那不要讓我到你的地盤, 因為我會想盡各種方法偷偷去嘗試它.
這裡有個TDD的10秒總結:
測試驅動開發意味著, 你要先寫自動化測試, 然後你再寫足夠的程式碼去通過測試, 接著你重構你的程式碼, 主要是去改進可讀性和移除重複的地方. 一直反覆進行這樣的事.
這裡有些對測試驅動開發的看法:
# TDD很難, 程式設計師要花一段時間才能掌握它. 事實上, 在很多狀況, 問題不在於你教多少, 指導多少或是展示多少. 唯一有效的方法, 是讓一個擅長TDD的人, 讓他和你一起搭檔編程. 一但知道怎麼做以後, 他將會受到很大的影響, 並且不會再去用其他方法工作
# TDD對系統設計有相當深遠且正面的影響
# 在新產品中, 需要花一段時間,才能讓TDD被應用的很有效率. 特別是黑相整合測試, 但是投資報酬率相當好
# 確認你投資的時間, 足夠到大家能很容易撰寫測試. 這意味著要有適當的工具, 受過訓練的人, 以及提供合適的utility classes 或是base classes.等等.
我們在測試驅動開發過程中, 使用了以下工具:
# jUnit / httpUnit / jWebUnit 我們正考慮去用TestNG和Selenium
# HSQLDB 在測試中, 被當成一個嵌入式的in-memory獨資仄庫
# Jetty 在測試中, 被當成一個嵌入式的in-memory的web container
# Cobertura 用來做測試涵蓋度度量
# Spring framework用來連接不同型態的測試裝置(test fixture)(帶有mock, 不帶mock, 連接外部資料庫, 連接in memory資料庫等等)
在我們最複雜的產品中(從TDD的觀點來看), 我們都有自動化黑箱驗收測試. 這些測試會在記憶體中啟動整個系統, 包括資料庫和網頁伺服器, 並且透過它的公開介面去存取這個系統(例如像是HTTP)
這樣會使開發-建構-測試的循環變得很快. 這也可當作一張安全網, 讓開發人員有足夠的信心常常去重構, 即使當系統成長後, 設計也能保持乾淨和簡單.
在新的程式碼上做TDD
對於所有新開發的程式, 我們都會做TDD, 即使這意味著最初的專案建置, 需要花費較長的時間(因為我們需要更多工具和支援一些測試裝置等等). 這是有點不容易, 但是它的好處很大, 因此沒有任何理由不去用它.
在舊的程式碼上做TDD
TDD是有點難的, 但是試圖在一開始沒有用TDD的程式碼上要去做TDD, 那是更加困難...為什麼? 嗯, 事實上, 關於這個主題, 我可以寫出一堆文章, 所以我想我先到這裡為止. 我將保留到我下一本書"TDD的實戰經驗"中再談. :o)
我們花相當多的時間, 試圖對一個較複雜的系統, 自動化其整合測試. 它的程式碼已經存在很長一段時間,並且處於嚴重混亂狀態, 完全沒有測試程式
每次系統的發佈前, 我們會有一個專門的測試人員, 去執行大量, 複雜的回歸測試和效能測試. 回歸測試大多數是手動進行, 因此嚴重地減緩開發和發佈的週期. 我們的目標是去自動化這些測試, 但是, 在幾個月的痛不欲生後, 我們還是無法能有更多進展
之後我們改變我們的方法. 我們承認這個事實, 那就是我們身陷於必須手動進行回歸測試的麻煩. 然後相反的問自己"我們如何使手動測試流程花費的時間比較少?" 當時有一個賭博遊戲的系統, 我們意識到, 許多測試團隊的時間是花在繁瑣的安裝工作, 像是瀏覽後台系統去建立牌局來進行測試, 或是等待一個安排好的牌局啟動. 所以我們為了這樣寫了一些工具, 他們是很小, 容易被使用的腳本(script), 並且會處理掉一些瑣碎繁雜的工作, 好讓測試人員可以專注於真正的測試工作
這些努力確實收到效果! 事實上, 我們一開始就應該要這樣做. 我們過去太急著去自動化它, 卻忘記要按部就班來. 剛開始的第一步應該是建立一些東西, 讓手動測試能更有效率.
學到的教訓: 如果你身陷於必須手動進行回歸測試的麻煩, 並且想要把它自動化, 還是放棄吧(除非它很容易去做到).相反地, 想些方法來讓手動回歸測試容易點, 然後再考慮將真正的測試給自動化
留言列表
