前言

在上一篇敏捷之路中主要講述了我們軟體開發方法方面的改進歷程，有近一年的時間裡完成了試點團隊由DO Whatever向敏捷開發的遷移。在這一篇文章中講介紹這個遷移過程背後的技術轉型的故事。

背景

核心背景就是我們已經決定採用敏捷的模式來提供我們的軟體研發水平。試點團隊包括四個人，開發經驗平均下來也就一年。
試點專案屬於典型的遺留系統，由外協公司開發的資訊化管理系統，下文簡稱UAV系統。該系統採用自研的OSGI架構，外協公司東拼西湊的完成後匆匆交付，沒有經過實際測試，實際屬於演示的原型系統，開發人員眾多加上人員流動大，程式碼質量慘不忍睹，外協的技術支援也是有心無力。
同時使用者作為典型的政府部門，需求非常不穩定，自己也不知道想要什麼東西。
就這樣我們開始我們的故事。

分析

我們的問題

採用敏捷開發的模式，每兩週進行一次迭代，因此我們每兩週內就要完成系統優化，測試和部署。這對於設計良好的系統並不難做到，但我們面對的是一個不甚瞭解的遺留系統，我們提交的系統總是上線後發現存在bug，造成了不良影響。週期短，技術不熟，測試不充分，難以發現問題。
由於敏捷開發對於持續整合和自動化測試還是比較推崇的，我們自然也希望實現系統的持續整合，但我們發現目前jenkins無法解決osgi框架的構建問題。jenkins無法構建，缺乏測試技術

怎麼辦

1.調研構建技術
2.學習自動化測試技術
3.上線前充分測試

轉型過程

慣性階段

在這個階段，還是屬於過渡時期，通過採取最簡單的措施，遏制住線上產品bug率居高不下的問題。為此採取瞭如下措施：
1.設立專門的測試人員，負責提高產品質量
雖然敏捷方法中比較推崇全員質量並淡化測試與開發人員區別，但結合到我們的實際情況這個目標還是有一些距離，為了最短時間起效最後還是決定設定固定測試熱源
2.搭建bugfree
對於發現的bug進行跟蹤，由於遺留的bug過多，無法全部實時處理，因此搭建了bug追蹤系統，由測試人員進行管理。
3.人工測試確認開發功能
開發人員完成開發後，由測試人員進行功能的確認，確認後才能提交程式碼，功能開發才算完成。
4.完整的手工驗收測試
上線前要進行完整的手工測試。
此外還進行了：
構建框架選型，經過反覆查閱資料和論證，確認這個自研的osgi框架沒救了，著手進行新框架的調研
單元測試選型，學習單元測試知識。

摸索階段

在設立了專門的測試人員並執行了嚴格的測試標準後，產品質量得到明顯提升，但開發速度有了不小的下降。同時測試人員工作量巨大，重複工作多，在結束前的驗收測試總是加班才能完成，再加上修復發現的 問題，總是存在產品上線推遲的現場，後來將驗收測試提前到截至兩天前才勉強能趕上迭代結束。因此這個週期我們集中精力來通過自動化測試技術來提高測試人員的效率，提高整個團隊的效率。
這個階段的自動化測試又可以分為兩個小階段
1.引入自動化冒煙測試
由於系統程式碼量大，區域性的單元測試覆蓋提升的效果有限，經過研究我們決定先構造一套支撐系統完整業務流程的自動化冒煙測試，測試人員可以輕鬆在3分鐘內的完成任務流程的測試，而之前人工要進行近兩個小時的測試。
完全自動化後，由測試人員每天執行，並負責通知開發人員進行修正。
冒煙測試的引入大大提升了測試人員的工作效率，縮短了開發和測試的反饋週期，提供了產品質量。
2.引入selenium自動測試
在完成了冒煙測試後，並完成對核心業務的單元測試覆蓋後，我們並沒有去完全補充單元測試，相反我們針對測試人員每次迭代結束前的驗收測試進行了自動化，即利用selenium實現UI的自動化測試，這樣測試人員通過selenium的測試完成了之前驗收測試中80%的工作。基本解除了團隊測試的瓶頸，當然這個工作給開發人員帶來了不小的工作量，但經過權衡和回顧我們認為這是非常值得的。

最後實現了測試人員進行人工複查和探索性測試即可。
截止到目前之前系統的質量問題得到了質的改變，很少出現線上bug的反饋。

在解除了質量報警和測試瓶頸後，我們又反過頭來解決專案構建問題。
由於我們通過兩個試點專案進行之前沒有應用過的技術研究，即專案框架springboot的研究以及maven和hibernate的研究。值得注意的是KSXT專案是公司的小專案，ZZH專案則是我們團隊內部進行的驗證性專案。經過兩個月的時間兩個專案均完成了開發，取得了至關重要的實驗結果。KSXT試點專案實驗maven，hibernate。ZZH試點專案實驗springboot。
在兩個試點專案中為了解決maven資源庫問題，我們在內網搭建了私有庫Nexus，從而解決框架遷移的最後一個屏障。
搭建jenkins

正軌階段

在完成兩個試點專案後，我們拋棄osgi的決心已經定下來，這是正好有SC專案上馬，新項成了完美的試驗場，魚魚SC專案成了springboot+maven+junit+hibernate新一代平臺的驗證專案，由於有了KSXT和ZZH專案的基礎，新框架雖然遇到了一些問題但還算是順利的搭建完成了。

在我們搭建新平臺時，測試人員也順理成章的搭建了jenkins，SC專案成為了jenkin是的第一個常駐專案。
jenkins在成功運轉後將我們的問題發現時間大幅降低，進一步提升了開發效率和產品質量。

同時由於在生產，測試，開發環境的不一致問題，讓產品的部署非常困難，從而激發了學習docker技術，來將jenkins的持續整合提升為持續部署。

成熟階段

隨著測試覆蓋度的提升，測試的複雜度也越來越高，於是通過向junit補充mock技術來降低編寫測試的困難和工作量。

同時為了提高程式碼的質量，引入了sonar作為程式碼質量評價工作，開始是通過sonar-runner客戶端手動進行，後來完成了jenkins對sonar的整合，持續整合系統如虎添翼，程式碼質量得到了有效改善。

同時新專案ZHJK專案上馬，經過SC專案的錘鍊新平臺在相容性穩定性上得到了大幅提升，同時與docker結合為平臺的微服務化提供了技術基礎。

在這個週期為了提升團隊的交流效率，搭建了wiki系統，進行培訓和技術分享以及專案資糧的管理。

還遠沒有結束

改進之路永遠沒有盡頭，下面是我們正在進行的改進：

1.引入TDD提高核心程式碼測試覆蓋率
2.引入BDD，jenkins整合fitenesse
3.jenkins對接docker，目標CD
4.前端的大規模重構，元件化

關鍵詞

分析
分析當前狀況是解決問題的第一步也是最重要的過程，我們針對我們的實際專案情況和團隊技術水平，制訂了相應的策略。
改進
自組織和追求卓越的團隊文化，是改進的基礎，同時改進措施要符合實際情況，不能心急，小步快跑，持續優化是改進的方向。

總結

技術不是目的而是手段
一切都離不開應用場景