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)，並且會處理掉一些瑣碎繁雜的工作，好讓測試人員可以專注於真正的測試工作。
這些努力確實收到效果！ 事實上，我們一開始就應該要這樣做。我們過去太急著去自動化它，卻忘記要按部就班來。剛開始的第一步應該是建立一些東西，讓手動測試能更有效率。
學到的教訓：如果你身陷於必須手動進行回歸測試的麻煩，並且想要把它自動化，還是放棄吧(除非它很容易去做到)。相反地，想些方法來讓手動回歸測試容易點，然後再考慮將真正的測試給自動化。
全站熱搜
留言列表
