2017年4月30日 星期日

twMVC #24 - 開發團隊的敏捷之路(未完成)

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

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

 


主題內容說明

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

 

簡報內容

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

 

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

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

主題內容說明

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

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 年所一同努力推展的工作。

 

敏捷開發

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

image

image

image

image

image

image

image

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

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

敏捷開發的幾個重點

  • 儘早並持續交付,短週期間隔經常交付可用的軟體
  • 駕馭變化
  • 溝通
  • 持續追求優越的技術與優良的設計
  • 自我組織的團隊
  • 定期自省,並適當地調整與修正

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

  • 團隊成員的接受度與技術能力
  • 團隊既有的開發流程
  • 開發團隊既有環境的限制
  • 各級主管的認知與支持
  • 公司文化

     

    團隊做了那些事情

    原本在 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。

    image

    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 一樣),所以個人的檔案、文件都可以放在上面做管理,而當有同事要離職時,就可以將工作的文件和檔案簽入到版本庫裡,就不用擔心日後因為電腦繳回後找不到文件與檔案了。

    image

    錯誤訊息與 Log 記錄

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

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

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

    image

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

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

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

    image

     

    產品佈署上線方式

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

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

    image

     

    永遠都是「未完成」敏捷開發之路

    我們還有很多挑戰,也還有很多沒有做到,也並非所有團隊都有做到單元測試的導入,也不是所有團隊都有做到敏捷開發,但我們團隊一直持續在協助各團隊的過程中去挖掘問題、接收回應,期盼能提供更加便利與順暢的開發、上線流程,並且持續與 IT 維運團隊合作,讓 Dev 與 Ops 雙方團隊的合作可以更加順暢。

    image

     

    推薦書籍

    我在簡報裡有提供了很多的書籍推薦,這邊在做個整理,真的希望每個開發人員與團隊都可以加以閱讀與吸收內容。

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

    image

     

    在團隊推動任何一項技術與方法的導入時,絕對不是僅憑一人之力就可以完成的,也不是一個單位四五個人就可以完成全部團隊的導入,有幾項關鍵因素是絕對必要的。

    一個有共同願景與目標的主要推動團隊,明白現在要為整個資訊部門做到什麼樣的目標,知道為何要推動,能夠達到什麼樣的效益。

    一個強而有力的意志與推動單位的主導者,在推動的過程中一定要遭受到各方的質疑,甚至直接遭遇到反對的聲音,因為推動單位有共同的願景與目標,在面對質於與反對時,不能因為少部分人而有所動搖,因為確信會對整個團隊帶來改變,所以必須要堅定推動與改變的意志。另外就是推動單位必須要有一個夠力並深知全部團隊的主導者,可以去說服其他開發團隊,並要求他們的團隊接受改變。

    全部開發團隊的信心與決心,如果只有推動單位一頭熱的去做這些事情,那麼最後的結果就是一切回到原點,什麼也不會改變,推動初期必須要讓全部開發團隊就能夠嚐到甜頭,例如直接去找到該團隊的痛點並且先解決掉(我們最先解決的痛點就是上線方式),一旦嚐到了改變的甜頭,該團隊就會期待下一步的改變並且願意優先嘗試。

     


    延伸閱讀

    如果開發團隊有使用 TFS 的話,千萬不要只是把 TFS 當作版本庫而已,工作項目管理、組建、發行、測試管理,這些功能都一應俱全,應用並發揮它的功能將會為開發團隊帶來極大的效益。

    以下是董大偉老師的文章,推薦給大家

    The DevOps Journey – Index

    the DevOps journey (0) - 敏捷開發真和每個開發人員有關?

    the DevOps journey (1) - 敏捷開發不相信時程預測?

    the DevOps journey (2) - 如果時程難預估,不如追求透明度…

    the DevOps journey (3) - 為何需要開發流程『自動化』…

    the DevOps journey (4) - 建立VSTS站台與專案(2017年Q1版)

    the DevOps journey (5) - 在VSTS站台與專案中添加成員

    the DevOps journey (6) - 安排與設定專案的迭代

    the DevOps journey (7) – 你的source code還沒上版控嗎?

    the DevOps journey (8) – 使用TFVC程式碼版控

    the DevOps journey (9) – 在TFS/VSTS中使用Git版控

     

    以上

  • 1 則留言:

    1. 感謝 kevin 大的文章,那場沒有辦法參加實在是太可惜了 QQ

      回覆刪除

    提醒

    千萬不要使用 Google Talk (Hangouts) 或 Facebook 及時通訊與我聯繫、提問,因為會掉訊息甚至我是過了好幾天之後才發現到你曾經傳給我訊息過,請多多使用「詢問與建議」(在左邊,就在左邊),另外比較深入的問題討論,或是有牽涉到你實作程式碼的內容,不適合在留言板裡留言討論,請務必使用「詢問與建議」功能(可以夾帶檔案),謝謝。

    最近的留言