mrkt 的程式學習筆記: twMVC #24 - 開發團隊的敏捷之路(未完成)

這一場的發表日期是在 2016-10-01，距今已經是七個月前的事情了，原本應該是在活動之後就會整理一篇文章說明，但因為工作繁忙以及懶惰的緣故，所以一直拖到今天才寫出來，這期間的 twMVC 研討會都已經來到 #27 了，然後在下個月（2017-05-13）也即將舉辦第 28 場囉。

關於講題名稱，一開始公開的時候是有很多人誤會，所謂的「未完成」並不是說要講的內容尚未完成，而是在說明一個團隊的敏捷之路並沒有所謂的「完成」，敏捷是一直持續進行並且是持續改善的，沒有完成的一天，而我是以工作團隊在過去一年當中所帶領推動的一系列改變來做說明，希望可以作為其他團隊的借鑑。

主題內容說明

很多團隊存在很多現實的問題，會嘗試著使用很多方式去解決，
這幾年敏捷開發已成主流，似乎這些困擾著團隊的問題就可以迎刃而解，
但聽了許多敏捷的課程，也看了一堆書，真的就可以完全瞭解嗎？
許多企業和開發團隊也喊著要導入敏捷，卻對敏捷開發存有嚴重誤解。
這次的內容不是要說什麼是敏捷，也不是要分享團隊如何成功建立並且完成敏捷開發，
分享一個團隊邁向敏捷開發卻尚未完成的過程。

簡報內容

twMVC#24 開發團隊的敏捷之路(未完成)—twMVC Docs.com

每間公司、開發團隊裡在做任何新技術的推動時或多或少都會遇到困難，既使是新創團隊也是一樣，而那種所謂大型公司且具有一定歷史的資訊團隊，包袱重、員工多、年資長，在推動時更是可以感受到各種的阻礙，而我就是身處在這樣的環境裡，感受是相當深刻的。

其實 trwMVC#21 可以視為 #24 的前半部，#21 我並沒有寫文章作說明，所以就在這邊也一併介紹，

twMVC#21 - 以實例說明ASP.NET Web API 服務的開發與測試過程 (2015-12-12)

主題內容說明

現在越來越多服務都使用 ASP.NET Web API 建立，從開發前的規劃、開發進行實作，一直到服務上線的過程應該要做些什麼與注意什麼，在開發的同時如何導入單元測試以及如何實作開發完成後的整合測試，以一個已經上線的 APP 後端 Web Api 服務來做實際案例說明，以及開發的心路歷程。

twMVC#21以實例說明ASP.NET Web API 服務的開發與測試過程—twMVC Docs.com

2015 年所講的這個主題，是以我所做的一個專案開發過程為主題，在當時公司所做的專案都沒有使用相類似的架構與開發模式，所以當初的出發點就是要讓這樣的架構與開發模式作為往後公司新專案開發的範本，依據物件導向開發，實做專案軟體分層架構，導入單元測試、整合測試，專案加入各種工具、套件等，在開發當時也的確是讓同事們造成不少驚嚇與衝擊。在 2015 年中有個新專案要開發的時候，也完全依照我的專案架構與開發方式，到最後也有很好的產出結果，並且也在使用端得到不少好的回饋。

以 #21 的主題，把講題內容所提到的工具使用、開發方式做了整理，也寫了好幾篇的文章，
文章如下：

Postman 功能 - Generate Code Snippet
ASP.NET Web Api - Help Page
ASP.NET Web API 文件產生器 - 使用 Swagger
Swashbuckle - Swagger for Web Api 顯示內容的調整
 ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
ASP.NET Web API - Import a Postman Collection Part.3 最後完成版
 使用 NanoProfiler 對 ASP.NET Web API 進行性能監控
 NanoProfiler 對於資料庫存取的監控 - ADO.NET
NanoProfiler 對於資料庫存取的監控 – Dapper
NanoProfiler 對於資料庫存取的監控 - Entity Framework
NanoProfiler 設定 - Profiling Configuration

在 2015 年開發 App – WebApi 專案的時候，雖然使用了相對於公司其他專案截然不同的開發方式與架構，也得到同事的支持和接受，但影響範圍只有在單一個開發團隊而已（約 20 人），但公司還有其他三個開發團隊（約 55 人）還是使用各自的開發方式與傳統架構，我的想法與目標還是希望能夠將這套架構和做法推展到所有的團隊和開發者。

另外在開發的同時也發現到一些基礎建設的不足，首當其衝的就是版本控管方式與管理混亂，再來就是專案的發行、部署方式複雜與紊亂，專案文件與共用檔案的分散和不易管理，另一個是 Log 記錄，還有共用套件的管理。而這些也就是 twMVC#24 講題所要講的事情，也是我與我所屬單位的同事們在 2016 年所一同努力推展的工作。

敏捷開發

我想什麼是敏捷開發、內容是什麼、如何實行等等，這邊我就不用再做說明，我也在簡報裡有做了詳述，在「公開版」的簡報裡我將現場版的簡報做了調整，不過在這邊將那幾張投影片內容放在下面，

以上的小故事是真實發生的，而且是我的親身經歷，這也應該是許多正在推行或已經導入敏捷開發的團隊裡最常被人質疑與誤會的，尤其是在管理階層，因為「敏捷」這兩個字，所以就常常被人給誤會，別說管理階層，就連開發者本身也是時常搞不清楚所謂的「敏捷」指的是什麼。

敏捷，指的是可以快速的反應需求變化。無法保證可以讓開發速度加快，而通常的情況下非但不會讓整體開發速度加快，而會讓開發時間加長，但錯誤修改、需求變更的反應速度與週期將會簡短。

敏捷開發的幾個重點

儘早並持續交付，短週期間隔經常交付可用的軟體

駕馭變化

溝通

持續追求優越的技術與優良的設計

自我組織的團隊

定期自省，並適當地調整與修正

推動敏捷開發所面臨的挑戰

團隊成員的接受度與技術能力

團隊既有的開發流程

開發團隊既有環境的限制

各級主管的認知與支持

公司文化

團隊做了那些事情

原本在 2015 年時，我所屬的原單位就已經有排定計畫要做 CI 持續整合與 RM 發行管理，屬於 CI 持續整合所以做的項目有：

程式版本控管 – 使用 Git 及採用 Git Flow

自動化測試 – 於專案開發導入單元測試

程式碼品質 – 程式碼規範、落實 Code Review

缺陷管理 - Issue Ticket

訊息通知 - Notification

而 RM 發行管理是為了要取代當時混亂且多種的上線佈署方式，因為很多專案是不同時間所開發的，各個時期所使用的上線佈署都不太一樣，有的比較早期的專案還仍然維持人工複製檔案的更新方式，而有的專案還會有兩個版控，一個是開發用而另一個是上線用，搞到最後都不知道要以哪一個版控為準，也不知道哪一個版控有最新、最完整的檔案，所以必須要有一個一致的做法來改變這些上線亂象。

不過原本是要在 2015 年由原來部門的同事們一起完成的，但最後也因為公司有其他重要專案要開發，所以很多項目就無法實行與完成，但至少新專案的開發都已經導入 Git 版本控管的使用，以及導入單元測試甚至於整合測試了。

DevOps

從 2015 年開始 DevOps 相關議題與討論就相當熱絡，而 DevOps 指的是 Development 與 Operations 的整合，重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發布更加快捷、頻繁和可靠。

DevOps 的三個關鍵點：敏捷、透明度、自動化

有關 DevOps 的相關文章和資訊、書籍都已經相當多了，所以這部分就不做說明，如果未曾聽過 DevOps 或不是很瞭解的朋友，我建議可以觀看董大偉老師的演講「推動 DevOps 轉型的成功」，將對於 DevOps 會有更進一步的瞭解，也可知道要如何在團隊裡推動敏捷開發與 DevOps。

https://channel9.msdn.com/Events/DevOps-TW/2015-DevOps-Day/b01

團隊所面臨到的問題

在 2016 年的時候，我由原來的部門更換到了另一個新設立的單位，而這個團隊所面對的是公司整體的資訊開發團隊，所面對到的不只是一個部門而是好幾個部門，單位的同事們所面臨的問題也更為嚴峻，

版本控管混亂，容易造成錯誤

專案文件及檔案的管理

產品錯誤訊息不及時、Log 記錄查詢不易

元件及套件使用、發佈與管理的問題

產品上線方式紊亂

版本控管

TFS 過去相當混亂，不管是版控、版本庫或是權限，都相當混亂，為了要統一管理，所以另外以 TFS2015 建立新的版本庫，然後逐一將放在舊 TFS 上的專案轉移過去。新的 TFS 不管是 Collection 或是權限等等，都是全新規劃的，在轉移的過程裡也讓各單位去重新盤整自己的專案，哪些還是運作、哪些已經是走入歷史。

新的 TFS 完全導入並使用 Git，這對於過去慣用 TFVC 的開發同仁是個挑戰，過去開發同仁使用 TFVC 並沒有很好的習慣，完全把版控當作檔案庫在使用而已，所以轉移使用 Git 之後，要讓所有的開發團隊去學習使用 Git，並且適應使用分支與 PR。這過程的確是相當辛苦，好在有同事不辭辛勞的協助，經過一年之後，所有開發人員也已經完全接受與適應了。

專案文件與檔案管理

相信很多公司與團隊在管理與維護開發文件的做法依然是會在一台 File Server 上建立資料夾，然後再以分享資料夾的方式去加入相關人員，讓大家可以存取專案文件和檔案，但是這樣的做法就是「亂」，而且文件版本管理不易，更別說資料夾權限的管理了。

另外就是我再開發專案或是研究學習一些技術或是製作一些 Lab 的時候，我也想要使用版控，但又不可能在專案的 TFS 上去建立我個人的版本庫，所以我就想要有一個別於工作專案使用的版本庫，好讓我放這些 Lab 程式與文件。

於是新團隊建立初期就使用 Gogs 這個使用介面相當類似 Github 的版本庫服務（感謝 twMVC 的伙伴介紹，以及感謝當初建立這個服務的前同事 - 軟體主廚 [ 軟體主廚的程式料理廚房 ]），建立初期是讓資訊團隊的同事先使用這個服務去練習與熟悉 Git 操作，到現在各個專案的文件、檔案管理都已經在使用，另外各部門、單位也會使用 Gogs 來管理單位的文件與檔案，因為每個資訊團隊的同事都可以有個人的帳號（如同 Github 一樣），所以個人的檔案、文件都可以放在上面做管理，而當有同事要離職時，就可以將工作的文件和檔案簽入到版本庫裡，就不用擔心日後因為電腦繳回後找不到文件與檔案了。

錯誤訊息與 Log 記錄

以往資訊團隊已經有捕捉與記錄系統 Exception 的機制，但做法是各系統將捕捉到的 Exception 先寫到資料夾裡以文字檔存放，然後各 Server 會有排程工作定時將這些文字檔複製到一台專門處理文字記錄檔的 Server 裡，最後會有服務去將這些記錄寫回資料庫裡。運作多年也都相當順暢，但當遇到有系統的運作是相當頻繁且一直有錯誤出現時，所產生的文字檔就會以不可思議的方式增長，連帶的就是影響資料寫回資料庫的速度，曾經有好幾次就因為後端服務來不及消化文字檔，而讓錯誤記錄延遲了三、四天以上，也就是當你要知道系統出了什麼錯誤而你想要知道詳細內容時，你要三天後才能夠在功能頁面上看到相關資料。

另外除了錯誤記錄外，我們也會需要去記錄一些系統訊息，已瞭解一些系統工作的內容和資訊，但這些處理在過去都是各開發團隊自己處理，而大部分的做法就是將 Log 寫在文字檔裡，但衍生的問題就是難以去追查這些記錄在文字檔裡的資料，而且公司 DBA 的立場是不允許開發團隊將 Log 直接寫入到資料庫裡，對我來說這些 Log 是相當重要的，所以我急需一個 Log 服務（公司不允許使用外部服務，也就是公司系統的 Log 不能存放在外部服務）。

最後我所採用的是 Exceptionless，雖然是個線上服務，但是確有將原始碼給公開出來，所以可以建立自己的 Exceptionless 服務，但服務所必須的 Elasticsearch 就必須由自己架設與管理。大家不要想說可以自己架設這些服務很好，當只有一兩個專案在用的時候是不會有什麼感覺，一旦是全公司的所有系統都要使用的時候，你就知道為何 Exceptionliess線上服務的收費要那麼貴了（以價制量呀）。

目前公司所有新開發的系統都已經使用內部的 Exceptionless 服務了，大部分是以記錄 Exception 為主，也有部分專案會使用 Log 功能，無論是哪一種 Log 資料都可以及時察看系統 Log 資料，而且也可以使用查詢功能快速的查詢 Log 資料。

元件及套件使用、發佈與管理

以往公司會有建立共用的底層元件，但還是以網路資料夾的方式讓專案去參考使用，也有團隊會去建立 Nuget Server 去管理 package，而前端團隊也需要有個地方可以放置自己製作的 npm package，所以最後所採用的是 ProGet 這個服務，讓團隊有一致的套件使用、發佈的地方。

產品佈署上線方式

前面有提到過，以前資訊團隊有很多的上線方式，甚至於衍生出開發與上線會有兩個不同版控的現象，我們希望可以讓人工手動去做系統上線或檔案複製到正式機的狀況可以被自動化給取代，所以團隊另一個同事 Phoenix ( Phoenix's 技術學習記事 ) 就全力研究 TFS 的組建和發行功能。

到目前為止，雖然還是有極少部分的系統還是維持原本的上線方式，但大部分的系統都已經完全使用 TFS 的組建和發行功能做上線的工作，而且與 Git 版控流程作結合，如果有導入單元測試的話，就會在上線前做全部單元測試的執行，確保上線的程式都有通過全部的單元測試。這在兩年多前我剛到公司的時候還是個遙不可及的目標，但現在已經完全做到了。