敏捷方法心得分享 - 洪盟翔

[Gaitz Cheng]

研究所認識了敏捷方法後，到去工作的這幾年都一直覺得受用無窮。第一年在大公司時，是負責開發內部開發工具，我們團隊全部都在同一個區間，用擋板隔開的好處是可以不被干擾，需要討論只要站起來找人就能很容易面對面溝通。因為業務屬於內部開發支援，我們不會每天做 Standup Meeting ，但每個禮拜會有一次全團隊的會議，大約六人，討論這禮拜完成與下禮拜預計要執行事項。團隊並無人有敏捷方法經驗，但是因為人少且需求相對穩定，溝通有效快速下，雖然並無導入實際方法論，還是運行的相當順利。最有趣的是，我們就是開發 CI 的伺服器與流程。

第二年我轉到了創業公司，創業公司的節奏快速許多，公司的每一步都攸關能不能生存下去。時間資源相當有限，且市場需求不易捉摸，需要一直實驗。所以開發的節奏和敏捷方法很相近，釋出、回饋、修改，我們平均兩到三天就會有新版持續上線，我們人員也都是坐在開放空間，緊密的共同工作溝通。

同時創業圈也流行了 Scrum ，我們有導入，每天都會開 stand up meeting ，但是沒有嚴格遵守一些最佳實踐，偶爾還是會超過十分鐘，因為討論起實作的問題。有使用 Trello 來記錄卡片，但沒有在上面評估時間，所以久了就只是一份共同待辦事項而已。

開發過程中，也不大會有機會寫下文件，所以軟體的維護性相對不高，只有一些簡單的測試保護而已。程式碼也不大會有機會重構，因為每天都有比重構重要的事情要做。如果公司有獲利、商業模式穩定後，才有機會去重構吧。

文件部分我最近開始使用一個新方法，我會寫下功能是在什麼樣的時空背景下被要求的。搭配使用 Quip 這類文件管理軟體，記錄文件的修改過程，實做設計上的取捨。實做的細節去看程式碼就好，但是需求是如何演變來的，相對更有價值，以往都是埋沒在信件與對話當中。

這幾年下來，敏捷一直深深影響著我的思路。我已經習慣東西做好趕緊放上去測試，市場就是客戶，而且還很難跟它溝通來得知需求，只能把測試的循環做到最好最快。程式普遍我只會寫單元測試，整合測試因為太複雜，僅有導入過一次測試最核心的流程，之後也因為年久失修而取消。

軟體一直都很複雜，擁抱改變某個程度來說是壓力的解放，因為算是瞭解了本質就是一直變。老師以前常說的`精準`，我也一直牢記在心。我會繼續用敏捷的心態，去追求優雅的開發軟體，學習新事物，產出更多有價值的產品。