可維護性.sbv

可維護性.sbv

0:00:00.000,0:00:01.000
還有一兩位

0:00:06.490,0:00:10.490
OK,OK,忘記拿了,OK,你拿

0:00:12.490,0:00:14.490
大家好,我是宥辰

0:00:14.490,0:00:16.490
那因為時間關係

0:00:16.490,0:00:18.490
這裡有一個QR Code

0:00:18.490,0:00:21.490
是可以載到這一份資源

0:00:21.490,0:00:24.490
那它也是一個線上的投影片

0:00:24.490,0:00:26.490
所以不確定手機好不好瀏覽

0:00:26.490,0:00:28.490
電腦可能比較好

0:00:28.490,0:00:30.490
那我等一下會直接挑幾個比較

0:00:30.490,0:00:32.490
我覺得比較重要的地方講

0:00:35.866,0:00:37.866
有

0:00:37.866,0:00:39.866
有吧

0:00:39.866,0:00:41.866
好

0:00:41.866,0:00:43.866
那就繼續了

0:00:49.882,0:00:53.882
好,我們先快速講一下可維護性

0:00:53.882,0:00:57.882
好,這是本來的agenda

0:00:57.882,0:01:03.882
那可維護性,為什麼我們在數位軔性這個議題中特別有提到可維護性

0:01:04.832,0:01:07.832
為什麼對於韌性這麼重要

0:01:07.832,0:01:10.832
因為我們對韌性有個簡單的定義是

0:01:10.832,0:01:13.832
系統在變動的環境下

0:01:13.832,0:01:16.832
持續提供美好服務的能力

0:01:16.832,0:01:18.832
那在這個定義之下呢

0:01:18.832,0:01:23.832
韌性其實是可用跟易用跟安心用

0:01:23.832,0:01:25.832
這三個結合嘛

0:01:25.832,0:01:29.832
那這三個結合我們可以把它當成

0:01:29.832,0:01:31.832
乘法來看

0:01:31.832,0:01:33.832
任何一項為零的話系統就沒有價值

0:01:34.554,0:01:41.554
舉例來說,如果有個系統可以連的上很好用,又可以幫用戶解決問題

0:01:41.554,0:01:46.554
但是我用了系統之後,隔天就收到詐騙電話

0:01:46.554,0:01:49.554
那就是,安心用是零

0:01:49.554,0:01:52.554
那最後我會,即便我買到書了

0:01:52.554,0:01:55.554
還是覺得這個系統非常的不值得信任

0:01:55.554,0:01:58.554
非常的 Negative ,就是負的

0:02:02.416,0:02:08.916
可是呢,這個價值並不是擋一下而已,而是要持續下去

0:02:08.916,0:02:15.916
所以我們加上了好維護這個項目的話,就是所謂的保持韌性

0:02:40.581,0:02:46.581
本來我會舉幾個例子講架構如何達到可維護性

0:02:46.581,0:02:50.581
那架構講完之後呢,還有另外一part更重要的就是流程

0:02:50.581,0:02:54.581
其實流程也要做到do less 來達到可維護性

0:02:54.843,0:02:56.123
維護性比較好

0:02:56.123,0:02:58.123
那這裡我有一個結論就是

0:02:58.123,0:03:00.123
任何刻意為之

0:03:00.123,0:03:02.123
而且卻是非強制的流程

0:03:02.123,0:03:04.123
都是成本很高

0:03:04.123,0:03:06.123
而且難以持續下去

0:03:06.123,0:03:08.123
那我們舉例來說

0:03:08.123,0:03:10.123
這是一個

0:03:10.123,0:03:12.123
很經典的開發流程

0:03:12.123,0:03:14.123
在座如果有開發經驗

0:03:14.123,0:03:16.123
應該都大概

0:03:16.123,0:03:18.123
或多或少經歷過這樣的流程

0:03:19.579,0:03:21.579
首先是要有規格

0:03:21.579,0:03:23.579
那接下來

0:03:23.579,0:03:25.579
有些比較在意的團隊

0:03:25.579,0:03:27.579
可能會有架構師來做架構設計

0:03:27.579,0:03:29.579
那接著就可以

0:03:29.579,0:03:31.579
開始寫程式

0:03:31.579,0:03:33.579
進行Code Review

0:03:33.579,0:03:35.579
然後部署上線

0:03:35.579,0:03:37.579
那另外也有測試的人可以在

0:03:37.579,0:03:39.579
有規格之後就開始寫測試計畫

0:03:39.579,0:03:41.579
執行測試

0:03:41.579,0:03:43.579
然後一樣部署上線

0:03:43.579,0:03:45.579
那大家覺得在這個流程

0:03:46.859,0:03:48.859
看似很美好,但是在

0:03:48.859,0:03:50.859
時間跟資源不足的時候

0:03:50.859,0:03:52.859
它會演變成什麼樣子

0:03:58.859,0:04:00.859
打叉叉的就是會被犧牲掉的東西

0:04:00.859,0:04:02.859
因為

0:04:04.859,0:04:06.859
這樣子也可以運作

0:04:06.859,0:04:08.859
有了需求,開始寫程式

0:04:08.859,0:04:10.859
然後部署就跟上線

0:04:10.859,0:04:12.859
就可以達到我們要的結果了

0:04:14.059,0:04:17.059
所以說這些附加的東西呢

0:04:17.059,0:04:20.059
就會被犧牲掉

0:04:20.059,0:04:22.059
那我們怎麼辦呢

0:04:22.059,0:04:24.059
其實我們有個技巧是

0:04:24.059,0:04:26.059
我們要把刻意的流程

0:04:26.059,0:04:28.059
盡量用某種方法

0:04:28.059,0:04:30.059
比如說自動化或強制性的方法

0:04:30.059,0:04:33.059
把它轉為必要的流程

0:04:33.059,0:04:35.059
比如說

0:04:35.059,0:04:37.059
為什麼

0:04:37.947,0:04:43.947
寫規格書 然後又要寫測試計畫

0:04:43.947,0:04:48.947
測試計畫不是只是把規格書又再擴張成

0:04:48.947,0:04:51.947
更多額外的輸入嗎

0:04:51.947,0:04:53.947
那為什麼不合併成說

0:04:53.947,0:04:57.947
我一開始其實就是寫測試規格書

0:04:57.947,0:05:00.947
那這樣子測試就變成一個必要的流程

0:05:00.947,0:05:02.947
本來是一個非必要的流程

0:05:02.947,0:05:04.947
被轉化為必要的流程

0:05:04.947,0:05:07.947
那這樣子它就有了某一種強制性

0:05:08.470,0:05:15.450
那接著是,寫程式完, Code Review大家都知道很重要

0:05:15.450,0:05:19.954
可是如果它不是強制, 就是沒有經過 Code Review

0:05:19.954,0:05:23.457
還是可以部署的話,那這一項就會被忽略掉

0:05:23.470,0:05:29.470
所以一般,如果要保有Review的話,就要讓它維持一種強制性

0:05:29.470,0:05:35.470
那測試,當然就只能靠自動測試

0:05:36.422,0:05:39.422
因為自動化而造成它不會被忽略

0:05:39.422,0:05:42.422
而且要PASS自動測試之後才能去部署

0:05:42.422,0:05:45.422
那這樣子就是因為融入了

0:05:45.422,0:05:48.422
把刻意流程轉為必要流程

0:05:48.422,0:05:50.422
所以讓這個流程可以

0:05:50.422,0:05:52.422
變成持續下去,而且

0:05:52.422,0:05:55.422
大家都會自然而然的去遵守它

0:05:57.968,0:05:59.968
那為什麼要講這個呢?

0:05:59.968,0:06:01.968
因為我們想要講說

0:06:01.968,0:06:04.968
韌性巡航或是韌性健檢

0:06:04.968,0:06:08.968
對機關來說到底是什麼樣嗎?

0:06:08.968,0:06:12.968
因為今天這個課的主題就是

0:06:12.968,0:06:14.968
各位領航員要

0:06:14.968,0:06:16.968
其實要一起去各個機關

0:06:16.968,0:06:18.968
走訪 去幫忙健檢

0:06:19.622,0:06:21.622
但是對機關來說呢

0:06:21.622,0:06:23.622
它是一個

0:06:23.622,0:06:25.622
首先先收到自評表

0:06:25.622,0:06:27.622
今年是2023年

0:06:27.622,0:06:29.622
收到自評表

0:06:29.622,0:06:31.622
然後接下來又

0:06:31.622,0:06:33.622
幾個月後就

0:06:33.622,0:06:35.622
有一群不認識的人

0:06:35.622,0:06:37.622
跑到他的辦公室去說

0:06:37.622,0:06:39.622
我要進行現場的輔導

0:06:39.622,0:06:41.622
那這個對機關來說

0:06:41.622,0:06:43.622
就是一個很明顯是一個

0:06:43.622,0:06:45.622
冒出來的刻意流程

0:06:46.134,0:06:49.134
那下一次機關又再遇到軔性巡航

0:06:49.134,0:06:51.134
可能是又再兩年後了

0:06:51.134,0:06:53.134
還是2025年

0:06:53.134,0:06:55.134
又發生了一次

0:06:55.134,0:06:58.134
又要填自評表又要現場補導

0:06:58.134,0:07:04.134
那我們到底對這個流程的期待是什麼呢

0:07:06.134,0:07:08.134
所以我們就在想說

0:07:08.134,0:07:10.134
有什麼辦法可以把

0:07:10.467,0:07:15.467
軔性巡航去融入機關的必要流程裡面

0:07:15.467,0:07:17.467
這裡做一個假設喔

0:07:17.467,0:07:20.467
這是我們輔導團的流程

0:07:20.467,0:07:22.467
最終希望產生的是

0:07:22.467,0:07:28.467
有個通用元件或指引可以長期的協助機關

0:07:28.467,0:07:30.467
但是機關的必要流程是

0:07:30.467,0:07:34.467
它會需要經過標案 經過計畫書

0:07:34.467,0:07:37.467
然後有預算 然後寫RFP

0:07:37.467,0:07:41.467
接著要有廠商評選的流程

0:07:41.467,0:07:45.467
那最後才是開發驗收上線等等

0:07:45.650,0:07:50.650
那這裡究竟如何做是一個開發的問題

0:07:50.650,0:07:52.650
我們先打個問號

0:07:52.650,0:07:57.650
不過我是認為說我們如果能做到這個概念的話

0:07:57.650,0:08:04.650
才是可以真正讓軔性巡航的價值提升是持續而且主動的

0:08:10.940,0:08:12.940
OK

0:08:12.940,0:08:14.940
那我們

0:08:18.940,0:08:20.940
剩下五分鐘

0:08:20.940,0:08:22.940
有什麼FAQ

0:08:22.940,0:08:24.940
或是有什麼Q&A

0:08:24.940,0:08:26.940
大家來討論一下

0:08:26.940,0:08:28.940
不是還有

0:08:28.940,0:08:30.940
但是

0:08:30.940,0:08:32.940
因為

0:08:32.940,0:08:34.940
我怕等一下會有回憶