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