2022年9月25日 星期日

敏捷轉型的四個階段

enter image description here過去這幾年,很榮幸有機會常常能跟企業分享敏捷觀念,甚至參與某些企業的敏捷導入。以前,一有機會主導,我立刻如火如荼,對組織進行一連串的推動。最近這一兩年,反倒開始會先觀察一下,針對企業內的同仁,做些正式或非正式的調查或訪問,然後再選擇比較適合該企業的導入策略。

因為幾年下來,我發現,所謂的數位轉型,大多都有底下四個階段,分別是『知識、信仰、習慣、文化』。

組織規模不很大的公司,在進行所謂的數位轉型,往往沒有很複雜,不管是bottom up(由下而上),或是top down(由上而下),總能說轉就轉。若來個強勢一點的老闆,一聲令下,立刻水到渠成。弱勢自由一點的新創公司,若能碰到有概念的同仁,從組織底層開始推廣,也常常一帆風順。幾年下來立竿見影,轉型成功,成效卓著。

但是,在規模比較大、或是年資比較老的公司,就沒那麼幸運了。你會發現,航空母艦的轉向常常需要不少時間,不同的階段還得有不同的節奏。你很容易看到,大企業老闆的一聲令下,但員工上有政策、下有對策,開始跟老闆比氣長,看誰撐得久。反正公司夠大,一時半刻也還死不掉,老闆從市場上感受到的轉型迫切度,在員工眼裡看起來很不明顯。反過來也是,感覺敏銳的一線同仁,嗅到市場的趨勢,開始想做些改善,從底層開始推動,但企業的中階或高層主管,卻還沉浸在看似漂亮的業務數字中,絲毫無法察覺風浪已經近在眼前。

這導致這幾年數位轉型談的多、做的多,但能有具體成效的公司數量卻很有限。

針對大型的企業,數位轉型有四個重要的階段,就是前面提到的『知識、信仰、習慣、文化』。

首先,必須讓企業同仁對於『改變』有一致的認識,這是『知識的建構』。讓同仁知道為何要改,該如何調整,是轉型的第一步。讓高階主管看到風浪、嗅到趨勢、針對轉型的必要改革有足夠的認識和心理準備。讓同仁們明白為何需要改變、將會帶來哪些好處與價值,如此才能夠從觀念與心態上建構轉型所需的動力。

從知識的建構到『相信』,往往會是第一個門檻。很多企業,就算有了轉型所需的知識,卻無法相信,如果不相信,怎麼從日常工作開始做起? 敏捷轉型是很好的例子,許多企業看到案例、上過教育訓練,也知道背後的原理和價值觀,甚至考過認證、知道敏捷框架和作法。然而一旦開始實施,碰到跟現行制度或過去的作法有衝突的地方,立刻自動回到過去的樣子,這樣如何轉型?

敏捷歡迎需求改變、即便在專案的後期,也沒有所謂的凍結需求。你知識上知道,跟你心裡相信,並且能身體力行,完全是兩個不同的層面。敏捷不相信甘特圖、不相信對未來的長期預估、不崇尚遵循計畫,敏捷要你打破部門的壁壘、讓不同部門的人組成團隊,天天坐在一起工作…這些,都跟以前的作法不同,甚至跟公司的政策與績效評估方式不同,如果你不打從心裡相信,怎麼實踐改變?

有了知識、並且相信,才算有了轉型的起步。
然後,你必須開始建立同仁的日常工作習慣。天天執行、周周回顧、常常調整與對齊、持續堅持到第一個成果出現、然後再繼續不停、不停、不停地做下去。

『習慣』的建立,需要經年累月。一直做到某個想法、某種決策、已經變成你的反射動作,在你碰到緊急關卡的時候,你發現自己,已經跟過去不同,你開始反射性地用新的思維去面對問題、去尋找答案、去解決衝突或挑戰。直到這一刻,所謂的轉型才算有初步的果實。

而最後一步,是把習慣內化成企業的DNA、變成組織的『文化』。文化的出現,絕對是組織多個部門多次迭代後的成果,非一朝一夕,一蹴可及。但如果不刻意去培養,好不容易建立起來的習慣,會慢慢退化還原成原先的樣子,這就是文化的威力,文化改變人於無形。

『知識、信仰、習慣、文化』這是小公司為何轉型容易,大公司為何相對困難的原因。
變革並非遙不可及,但在對的時間,用對的人,做對的事情,才能夠讓數位轉型真正落地。

2022年8月21日 星期日

Azure DevOps in Action - 如何避免開源套件的使用風險

enter image description here
近代軟體開發,不管是使用哪一種語言,幾乎都一定會使用到套件(Package),套件的使用都有著非常重大的意義。套件不只是讓開發變的更方便,套件的版本管理,能夠讓專案之間的相依性被有效管控,避免dependency hell的發生。

所以各大開發語言,不管是node.js、python、Java…都有自己的套件庫,微軟的.net當然也是,nuget就是.net開發人員的標準套件庫。如今,使用套件庫上的組件來開發企業內的專案,已經是理所當然的習慣了。

套件庫的使用風險

然而,使用套件並非100%毫無風險,由於開源軟體的觀念盛行,這個時代任何人都可以將自己開發的套件貢獻上nuget讓大家使用,雖然開發社群與nuget站台會針對有潛在或惡意風險的套件提出警訊,但由於這些資訊並非即時提供,且有可能因為開發人員的疏忽而沒有被發現,導致你的專案使用到有品質不佳,或是有安全疑慮的套件。

除此之外,套件還有許可授權的問題,並非每一個套件使用上都是毫無代價的,雖然nuget會要求套件開發人員具體標明套件的使用授權許可,但倘若開發人員不察,使用到一些並非可以免費使用的套件,或是使用到了標註為GPL的套件,那你依賴該套件開發的專案,也會被要求開源,這對於公司來說,可能會造成一場災難…

在CI Pipeline中掃描套件

因此,為了避免軟體開發人員一時疏忽,CI Pipeline有必要針對軟體套件的使用作一些掃描和檢查。而WhiteSourceBolt就是這樣的一套免費工具。

你可以在Azure DevOps Pipeline中,加入WhiteSourceBolt這個task,就可以輕易的掃描整個專案中使用的套件:
enter image description here

呈現出的報表如下:
enter image description here

你會發現,報表中清楚的告訴我們,哪些套件是高風險的,並且原因為何(上圖A)。如果你的專案有紅色高風險套件,強烈建議你要立即著手處裡(升級版本或尋找替代套件)。

要在Azure DevOps中啟用WhiteSourceBolt非常簡單,只需要為你的組織安裝Azure DevOps Marketplace中的外掛:
enter image description here

下載位置位於:
https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt

安裝好之後,你重新進入Azure DevOps,可以看到在Pipeline選單下,出現了WhiteSourceBolt:
enter image description here

請點選進去,輸入你的聯絡方式註冊後即可使用。

接著,請進入Pipeline,在其中加入WhiteSourceBolt task,並且設定working directory:
enter image description here

完成之後,重新觸發運行pipeline,完成後即可看到報表囉:
enter image description here

幾個小小的動作,讓專案免於套件使用的風險,非常划得來吧。


YouTube頻道:https://wwjd.tw/809k364
電子書: https://www.pubu.com.tw/ebook/288713
最新著作:

https://www.tenlong.com.tw/products/9786263241251?list_name=b-r7-zh_tw

內容審查(Content Moderator)服務

enter image description here
當網路上出現一則訊息,誰有權力判斷這則訊息的真假?
1.政府 2.平台業者 3.KOL(Key Opinion Leader, 意見領袖) 4.我自己

上面這個問題,不知道你的答案會選擇甚麼?

這兩天沸沸揚揚的中介法,造成了很多網路上的輿論。主因是平台業者被要求有責任管理(刪除或標註)不實言論,否則要罰款。

但這中間出現了兩個問題 1. 誰決定不實? 2. 如何做到有效即時的內容管理?

身為技術人員,我想從技術的角度談這件事情。首先,有沒有可能即時發現用戶將有問題的內容張貼到網站上? 技術上確實有可能。

現在微軟Azure, AWS, Google都有許多雲端AI服務,可以辨識圖片、影音、文字,近乎即時的判斷內容是否涉及情色、猥褻、或是具有冒犯意味甚至鼓吹自裁。這服務微軟叫做 Azure Content Moderator,內容仲裁。總的來說,在當今的AI技術上,我們早就可以針對圖片、影像、或文字進行客觀的內容判斷,這些技術已經逐漸成熟,經驗上準確度大約八九成沒問題。

所以各大網站(像是FB)可能早已把這些技術用在內容分析上了(如果你的網站也需要,但不知道該怎麼做,可以與我聯繫)。但問題是,這些AI服務,可以判斷內容,無法知道對錯。

因為內容的正確與否,涉及價值觀的判斷。
在這個世界上,並不是所有事情都是非黑即白,一翻兩瞪眼的不是對就是錯,更何況,真假對錯很可能因為時間而有所改變。一開始你可能以為是對的(內容為真),但經過時間,很可能發現是錯的(內容為假),反之亦然。舉個更簡單的例子,不同世代對於同一件事情的看法,也往往南轅北轍。

如果第一時間不分青紅皂白的,就直接屏蔽刪除或標註某種論點,很可能事情將永遠沒有水落石出的一天。當然,如果你不在意真相(只在意管理),也就無所謂。

所以,從技術的角度來說,現在的科技就算不用靠誰立法、無須哪個單位協助,單單使用AI技術,就足以判斷內容是否違背善良風俗,這個也早就在做了。然而問題是,會不會我覺得的裸露、是你覺得的藝術呢? 這條界線該如何決定? 誰決定? 因為一旦涉及主觀價值判斷,所有的一切就變的不再簡單。

因此,AI就算能幫你辨識內容,卻無法幫你判斷真偽。
是非、對錯、真假,都很難由誰單方面說了算。

因此,我們再看一次這個問題。
當網路上出現一則訊息,誰有權力和責任判斷這則訊息的真假?
1.政府 2.平台 3.KOL(Key Opinion Leader, 意見領袖) 4.AI(人工智慧) 5.我自己

好,現實問題是,網路層出不窮的假訊息,詐騙事件頻傳,已經對很多人造成傷害,如果不該由特定單位、特定人來過濾特定訊息,那該怎麼辦? 難道讓人民自己判斷?

底下有個關於真偽的小故事…
有人問銀行裡面假鈔辨識員 : 為何你能夠瞬間就識別出仿製精良、栩栩如真的假鈔? 你們是有受過什麼特殊的訓練嗎? 是不是因為早已看過了市面上每一種假鈔,所以才能迅速識別?

行員回答: 我是沒有看過每一種假鈔,但我因為每天都在看真鈔,所以碰到假鈔自然比一般人敏感一些。

就是這樣,沒別的答案了。
所有的真假,都涉及主觀判斷。

真的訊息可以聽起來匪夷所思,假的訊息也可能看起來毫無破綻,不是有權力、有資源的單位就一定可以判斷正確。如果無法讓人民成熟、成長…到有獨立判斷的能力,那一切最終都是白搭。更何況,與其相信政府、相信特定KOL、相信特定網站平台的判斷,那我還不如相信AI,因為至少,我知道這些雲端AI服務,設計的時候已經盡量排除既定的價值觀(主觀)。

然而,真正能判斷對錯是非的,永遠只有自己。

政府該做的,是提供民眾更多的管道、教育資源、技術,來幫助民眾自行判斷(決定)真偽,並且持續增加民眾的素養,讓大家有能力自己做出正確的判斷。而非幫民眾進行內容審查,或由特定單位(或網路平台)來幫民眾決定真假是非對錯。

最近開飛機的湯姆克魯斯很紅,但我卻想到另一部他主演的電影–《關鍵報告》(Minority Report)。劇中的預知科技,可以讓罪犯在還沒行動前就被制止,在還沒造成傷害前就把加害人給逮捕,這樣的社會看似超完美,完全沒有任何犯罪。所有可能的犯行都被預先銷聲匿跡於無形。

但這真是你要的世界嗎?

網路假訊息確實造成了很大的困擾,網路霸凌、情色甚至手機成癮都引發了不少的問題,但這現象表示,人類的理智與成熟度似乎跟不上網路發展的快速。這意味著,我們必須投入更多的資源,來培養人民獨立判斷是非、獨立思考的能力,而不是簡單的封鎖、禁止、遮蓋或屏蔽。當然,我知道這樣做在技術上簡單多了。

然而解決核心問題,才是我們需要有權力、有資源的政府和與單位,更多投入心力的,不是嗎?

2022年8月19日 星期五

Let it be

每當寫程式或文稿累了的時候,我會到河堤騎車。

最近這幾年,台北鄰靠基隆河的兩岸,都有了挺不錯的自行車道,幾乎沒甚麼難騎的上下坡,很適合以悠哉閒逛的心情慢慢騎吹吹風…
enter image description here
一天,忙了一整個下午,趁夜幕微微垂下,趕在日落前,我租了YoiuBike在河堤邊緩緩騎乘。岸邊隨風飄來青草的香味,讓人很是愉快。

正當我覺得身心放鬆,通體舒暢。卻不知耳邊何時傳來了一陣犀利(你要說淒厲也行)的對談聲,有點像是你去傳統菜市場會聽到的那種婆婆媽媽在攤販前理直氣壯的討價還價聲,聲音從遠而近,由小而大,漸漸飄了過來。

仔細一聽,位於六點鐘方位,後方。
一群騎著貌似淑女自行車的大媽,集團似的緩緩逼近。

我側眼一瞥,數了一數,五位。喔不,是六位,其中一位有些落單,奮力的在後面追趕。

前面五位大媽,領頭的三人,並排而行,佔據了來往雙線車道,伴隨著中氣十足的對談,讓人不注意到她們都很難。雖然距離有些遠,但言談中我依稀聽到關於某位大媽的兒子的太太的最近一些態度問題…呃…不關我事,非禮勿聽,我騎我的車。

加速前進。

可能是我租賃的YouBike齒輪比不佳,也可能是每天騎車的大媽中氣十足,我雖然加速超前了一定的距離,但每當我放鬆開始欣賞河邊的景色和迎風吹來的芬芳草香,一不注意,這群大媽集團立刻從後方逼近。一連數次,我在聽到了大媽們對談的特殊嗓音時,才意識到我快要被集團軍輾斃,只能瞬間加速遠離…但沒多久,我優閒的騎車氛圍就又會被身後堅持出現的音量所打破。

大媽們像是擁有裝上了勁量永備電池一樣的持久續航力,以堅毅且穩定(甚至我覺得似乎有愈來愈快)的速度屢屢逼近。

每當大媽集團軍從後方接近,我airpods裡的音樂聲量,總是不爭氣的敗陣下來…
當這條沿岸車道已經騎了約莫三分之二時…我,終於做出了決定。

在車道轉角處的某一個空曠處,我停了下來。站穩步伐,拍拍身上的風沙灰塵,好整以暇的,帶著敬佩與釋放的心情,目送大媽集團軍隊從我眼前騎過去…

喝了口從家中帶出來的水壺裡的氣泡水,整理了一下裝束,跨上自行車,我開始緩緩而行。

我何苦讓自己被身後追趕的雜音持續干擾著呢?

人生旅程上總是會碰到不同的人群,路程上人來人往、來來去去,我又不是要和誰比賽,幹嘛跟自己過不去,身後的雜音,不如就讓它從眼前過去。

等雜音遠離,我戴上耳機,依舊開始自在的騎自己的路,欣賞屬於自己的風景,以我自己習慣的速度,自由前行。

2022年7月25日 星期一

Azure DevOps in Action - 使用Deployment Group進行地端大量部署

enter image description here
使用Azure DevOps Services,部署到雲端相對容易,部署到地端環境,得考慮的事情就多了。主要的原因是,Azure DevOps Services在雲端,無法(也不應該)直接跳過防火牆存取地端環境上的伺服器。

另外,如果不管是雲端或地端伺服器,若是HA(高可用性)架構,做了負載平衡(Load Balance)或是Failover,部署站台時,需要把同樣的artfact一次部署到多台伺服器,在pipeline的設計上也有一定的難度。

上面提到的這些事情,解決方案就是『Deployment Group』。

功能說明

Deployment Group可以讓你把特定artifact一次部署到多台伺服器,同時,也可以突破防火牆的限制,從雲端部署到地端。其中的關鍵就在於,你必須在伺服器端安裝一個代理程式。

我們來看一下底下這個準備好的情境,我們準備了兩台Windows Server 2019 VM,名稱分別是testdpvm1與testdpvm2。並且,在這兩台伺服器上開啟了IIS,也運行了基本的網頁如下:
enter image description here
同時,我們也建立了一個Azure DevOps Team Project,其中的repo很簡單,只有一個html檔案:
enter image description here
並且,我們為這個repo的部署建立了一個CI Pipeline:
enter image description here
這個CI Pipeline的功能也超單純,只是打包這個 .html頁面成為 .zip檔案,然後放入(publish)到drop資料夾,準備給CD Pipeline使用。

建立Deployment Group

接著重點來了,我們待會要將drop資料夾中的artifact透過CD Pipeline如同『穿越防火牆』一般地『同時』發佈到那兩台剛才建好的VM上,為此,我們來建立Deployment Group。請在Pipeline功能中,找到Deployment Group,並且建立新的Deployment Group:
enter image description here
接著,為Deployment Group命名,一般採用的是你的環境名稱,例如Dev、QA、Production…等。

然後,請複製出現的PowerShell Script (別忘了要勾選Use a personal access token in the script for authentication):
enter image description here

運行代理程式

接著,請到剛才那兩台VM上,以PowerShell的admin模式,執行複製的PowerShell Script:
enter image description here
其中的問答都以enter跳過即可。

完成後,你回到Azure DevOps的Deployment Group畫面檢視,會看到兩個agent已經出現:
enter image description here

透過deployment group進行部署

接著,我們來設計CD Pipeline,你可以透過『IIS WebSite』這個關鍵字過濾,找到『IIS WebSite Deployment』這個範本:
enter image description here
這個範本預設採用Deployment Group Job:
enter image description here
你只需要透過設定畫面選擇剛才建立好的Deployment Group名稱,你會發現,上圖右下角畫面會出現該Group預計部署的機器數量。

接著,在job中只需要保留IIS Web App Deploy這顆task即可:
enter image description here
設定完成之後,我們可以試著運行CI Pipeline產生artifact。接著,觸發CD Pipeline進行部署:
enter image description here
如果部署成功,將會出現底下畫面:
enter image description here
這表示兩個環境都成功了,我們來看運行的結果:
enter image description here
果然,兩個站台上的網站都變成我們CI Pipeline所建置出的artifact了。透過Deployment Group,我們可以不僅可以進行目標站台的大量部署,同時,由於目標環境上安裝友agent,我們也可以突破防火牆的限制,部署到地端或是較封閉的環境,Deployment Group的使用是一個非常重要的技巧。


更多資訊:
Azure DevOps 顧問實戰
https://www.tenlong.com.tw/products/9786263241251?list_name=b-r7-zh_tw

電子書:
https://www.pubu.com.tw/ebook/288713

教育訓練:
https://www.studyhost.tw/NewCourses/ALM

2022年6月18日 星期六

快速產生 .net core 測試程式碼覆蓋率報表

enter image description here

昨天,幫客戶介紹 .net core 的單元測試(Unit Test)開發。

其實,單元測試(Unit Test)是個非常簡單的概念,近代開發工具本身也都進化的超級方便,輕輕鬆鬆的就可以建立出單元測試專案的架構。

單元測試(Unit Test)看起來一點都不難。

這話只對了一半,單元測試難的地方並非撰寫單元測試程式碼本身(甚至,單元測試程式碼本來就應該盡可能的簡單,簡單到不該出現邏輯),難的地方是為了實施單元測試前的程式碼重構(如何增加程式碼的可測試性),以及如何在企業內真的推廣和實作。(因為上至主管下至開發人員,總有成千上百個看來非常合理的理由,解釋為何自己現階段無法導入單元測試)

不過,這些困難的問題,我們留到課程裡面再討論。

我們今天先來看一個簡單的,如何在 .net core 產生測試程式碼覆蓋率的報表。

其實,只有三個動作,第一個,請安裝 .net tool:

dotnet tool install -g dotnet-reportgenerator-globaltool

然後
透過 dotnet CLI 跑一次單元測試進行資料蒐集,記得請在 .sln 或 .csproj 所在的目錄下執行:

#收集資訊
dotnet test --collect:"XPlat Code Coverage"

請注意上面的 --collect:“XPlat Code Coverage” 參數,是為了蒐集單元測試涵蓋率資訊,執行完畢之後,會出現底下畫面,請特別注意XML檔案所在位置:
enter image description here

因為我們下一個指令需要該位置資訊。

最後,請執行:

reportgenerator  -reports:"路徑\coverage.cobertura.xml" -targetdir:"report" -reporttypes:Html

嘩啦,單元測試涵蓋率報表出來了(位於report資料夾中,還是HTML格式的),就這樣:
enter image description here

簡單吧~

2022年5月26日 星期四

迭代、敏捷 與 滾動式調整

enter image description here

今天上課的時候,跟同學聊到,最近很流行的一個詞彙 『滾動式修正』(或 滾動式調整)。

不知道你自己對這個詞的定義是什麼? 所謂的『滾動式調整』是不是走一步算一步? 是不是朝令夕改的美化版? 是不是先做再說,後面再看著辦?

儘管很多人不明所以,但『滾動式調整』這個詞彙這幾年仍被許多團隊理所當然地使用著。為何過去從沒聽過,這幾年卻如此盛行? 我自己覺得,和敏捷(Agile)似乎脫不了關係。

敏捷(Agile)存在的意義,是因為我們認知到並承認,現今外在環境的變化實在太快了,快到我們再也沒法像過去一下,先妥善地做完計畫,然後再動手實行。如果堅持如此,將會錯失先機。

此外,更重要的是,倘若沒有先著手實施,試著得到外界真實的反饋,只在辦公室裡籌算,即便覺得計畫得再周密,一但拿到真實世界裡,很可能就會立刻破功。

這兩者都是同樣的前提 --> 這個世界變化得愈來愈快。
這也是敏捷之所以日趨主流的原因。

而敏捷的被認可,或多或少讓『滾動式修正』變得理所當然。然而,真的每一個組織,每一個單位,每一個計劃,都適合滾動式修正嗎?

今天上課談的是DevOps。
我問學員:『如今需求變化快速已不可避免。假設,持續交付 (所謂的持續交付,一般是指一天數次這樣的頻繁上版,最少也是一周數次,不會更低)是必須的,那什麼是持續交付的基礎?』『一家公司、一個團隊,一個專案,能夠毫無準備的就實施頻繁交付(CD-Continuous Delivery)嗎?』

答案是 : 『不能』。

因為,沒有良好準備的頻繁交付,將會帶來災難

頻繁交付的前題是持續整合(CI-Continuous Integration),持續(密集)到什麼程度? 最好應該是一天數次,至少是一周數次,將程式碼頻繁的簽入並且合併至主線(main)。同時在合併前進行程式碼品質掃描、安全性掃描、單元測試。如果這些都沒做到,那請容我這麼說,目前這個團隊(專案)恐怕還不到可以實施頻繁交付(CD-Continuous Delivery)的程度。

所以,持續交付(或謂 頻繁交付,不過這兩者其實有些許不同)的前提,是良好的基礎建設(這邊指的基礎建設是指 CI - Continuous Integration)。

同樣的,若企業想要執行『滾動式修正』,你的團隊和行政體系必須要有足夠良好的體質,這體質指的是 : 快速的執行效率、順暢的溝通管道、卓越的行政系統、高效的組織架構。不僅如此,還要有良好的防呆機制和安全性防護措施(就如同我們在CI的過程中,有著各種自動化檢查和安全性掃描一樣)。

唯有已具備良好體質的團隊,在面對快速迭代、持續修正的計畫與指令時,才能游刃有餘。

否則,我們的『滾動式修正』將帶來災難,大家看到的只會是『滾動』,而沒有『修正』。沒有辦法得到持續修正、持續改善的效果。要記得,並非所有的『滾動』都會帶來價值,就如同並非所有的『頻繁交付』都會為帶來價值一般。

我們真正想要的並不是滾動,而是修正。正如同敏捷想要的並不是迭代,而是持續改善

唯有頻繁修正、持續改善才是價值的來源。而為客戶帶來價值,才是我們真正想要實現的成果。

熱門文章