Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
漸進式設計(Incremental Design)
這意味著一開始設計就要保持簡單, 然後持續去改進它. 而不是一開始就試圖要所有的事情都正確, 然後就凍結它.
我們這點上做的相當好, 也就是, 我們花了可觀的時間去重構, 改進現有的設計. 並且我們很少花時間去大規模的預先設計. 當然, 有時我們也會搞砸了. 例如, 允許一個搖搖欲墜的設計"陷入"的太深, 導致後來的重構變成是一個大工程. 但是整體來說, 我們還相當滿意.
持續設計的改進, 很大程度是做TDD所自動帶來的副作用
持續整合(Continuous integration)
我們大部分的產品在持續整合方面已經相當成熟, 它是利用Maven和QuickBuild來達成的. 這是相當有用並且節省時間. 對於"嘿, 它在我的電腦上是可以的"這個問題, 持續整合是終極解決方案. 若是要判斷所有程式碼的健康狀況, 我們把持續建構的伺服器當作是"仲裁者", 或是參考點. 每次有人checkin東西到版本控制系統, 持續建構系統會醒來, 在共用的伺服器上, 重新建立每件事情, 然後再執行所有的測試. 如果有出現問題, 它將會寄郵件去通知整個團隊, 告訴他們這個版本是有問題的, 包括準確地告知哪些修改的程式碼造成建構失敗, 以及指向相關的測試報告的連結,等等.
在每個晚上, 持續建構伺服器將會重新建構產品, 並發佈執行程式碼(ears, wars,等等), 文件, 測試報告, 測試涵蓋度報告, 相依性報告,等等, 把他們放到我們內部的portal上面. 有些產品也會自動部署到測試環境中.
設定這件事情需要花費大量的工作, 但是每一分鐘都是值得的
程式碼集體共有權(Collective code ownership)
我們鼓勵程式碼集體共有, 但是並不是所有團隊都已經採用它. 我們發現到, 搭檔編程中經常更換搭檔, 會自動形成高度的程式碼集體共有權. 若團隊有高度的程式碼集體共有權, 已被證實會非常強壯. 例如,他們的sprint不會因為某個關鍵的人員生病而有所影響
資訊化工作場所(Informative workspace)
所有團隊可以善加利用白板和空白牆壁的空間. 在大部分的房間, 你將會發現到牆壁貼滿了產品或是專案的各式各樣資訊. 最大的問題是舊的訊息也積累在牆壁上. 我們可能需要在每個團隊中導入一個"管家"的角色
我們鼓勵使用任務版, 但是不是所有團隊都已經採用它. 請看"我們如何安排團隊的座位和空間"
編碼規範(Coding standard)
最近我們已經開始定義編碼規範. 它非常有用. 要是我們能早點這樣就好了. 它一點都不花時間, 只要從簡單開始, 然後讓它慢慢增加. 只要寫下不是所有人都明顯知道的事, 如果可能的話, 連結到現存的資料上.
大部分的程式設計師有他們自己的編碼風格. 細節像是他們如何做例外處理, 他們如何註解程式碼, 什麼時候要傳回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.
可持續的開發速度(Sustainable pace)/精力充沛的工作(energized work)
許多agile開發的書籍宣稱, 加班在軟體開發過程中會降低生產力
在幾次不情願的試驗後, 我非常同意這件事.
大約幾年前, 我們其中一個團隊(最大的團隊)大量瘋狂的加班, 現存程式碼的品質令人沮喪, 他們必須花大量的時間在救火. 測試團隊(也同樣在加班)沒有機會, 認真地去做品質確認的工作. 我們的使用者很生氣, 很多八卦都快把我們給吃掉.
在幾個月後, 我們成功地將工作時間降到適當的範圍. 人們正常上下班(除了專案關鍵時期例外). 令人驚訝的事發生了, 生產力和品質有明顯的改進.
當然, 減少工作時間是絕不是唯一會導致改善的原因, 但是我們都相信它佔很重要的因素.
留言列表
