在一週得到一年工作經驗
12公開內容
2022 年四月，我參加了 LeSS in Action 的課程，在這個課程中我們要用一週的時間學習加入一間敏捷開發的公司並且實際產出程式碼，體感上就像是你工作了一年一樣，讓我們來看看這一週的時間發生了哪些事情吧？
全部內容
免費與付費
最新發佈優先
因為經常有面試人的機會，然而在不同的面試條件中有一個「Problem Solving」的項目讓我一直在思考代表怎樣的意義，剛好在 LeSS in Action 的課程中有了一些想法。
這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來，然而還是有許多內容很難用文章簡單的說明。
雖然這系列的課程是設計給工程師的，然而在學習敏捷開發（Scrum 為主）的過程中，我們是從如何做「產品」的角度去做切入，也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異，也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。
當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。
不同於我們大多數討論持續整合（Continuous Integration）是以工具為主的議題，在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代，也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。
完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
當我們的衝刺（Sprint）完畢之後，還需要對這一次的衝刺進行評論（Review）以及回顧（Retrospective）來對工作的狀況進行改善。
當我們對敏捷團隊有一些概念後，我們還需要了解在敏捷開發中重要的幾個事件，以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。
