13 我們如何結合Scrum和 XP 
 
 
Scrum和XP結合後,可以帶來很多好處,這點是無須爭議的。網路上,我看到大部分的資料都支持這個論點,所以我不用再花時間去爭論為什麼。
 
好的,我注意到一件事。Scrum著重在管理以及組織的實踐。而XP大多著重於實際的編程實踐。那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題,並且互補對方的不足。
 
因此,我要在現有的經驗證據中,加上我的聲音:Scrum和XP組合起來是很有成效的!
 
我從 Jeff Sutherland 那裡了解到,一開始 Scrum 是有實施 XP 的實務。但是 Ken Schwaber 說服了他,把工程實踐從 Scrum 中移除,以保持整個模型的單純,讓團隊自己去負責技術實務的部分。或許, 者可以幫助 Scrum 傳播的很快。但是,缺點是許多團隊因此而受難。因為缺乏技術實務,而導致無法建立可持續的敏捷開發。 
 
我將要介紹某些較有價值的XP實踐,以及他們如何套用到我們每日的工作中。我們並沒有要求所有團隊,去採用所有的實踐。但是總歸來說,我們已經在大多數的方面,嘗試過XP和Scrum的組合。有些XP的實踐,可以直接被Scrum解決掉,因此可被視為重疊的實踐。例如: "完整團隊"、"坐在一起"、"故事"、和"計畫遊戲"。在這樣的狀況下,我們已經直接採用Scrum。
 
 
搭檔編程
我們最近在某一個團隊開始採用搭檔編程,運作的相當好。我們大部分的其他團隊,仍然沒有嘗試太多的搭檔編程。但是在某個團隊實際運用它,跑幾次Sprint後,我因此而被啟發,願意試著指導更多團隊去試試看。
 
到目前為止,有些關於搭檔編程的結論:
•    搭檔編程可以改進程式碼的品質。
•    搭檔編程可以改進團隊的注意力(例如,坐在你後面的人說"嘿,這個東西在這個Sprint中真的需要嗎?")。
•    令人驚訝的,那些強烈反對搭檔編程的開發人員,實際上根本沒有嘗試過它。可是一旦嘗試過,便很快喜歡上它。
•    搭檔編程會讓人精疲力盡,不應該整天都這樣做。 •    經常更換夥伴是有好處的。
•    搭檔編程可以增進團隊間知識的傳播。會令人想不到的快速。
•    有些人就是對搭檔編程感到不舒服。不要因為他不想搭檔編程,就否決一個優秀的程式設計師。
•    檢視程式可以當作搭檔編程的替代方案。
•    "領航員"(不使用鍵盤的傢伙)應該也要有他自己的電腦。並不是用來開發,而是需要作一些嘗試,或是當"司機"遭遇到問題的時候查看文件,等等。
•    不要強迫人們採用搭檔編程。而是鼓勵他們並提供正確的工具,讓他們根據他們自己的步調去實驗。
 
 
測試驅動開發(TDD)
阿們,對我來說,TDD是比Scrum和XP還要重要。你可以拿走我的房子,我的電視,和我的狗。但是不要試圖阻止我去做TDD!如果你不喜歡TDD,那不要讓我到你的地盤,因為我會想盡各種方法偷偷去嘗試它:o)
 
好的,我已經不再對它這麼狂熱。我了解到 TDD 只是一個相當小眾的技術,只有少數的人有耐心去精通它。相反地,我只教授這些技術,但是讓團隊決定要用多少,以及何時去用。
 
這裡有個TDD的10秒總結:
 
測試驅動開發意味著,你要先寫自動化測試,然後你再寫足夠的程式碼去通過測試,接著重構你的程式碼,主要是去改進可讀性和移除重複的地方。一直反覆進行這樣的事。。
 
這裡有些對測試驅動開發的看法:
•    TDD很難,程式設計師要花一段時間才能掌握它。事實上,在很多狀況,問題不在於你教多少,指導多少或是展示多少。唯一有效的方法,是讓一個擅長TDD的人,讓他和你一起搭檔編程。一但知道怎麼做以後,他將會受到很大的影響,並且不會再去用其他方法工作。
•    TDD對系統設計有相當深遠且正面的影響。
•    在新產品中,需要花一段時間,才能讓TDD被應用的很有效率。特別是黑箱整合測試,但是投資報酬率相當好。
•    確認你投資的時間,足夠到讓大家能很容易撰寫測試。這意味著要有適當的工具,受過訓練的人,以及提供合適的utility classes 或是base classes 等等。
 
因為 TDD 還蠻難的,我並不打算強迫人們去用它。相反地,我指導他們以下準則:
 
1) 確保每個關鍵的功能,都至少有一個端點到端點的驗收測試。可透過畫面,或是畫面下一層來操作。
2) 確保每個複雜或是關鍵的業務之程式片段,都有進行單元測試。
3) 這會遺留某些程式碼沒有被涵蓋,那沒有關係。但是要知道哪些沒有被涵蓋,確定這是經過深思熟慮後的取捨,而不是只是被忽略了。
4) 當你開發到哪裡,就要撰寫測試到哪裡,不要留著之後才做(因為你之後可能跟你現在一樣忙)。
 
在沒有要求全面 TDD的狀況下,看起來仍然有足夠的維護能力。 因為報酬遞減的關係,測試涵蓋度最終只達到70%。簡單來說,測試自動化是關鍵,而 TDD 是可有可無。
 
我們在測試驅動開發過程中,使用了以下工具:
•    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,那是更加困難…為什麼? 嗯,事實上,關於這個主題,我可以寫出一堆文章,所以我想我先到這裡為止。我將保留到我下一本書"TDD的實戰經驗"中再談。:o)
 
一直都抽不出時間寫這些東西 … 但是,從來都不缺乏 TDD 的書籍!有一很棒的書是有關於處理遺留代碼的,叫做 Working Effectively with Legacy Code,作者是 Michael Feathers,非常經典。我也寫過一些有關於技術債的文章,可以參考我的部落格。 http://blog.crisp.se/tag/technical-debt
 
我們花相當多的時間,試圖對一個較複雜的系統,自動化其整合測試。它的程式碼已經存在很長一段時間,並且處於嚴重混亂狀態,完全沒有測試程式。
 
每次系統的發佈前,我們會有一個專門的測試人員,去執行大量、複雜的回歸測試和效能測試。回歸測試大多數是手動進行,因此嚴重地減緩開發和發佈的週期。我們的目標是去自動化這些測試,但是,在幾個月的痛不欲生後,我們還是無法能有更多進展。
 
之後我們改變我們的方法。我們承認這個事實,那就是我們身陷於必須手動進行回歸測試的麻煩。然後相反地問自己:"我們如何使手動測試流程,花費的時間比較少?" 當時有一個賭博遊戲的系統,我們意識到,許多測試團隊的時間是花在繁瑣的安裝工作,像是瀏覽後台系統去建立牌局來進行測試,或是等待一個安排好的牌局啟動。所以我們為了這樣寫了一些工具,他們是一個很小,容易被使用的腳本(script),並且會處理掉一些瑣碎繁雜的工作,好讓測試人員可以專注於真正的測試工作。
 
這些努力確實收到效果! 事實上,我們一開始就應該要這樣做。我們過去太急著去自動化它,卻忘記要按部就班來。剛開始的第一步應該是建立一些東西,讓手動測試能更有效率。
 
學到的教訓:如果你身陷於必須手動進行回歸測試的麻煩,並且想要把它自動化,還是放棄吧(除非它很容易去做到)。相反地,想些方法來讓手動回歸測試容易點,然後再考慮將真正的測試給自動化。
arrow
arrow
    全站熱搜

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