David Ko的學習之旅

每次我在跟人家談論 agile, 我常說會不會 scrum 並不重要, 如果你能夠做到自動化測試, 那對團隊的品質就會有幫助, 可是很多人就會問說, CI tool 會不會要花很多時間, TDD 我不會寫, 也沒空用耶. 那我們要怎麼辦呢?
 
 
以下是我的一些經驗談, 希望能對大家有點幫助
1. 先可以動
要不要用 Jenkins, TeamCity 這些高檔 continuous integration 工具, 這個問題可以一開始先不用面對, 雖然工具很好用, 但是也是要花時間唸書的. 最快可能是用個 batch file 把大家組合起來, 然後放在 cron table 之類的機制, 讓它可以週期性執行起來就可以了.  這樣會花你很多時間嗎? 會需要很高深的技術嗎? 應該不用吧 XDD
agile 的精神就是一開始先做最小集合, 然後利用 iteration 逐步改進. 唯有立即看到結果, 你才能知道你問題出在哪裡, 你才能看到你的效果. 所以第一點就是先可以動.
2. 先做測試自動化
TDD 真的不簡單, 不止觀念上要改變, 連程式架構上都需要做些改變. 因此要大家能立馬開始用 TDD, 這真的有點難度. The art of unit testing 這本書的作者說, 從 unit testing 或是測試自動化開始, 會是一個比較好的選擇. 讓這個動作把程式品質顧好, 讓你有多點時間去學些好的設計 (而不是都花在解 bug 上面), 最後才來說要不要做 TDD.
3. 先有少量
剛開始時, 不要想說要有幾百個自動化的測試個案. 你只要每個功能寫個 2-3 個就可以了. 因為這是要讓大家養成習慣, 而不是要求大家在衝量. 畢竟一個新的東西, 老闆出一張嘴很容易, 但是學習需要時間, 改變需要心理建設, 這些都是需要時間的. 你要做的的是降低門檻, 提高接受度. 
4. 先寫重要的
每個專案重要的定義不同, 但是先寫重要的, 讓這個投資是在最值得的地方, 這樣不管老闆或是員工, 都會覺得這不是件白工, 是個有意義的事情, 這樣要大家寫的阻力才會變小.
5. 先有樣本
有時候要測一個東西是有點難度的, 可能會比把那個受測功能寫出來還難. 這時候我會做的是請某位高手先寫 1-2 個案例. 之後再請別人接手. 這樣的好處是難關讓高手解決, 可以縮短時間, 讓他覺得有挑戰性. 然後讓技術沒那麼強, 或是不熟悉的人, 可以藉由這樣的來學習, 讓他們把依樣畫葫蘆, 把測試個案的數增加. 也不會讓高手覺得他都在做 routine 的工作. 
6. 每天至少執行一次
需知道測試程式只要 1-2 沒有執行, 可能之後都不會執行通過的, 因為受測程式會不斷地修改, 如果測試程式沒有不斷執行, 去跟上受測程式的修改, 不一會就會沒用的. 為了讓你的測試自動化有效果, 每天至少執行一次. 
不過, 最重要的, 還是你自己願意開始去嘗試, 想要跨出第一步. 否則不管大家分享哪些招數, 那都是別人成功的故事, 你永遠只有在台下聽的份 XDD

多個敏捷團隊之間的版本控制 (4)
http://www.slideshare.net/ssusere62027/4-37282728 
 

多個敏捷團隊之間的版本控制 (3)
http://www.slideshare.net/ssusere62027/3-37195342
 
來源:

多個敏捷團隊之間的版本控制 (1)

http://www.slideshare.net/ssusere62027/1-37088237

 
來源:

很多人提到持續整合時, 都會想到一堆工作, CI server, source control system, automation framework 等等. 不是的, CI 和工具是沒有關聯的, 它能不能成功, 重點是在於團隊能不能遵守紀律. 因此當你們開始實施 CI, 必須和團隊溝通清楚, 不要把重心放到錯誤的地方.
以下是常見的要遵守的 practices:

在進行持續整合時, 你需要準備以下事情
 
 
 
1. 版本控制
你需要將建構或是編譯系統, 所有需要用到的東西, 儲存到一個地方, 以確保將來可以隨時建構出相同一份系統. 這件事情看起來很簡單, 但是還是常常會沒做好. 記得重點是全部會用到的, 都要放進來. 
例如: 很多人沒有放 3rd party 的 library, 等到要 build 的時候, 才去網路上下載, 或者是才去 copy 一版進來, 這是不對的. 此外, 你的建構環境或是編譯系統也是要存放一份, 否則可能因你的環境不同, 也會產生出不同的東西.
2. 自動化編譯
不要只有 IDE 環境來編譯系統, 必須要能用 command line 來編譯, 這樣你才能控制所有東西, 並且有以下好處
a. 確定所有事情可以自動化執行
b. build script 需要版本控制, 將來才能對 script 修復和重構
c. 編譯時間對某些系統是重要的考量, 有 script 才有機會去調整
3. 自動化測試
如果你沒有做自動化測試, 那整個持續整合的系統就只是編譯你的程式而已, 這樣就弱掉許多. 這裡你需要三類型的測試
a. 單元測試: 對於某個單元(function, class 或是 method) 進行測試. 這需要在 10 分鐘內執行結束.
b. 元件測試: 測試某些模組, 或是單元整合起來, 是否能運作正確.
c. 驗收測試: 通常是要驗證是否滿足客戶的驗收標準, 是否符合當初所談的需求流程.
4. 持續整合的系統
是否一定需要持續整合的系統, 這件事情可以討論. 因為持續整合重點在 practice, 在於團隊的紀律和心態, 而非是用某個工具. 
不過如果你需要使用持續整合的系統, CruiseControl Family 或是 Jenkins 都是不錯的考量. 如果你是微軟的愛好者, 那她那一套也可以加減用.
不過這些東西, 似乎除了 IDE 環境, 很多公司好像都沒有, 有點蛋蛋的悲傷 …...

在大型開發團隊中, 很多時候 source tree 上所產生出來的 build 都是無法執行, 通常是最後一兩周的階段, 這個系統才有機會真的可以運轉.
為什麼會這樣呢? 主要原因是早期開發人員在寫程式時, 只在乎自己的那一塊是否寫完, 至於和別人都在一起是否能動, 那是之後的問題, 老闆只會為你寫完了沒有, 而不是這個系統能不能動.
所有通常在專案進入測試階段時, 大家才會開始處理這個系統是否能運作的事情. 也就是開始修復 bug. 這裏要花多少時間才能修復完畢, 系統要多久才能穩定, 就要祈求上天了. 
為了要解決這樣的問題, agile 裡面便提出了一個 practice, 叫做持續整合(continuous integration, CI). 希望程式一有變動時, 我們就趕快做整合, 確保整個系統仍能運作正確. 也就是你新增的部分, 不會影響原先系統的運行.

最近在上 CSPO (Certified Scrum Product Owner) 聽到一個蠻有趣的笑話, 你每天 check-in 程式幾次?
 
 
很多時候, 你會看到有些人宣稱他們在實施持續整合, 他們用的是 XX 系統, 然後有做測試自動化, 聽起來十分厲害, 會以為他們敏捷實行的很好.
但是老師問了一句話: 你每天 check-in 程式碼幾次?  各位, 你的回答是多少呢?
我想大多數的人, 回答可能是 1 天 1 次, 或者 2-3 次, 也有 2-3 天 1 次. 老師說這是根本不是在做持續整合, 最多只能說你是在用持續整合的工具.
你應該是要每天持續 check-in 數十次到上百次, 這樣才是在持續整合. 否則你也是很慢才知道你的代碼是否有問題, 是否會造成別人的問題. 
這也是通常 mini-waterfall 或是 scrum-fall 團隊最常看到的臭味: 每天最多 1 次, 或者多天才一次持續整合.
更慘的事, 還有工具的廠商欺騙你, 說只要你買了他們的工具, 開始使用, 這樣你就是在做敏捷了. 所以如果你看到有研討會, 從頭到尾都是廠商在介紹工具, 你就問問那些講師們, 他們的持續整合系統每天被執行了幾次? 程式碼有 check-in 了幾次? 如果連 10 次都沒有超過, 我想你應該可以換個場次聽聽了, 因為那不是敏捷. 
敏捷不是用持續整合工具就是在做敏捷, 不是有用 iteration 就是敏捷, 而是無時無刻保持敏捷的做法: 快速交付, 及早回饋. 這並不是只是在 iteration level, code level 也是要如此.

幾天前遇到一個討論, 讓人印象深刻. 
在 agile 中有個 practice 叫做 continuous integration, 它能幫助你, 及早發現系統整合上的問題, 以及讓你可以保持隨時可以有運行的系統, 或是可以發佈的系統.