《LeSS in Action》是一個關於 Scrum 的工作坊，我們將在一週的時間內模擬加入一間公司，並且在一週後馬上離職。因此這是一間工程師 100% 離職率的公司，在這一週的時間內我們需要學習針對一個真實的產品進行開發，跨團隊的協作來產生貢獻。


LeSS in Action - 入職

軟體開發

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

當我們對敏捷團隊有一些概念後，我們還需要了解在敏捷開發中重要的幾個事件，以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。

完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。

在一間採用 Scrum 的公司中工作，勢必要了解敏捷開發是一個怎樣的概念。也因此，我們在分配完畢團隊後，先以團隊為單位安排出我們所理解的「敏捷流程」並且相互對照討論。

當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。


這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來，然而還是有許多內容很難用文章簡單的說明。


當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。


我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。


當我們的衝刺（Sprint）完畢之後，還需要對這一次的衝刺進行評論（Review）以及回顧（Retrospective）來對工作的狀況進行改善。

雖然這系列的課程是設計給工程師的，然而在學習敏捷開發（Scrum 為主）的過程中，我們是從如何做「產品」的角度去做切入，也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異，也是這一週課程中各種安排的理由所在。

不同於我們大多數討論持續整合（Continuous Integration）是以工具為主的議題，在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代，也因此必須持續的將團隊的產出整合在一起。


軟體工程師逐漸變成一個熱門的職業，當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢？這系列的專欄會分享日常工作中的經驗以及一些案例分析，讓我們一起努力成為一位更優秀的軟體工程師吧！