對於一個跨職能的小團隊來說，人力是非常珍貴的資源。每個人都有自己的特長可以發揮，任何混亂的流程沒有被正規化、任何重複性且低價值的事情若沒有辦法被自動化，都會是一種浪費以及沈重的包袱。

一旦這些包袱越來越重，團隊能夠用在有價值項目的時間與精力就會越少，組織也會越難適應市場需求的變化，最後團隊與組織在疲於奔命下被市場淘汰。

越是基本的流程就應該標準化、正規化，越是重複的工作就越應該自動化。所以常有人在講沒有自動化測試、就沒辦法跑敏捷；DevOps 的許多基礎建設如 CI/CD，也是敏捷的基石。

今天就來簡單分享一下在前公司對於這方便的經歷吧！

版本控制

我通常會預設版本控制是一個軟體工程師必備的技能，尤其是現在主流的 Git，工程師們都應該能寫出有價訊息的 Commit、知道常見的的 Git Workflow 的知識，但可惜現實遇到的總是相反。

Git 是現代（幾乎）每個軟體工程師必定會接觸到的、每天都會用到的工具，但事實上許多工程師卻對這個工具仍不熟悉。通常用不好就會有複雜的 Conflict，然後光是解 Conflict 就會花掉龐大的時間，甚至損害程式碼的正確性。

在前公司前期最常看到的就是生命週期過長的分支，都是存在會超過一個月，甚至到達三個月以上的分支，這些分支活越久，就越難併回主線。如果無法併回主線，就無法釋出，也幾乎就是沒價值，也就是幾乎三個月都沒有產值。

有些比較奇特的，就會乾脆就越行越遠，自己就變成主線了，甚至成為一個新的 Repository 活著。但是與原本的專案仍有許多 Code Base 是相同的，一但這裡有地方要修，就得兩個地方都修。

這些事情都一再的耗損我們的時間，但是明明卻可以透過好的習慣與流程去預防的。所以我們之後也透過共享知識、 Retro 與日常討論不斷改進我們的流程。每一個變化是一個 Action 逐次改善，最後我們花費在這裡的時間也就逐漸減少了。

重複性的工作

我們曾遇到要處理一些技術上的事情，是常常不定時要去做的重複性事項。做這件事情一次處理一個單位與處理十個單位的成本是相近的，所以一但這件事發生越頻繁，我們就會越少人力在開發上。

所以後來同事就把這件事情寫成自動化腳本，儘管如此還是處於半自動化程度，需要有人執行腳本並查看結果是否成功，但已經是很大的改善了。接著我們就把這件事在訂成週期性發生，而不是需求驅動，規定不管何時提的需求，我們不再即時處理或當天處理，而是累積到一週的某一天再一起執行，從此這件事也就不再困擾我們，而只是每週的一個小插曲而已。