LeSS in Action: Developer Practices
This event has been cancelled.
Osaka
〒550-0003
Japan
Description :
Organizational Agility is constrained by Technical Agility.
|
The 5-day development practice course is 70% hands-on and 30% lecture and has three main focuses: Large-Scale Scrum, technical practices, and authentic team dynamics. It covers Scrum practices such as cross-team Sprint Planning, Backlog Refinement, working as a team, and many technical practices such as Test-Driven Development, Continuous Integration, Acceptance Test-Driven Development, and Refactoring. It also covers how to apply these practices in a legacy codebase situation. |
■ 概要
5日間の開発実践トレーニングでは、実際にユーザーに利用されている既存製品の上で、ユーザーに受け入れられる機能をチームで同時に開発し、提供するSprintを実施します。 参加者は50％以上の時間をプロジェクトに費やすことになります。 また、Specification by Examples、TDD、Continuous Integration（CI）、Continuous Delivery（CD）などの技術的プラクティスや、スクラムチームへの協力的アプローチ、コード共有、Definition of Doneなどの組織的なスキルについても学習します。
参加者は「CSD（Certified Scrum Developer℠）および、A-CSD（Advanced Certified Scrum Developer℠）」・「Certified LeSS Basics」の資格を取得することができます。
※ 本コースでは、事前に資格を保持している必要はありません。
本コースはオンサイトにて行います。
また認定スクラムトレーナー（CST®）である 江端一将（ebacky） も共同トレーナーであり、同時通訳も行います。
Agenda :
- Certified ScrumDeveloper® および Advanced Certified Scrum Developer℠ は、Scrum Alliance® が発行するライセンスです。
- Certified LeSS Basics は、The LeSS Company B.V. が発行するライセンスです。
- 1企業様のお申し込み人数上限は7名様までとさせていただいております。上限を超えてお申込があった場合は日程変更をお願いする場合がございます。ご了承ください。
- 本トレーニングは、株式会社Gains Lineが販売及びお問い合わせの窓口となります。
- 全時間受講が義務づけられております。遅刻や早退、途中退室は無条件で認定できません。
- パソコンや携帯電話の使用等、ルール違反も認定できませんのでご注意ください。
- 研修開始日前日を起算日として14日前の日以降の日程振替は行なっておりません（キャンセル扱いとなります）。ただし受講者の入れ替えの場合は、キャンセル料はなく前日までご変更いただけます。マイコースからご編集ください。
- 対面でのトレーニングとなりますので、コロナ等の影響により、中止や延期の可能性がございます。
- コロナ等によるリスク回避の為に参加者の方々に個別に書面による同意書等にご署名を頂く場合がございます。
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.
Collaboration
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.
Craftsmanship
We will discuss the alternative metaphor for software practitioners to map their careers and guide them.
Retrospectives
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: 550,000 JPY