LeSS in Action: Developer Practices


Description :


為期 5 天的 LeSS in Action 培訓基於 Odd-e 十年以來引以為傲的 Certified Scrum Developer 培訓。培訓的關注點在於「工程技術實踐」與「企業組織管理」相結合,尤其是多團隊在同一個產品上透過 Scrum 的方式進行軟體開發(LeSS)的情境。畢竟在實務的應用中,二者相輔相成,缺一不可。
培訓的進行方式會是真實地運作一個完整的Sprint,我們將基於一個真實且有使用者使用的既有產品之上,由各組同時開發並交付使用者驗收導向的功能。學員有 50% 以上的時間是在專案中實作。同時,課程內容包含 Specification by Examples, TDD, Continuous Integration(CI) 與 Continuous Delivery(CD) 等技術實踐,以及 Scrum 團隊的合作方式,程式碼共有,Definition of Done 的意義及方法等組織技能。
長久以來,本課程在新加坡,日本,泰國,歐洲等地區引起許多正面的影響,幫助各地許多企業轉型建立良好的基礎建設與團隊技能,也為個人提供了更大的發展空間。我們理解 5 天針對於開發人員的培訓對於台灣企業與個人的挑戰,也請諒解我們為保證效果,為確保接近實務的 Sprint 運作,無法調整課程時長。與其投資於好高騖遠的高層管理理論,不如踏實地從軟體開發的獨特性開始反思。強烈建議企業客戶能找工作緊密相關的三人以上受訓,一來學習有伴效果好,二來減少學習認知盲點,三來得以保證實務上效果的延續。
課程用語為中文,將因應台灣企業與組織運作常見的問題著墨更深。實作上至少會用到 Java,JavaScript,以及大量其它相關的開發技術,包含單元測試、端到端測試、持續整合與自動部署等相關技術框架與方案。
講師陣容包含來自 Odd-e 新加坡的 Terry Yin (尹哲),以及台灣本地的David 共同進行講授。


Agenda :


  • Requirement workshop / A-TDD
  • Definition of Done
  • Cucumber and Friends
  • Sprint Plannings


  • Test-Driven Development
  • Collaboration (Working in teams, SCM, Build Automation and other tools, Pair Programming, Continuous Integration and CI Systems, Collective Code Ownership)


  • Code Smells & Refactoring
  • Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing


  • Thinking about Design
  • Feature Team Revisit


  • Working with Legacy Code 
  • Craftsmanship
  • Retrospective

Details :

Product Backlog Refinement Workshop

In Large-Scale Scrum, the PBR workshop is one of the most critical activities. By doing the workshop in the sprint with multiple teams, we will cover the three essential aspects of this workshop: splitting big items, detailing the items, and estimating. Some optional techniques we might cover based on the situation include: impact mapping, storying mapping, specification by example, estimation ceremonies, etc.


Definition of Done

What is the purpose of the Definition of Done? We will also talk about what it is about, how to use it, and who should ensure it. 


Sprint Plannings

(Cross-team) Sprint Planning Part One is mainly covered by the PBR workshop since there's only one sprint. Sprint Planning Part Two will be explained and practiced in detail.


Acceptance Test-Driven Development with Cucumber and Friends

This part explains how to drive the iteration with the examples derived from the PBR workshop. We will discuss the detailed technical approaches, good practices, and conventions.

The actual teaching or lecture is usually delayed to the next couple of days until the participants have real experience struggling with the tools and process. Most of the learning should be from the practices and on-time coaching from the course instructors. Same as all the other technical practices


Test-Driven Development

From day 2, all the code needs to be written by TDD. Same as described above, We will explain the philosophy very quickly with a simple exercise. Most of the learning should come from hands-on coaching and practicing.



This part explains the fundamental techniques and practices that enable teams to collaborate in a Large-Scale Scrum situation. Including:

  • Working in teams 
  • SCM, Build Automation, and other tools
  • Pair Programming
  • Continuous Integration and CI Systems
  • Collective Code Ownership

The above is getting the participant ready to understand why things are happening in the way they are in Large-Scale Scrum.


Code Refactoring

This part covers the why, what, and how of code refactoring. We'll train people to have the nose to smell bad code and the techniques to remove the bad smells.


More on Test Automation

With both the automated acceptance test and unit test covered in the course, in this part, we go deeper into (automated) testing. Including:

  • Real testing/exploratory testing
  • Product-wise testing strategies
  • Good automated testing
  • Unit testing other programming languages

Thinking about Design

Here we discuss the difference between emergent design and the traditional design style that often happens in a waterfall process.

On top of that, we also talk about the design principles and paradigms.

Thinking about "real testing", again

Feature Teams

With all gained knowledge from the first four days, we will finally explore this organizational structure topic again and see the links between the technical practices and team approaching and feature teams.


Legacy Code

Based on the book by Michael Feathers, Working Effectively With Legacy Code, we discuss the way of working when the code is without good test coverage, and the knowledge about how the code works is lost.



We will discuss the alternative metaphor for software practitioners to map their careers and guide them.



The training is over, the teams created in the course won't continue (usually). We will try to give people an experience of a good retrospective, learn to identify bad smells in a retrospective, and learn good techniques for running a retrospective. We will also cover how large organizations do retrospectives.


It's hard to document what we do in the course precisely. Because every time the teams will be working on different product backlog items and continue the product left by the previous class, many contents will be emergent.

Price: 3.500 SGD

Early Bird Price: 3.000 SGD (End Date: 2024-09-07)