LeSS in Action - 延伸思考:工程師的心態
方格精選

LeSS in Action - 延伸思考:工程師的心態

更新於 發佈於 閱讀時間約 4 分鐘

因為經常有面試人的機會,然而在不同的面試條件中有一個「Problem Solving」的項目讓我一直在思考代表怎樣的意義,剛好在 LeSS in Action 的課程中有了一些想法。

能夠解決問題的人

在台灣,我們很學習大多是透過「如何(How)」的方式來解決問題。然而這個「如何」是依靠標準答案所構成的,也因此我們如果沒有先學會工具、標準流程就沒辦法處理問題。

然而,在 LeSS in Action 課程中裡面建議大家比起思考「如何」更應該思考更多「為什麼(What)」去思考問題是為何存在、背後所象徵的意義為何。

在中文裡面 What 跟 Why 幾乎都可以用「為什麼」而來講,然而 What 跟 Why 相比來說具有更多討論「定義」的意義,而 Why 則是希望「解釋」的意義。

比技術更好用的能力

當我們了解到「如何」跟「為什麼」的差異後,就會發現技術實力本身並非影響專業、職涯的關鍵條件,即使我們了解再多技術、能夠用多優秀的技巧撰寫程式很可能都無法提升。

我最早知道的資深工程師定義,是一位前輩告訴我的,也就是「知道自己該做什麼」的人。剛好對照到「為什麼」的思考方式,雖然有點抽象但是也明確的說明了技術條件並不是影響是否成為資深工程師的關鍵。

這也驗證了在我過往的經驗中,經常會發現有些人會用「我能夠用某某工具解決問題」的問題來描述自己的能力,然而並未能深入分析、定義問題,這樣的方式得到的將果也不過是隨著時間增加會使用的工具。

學習探索的技能

要處理未知的問題,其中一個非常重要的環節就是定義「範圍」也就是透過不斷地提出「為什麼」來畫出一個已知跟未知的邊界,最後根據自己所具備的知識來尋找能夠從已知連結到未知的路徑來解決問題。

當我們利用「探索」的方式不斷地嘗試前進,我們可以應用小步前進的技巧來對應無法知曉全貌的「恐懼感」因為當我們出錯的時候,隨時都可以後退一步,也能夠避免在思考全貌時不斷遭遇的「未知」影響我們的思考,最後迷失了方向。

在敏捷開發中會推薦採用驗收測試驅動開發(Acceptance Test Driven Development)就是為了要實踐「探索」的過程,讓我們隨時都學習如何「專注當下」好好的把眼前的問題解決,只要持續這樣的前進,總有一天就會把所有問題解決。而不是專注在「如何一次性解決問題」這樣不太現實的方法上。

文化、時間、環境的挑戰

敏捷開發是源於歐美的方法,當然也受到歐美文化的影響,要在習慣亞洲文化的我們去接受這樣的轉變會需要不少的時間適應。

在刻意練習中提到要使用正確的方法練習才會有效,然而工程師是一個相對新的領域,也因此還未有完善的訓練方式(也是我們的「為什麼」還問得不夠多)因此想要有有系統的訓練就已經相當困難。

同時,環境的存在依舊影響著大部分的人。即使你的內心已經產生變化、也找到自己的方法正確的運用時間訓練自己,仍然要面對的是找不到一個可以接受這樣工作型態的公司。

即使遭遇了重重困難,依舊還能夠堅持的用這樣的方式前進。我想,你會開始看到一個不一樣的「專業」的世界。


封面圖片使用 UnsplashNorbert Kundrak 的作品,這系列的文章只是課程的一小部分,因此並無法完整涵蓋所有概念以及精神,看關於技術的主題可以到弦而時習之找找靈感。

avatar-img
蒼時弦也的沙龍
55會員
40內容數
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
留言
avatar-img
留言分享你的想法!
蒼時弦也的沙龍 的其他內容
這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來,然而還是有許多內容很難用文章簡單的說明。
雖然這系列的課程是設計給工程師的,然而在學習敏捷開發(Scrum 為主)的過程中,我們是從如何做「產品」的角度去做切入,也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異,也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念,要減少技術債的方式就是重構,然而在實踐重構的時候並非我們所想像的必須「安排時間」重構,而是在開發的過程中不斷的進行。
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。
這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來,然而還是有許多內容很難用文章簡單的說明。
雖然這系列的課程是設計給工程師的,然而在學習敏捷開發(Scrum 為主)的過程中,我們是從如何做「產品」的角度去做切入,也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異,也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念,要減少技術債的方式就是重構,然而在實踐重構的時候並非我們所想像的必須「安排時間」重構,而是在開發的過程中不斷的進行。
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。