13 我們如何結合Scrum和 XP
漸進式設計
這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一開始就試圖要所有的事情都正確，然後就凍結它。
我們這點上做的相當好，也就是，我們花了可觀的時間去重構，改進現有的設計。並且我們很少花時間去大規模的預先設計。當然，有時我們也會搞砸了。例如，允許一個搖搖欲墜的設計"陷入"的太深，導致後來的重構變成是一個大工程。但是整體來說，我們還相當滿意。
持續設計的改進，很大程度是做TDD所自動帶來的副作用。
持續整合
我們大部分的產品在持續整合方面已經相當成熟，它是利用Maven和QuickBuild來達成的。這是相當有用，並且節省時間。對於"嘿，它在我的電腦上是可以的"這個問題，持續整合是終極解決方案。若是要判斷所有程式碼的健康狀況，我們把持續建構的伺服器當作是"仲裁者"，或是參考點。每次有人checkin東西到版本控制系統，持續建構系統會醒來，在共用的伺服器上，重新建立每件事情，然後再執行所有的測試。如果有出現問題，它將會寄郵件去通知整個團隊，告訴他們這個版本是有問題的，包括準確地告知哪些修改的程式碼造成建構失敗，以及指向相關的測試報告的連結，等等。
在每個晚上，持續建構伺服器將會重新建構產品，並發佈執行程式碼(ears，wars，等等)、文件、測試報告、測試涵蓋度報告、相依性報告，等等，把他們放到我們內部的portal上面。有些產品也會自動部署到測試環境中。
設定這件事情需要花費大量的工作，但是每一分鐘都是值得的。 如果你再走的更遠一點，你會達到持續交付的境界。每個提交的版本，都是一個可發行的候選者，所以發佈只是一個按鍵的操作。我看到越來越多的團隊做到這樣，我自己帶領的專案，也是這樣在做。它讓你感到非常神奇地的有效！我建議你可以研讀（或者至少瀏覽一下）Continuous Delivery 這本書。建置它需要做很多事情，但是在新產品開始時，這絕對是值得去做的。幾乎可以馬上得到回報。並且現在有很多工具都支援這件事情。
程式碼集體共有權
我們鼓勵程式碼集體共有，但是並不是所有團隊都已經採用它。我們發現到，搭檔編程中經常更換搭檔，會自動形成高度的程式碼集體共有權。若團隊有高度的程式碼集體共有權，這個團隊就會非常強壯。例如，他們的Sprint不會因為某個關鍵的人員生病而有所影響。
Spotify （和其他所多快速發展的公司）有個“內部開源”的運作方式。所有的程式碼都放在內部的 GitHub 上面，所有人都可以複製儲存庫，以及提出 pull request，就像任何公開的開源專案，非常方便。
資訊化工作場所
所有團隊可以善加利用白板和空白牆壁的空間。在大部分的房間，你將會發現到牆壁上，貼滿了產品或是專案的各式各樣資訊。最大的問題是，舊的訊息也積累在牆壁上。我們可能需要在每個團隊中，導入一個"管家"的角色。
我們鼓勵使用任務版，但是不是所有團隊都已經採用它。請看"我們如何安排團隊的座位和空間"。
編碼規範
最近我們已經開始定義編碼規範，它非常有用。要是我們能早點這樣就好了。它一點都不花時間，只要從簡單開始，然後讓它慢慢增加。只要寫下不是所有人都明顯知道的事，如果可能的話，連結到現存的資料上。
大部分的程式設計師有他們自己的編碼風格。細節像是他們如何做例外處理，他們如何註解程式碼，什麼時候要傳回null，等等。在某些狀況下，這些差異是沒有關係。可是在某些狀況下，可能會導致嚴重的系統設計不一致，以及很難閱讀的程式碼。此時編碼規範就非常有用，只要你關注在一些重要的事項上面。
這裡有些我們編碼規範的範例：
• 你可以打破裡面任何一個規則，但是要確認有個好的理由，並且要記錄下來。
• 預設使用Sun的編碼規範：http：//java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
• 永遠，永遠，永遠不要在，沒有記錄stack trace的情況下，或是重新丟出exception的狀況下，去抓住exception。用log.debug()是可以的，只是不要忘記stack trace就可以。
• 使用setter為主的依賴性注入(dependency injection)，來減低類別之間的關連(當然，如果緊密耦合是適用的話，那就另當別論)。
• 避免縮寫。但是為人熟知的縮寫則是可以，像是DAO。
• 需要傳回collection或是陣列的函式，不能夠傳回null。而是要用空的collection或是陣列來代替null。
程式碼規範和風格指南是非常有用的。但是沒有必要去重新發明輪子 – 你可以從我的好友 Google 中複製一份： http://google-styleguide.googlecode.com
可持續的開發速度/精力充沛的工作
許多敏捷開發的書籍宣稱，加班在軟體開發過程中會降低生產力。
在幾次不情願的試驗後，我非常同意這件事！
大約幾年前，我們其中一個團隊(最大的團隊)大量瘋狂的加班，現存程式碼的品質令人沮喪，他們必須花大量的時間在救火。測試團隊(也同樣在加班)沒有機會，認真地去做品質確認的工作。我們的使用者很生氣，很多八卦都快把我們給吃掉。。
在幾個月後，我們成功地將工作時間降到適當的範圍。人們正常上下班(除了專案關鍵時期例外)。令人驚訝的事發生了，生產力和品質有明顯的改進。
當然，減少工作時間，絕對不是唯一會導致改善的原因，但是我們都相信它佔很重要的因素。
我再看了幾遍，認為在軟體開發中（或是其他任何複雜和有創意的工作），交付的價值和所花費的時間，其實是沒有什麼關聯性。真正重要的是有多少專注和有動力的時間。我們大多數曾經經歷過這樣的感受，在星期六上午工作的很平順，好幾個小時很安靜，並且在那時間似乎完成了一整個禮拜的工作！這就是我說的專注和有動力的時間。所以不要強迫人們超時工作，除了極少數例外的狀況是真的需要這些時間。另外，讓人們精疲力盡是不道德的。
全站熱搜
留言列表
