LeSS (Large Scale Scrum) 入門
はじめに
Scrum は 3 から 9 人で美しく回ると言われていますが、現実にはより多い人数のチームに所属することはザラにあります。同様に適切な人数で始めたはずの開発も発展につれ人数が増大することも度々起こります。
人数が多くて動きが鈍くなったチームは分割したくなりますが、チームはどのように分割するのが良いのでしょう？ また、分割後はどのように Scrum を回せば良いのでしょう？
複数チームによる規模の大きい開発に対応する Agile の手法としては LeSS・SAFe・Disciplined Agile などが有名です。
今回は個人的に最も導入コストが低いと感じる LeSS に着目し、その概要を把握できるようフレームワークを中心にご紹介したいと思います。
LeSS とは
LeSS は Scrum の原理・原則、目的、要素、などを複数チームでの開発に取り入れた手法です。
上位概念を付け加えることで大規模開発に対応しており、開発チームの視点からは Scrum とほぼ差異が無いという特徴があります。
LeSS は 2 から 8 チームでの開発用の (Smaller) LeSS と、 約 8 チーム以上での開発用の LeSS Huge という 2 つのフレームワークがあります。
(Smaller) LeSS
2 から 8 チームでの開発用のフレームワーク。
Role
Product Owner
ひとり。Product Backlog Item の順序を管理する。Team
Scrum で言うところの開発チーム。最大 8 チーム。ひとつのチームは 3 から 9 人で構成される。Scrum Master
チーム数に応じて最大 8 人。Scrum Master はそれぞれ 1 から 3 チームを担当する。
Sprint のすすめ方
ひとつのプロダクトの開発を複数チームで進める。
Sprint は全チーム共通であり、Sprint 終了時にはリリース判断可能なインクリメントが得られる。
Artifacts
Scrum とほぼ同じ。
- Product Backlog
- （チームごとの）Sprint Backlog
- Product Increment
Events
基本的には Scrum と同じだが、Sprint Planning 1 や Overall Backlog Refinement、Overall Retrospective などの全チームで開催するイベントが追加されている。
Product Owner はチームごとのイベントには参加しない。
なお、Scrum Master のイベント参加要否については明言されていない。
Sprint Planning 1
Ready になっている PBI からどのチームがどの PBI に Sprint で取り組むか決定する。
Sprint Goal を定義する。
- 参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者
Sprint Planning 2
チームごとに、Scrum と同様に、Sprint Planning 1 で決めた PBI を Sprint で Done にするための計画を立てる。
チームごとの Sprint Backlog が作成される。
- 参加者
- (Scrum Master)
- チームの全メンバー
Daily Scrum
チームごとに Scrum と同様の 3 つの質問などでチームの進捗を検査する。
- 参加者
- (Scrum Master)
- チームの全メンバー
Overall Product Backlog Refinement
Product Backlog 全体の精査を行う。
Team Product Backlog Refinement の前に実施する。
精査内容
- 各 PBI の理解を深める
- 大きな PBI の分割
- 各 PBI を着手可能にする
- （大雑把な）見積もり
- 関係性の深い PBI をグルーピングする
- どのチームがどの PBI に取組むのが良さそうか判断する
参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者
- 対象となる PBI の分野の専門家
Team Product Backlog Refinement
チームごとにチームが取り組む PBI の精査を行う。
精査内容
- 各 PBI の理解を深める
- 大きな PBI の分割
- 各 PBI を着手可能にする
- 見積もり
参加者
- (Scrum Master)
- チームの全メンバー
Sprint Review
スプリントのインクリメントをベースにプロダクトに関わる全員でプロダクトについて考える。
Sprint のインクリメントに対し承認をもらう場では無い。
- 参加者
- Product Owner
- (Scrum Master)
- 全 チームの全メンバーまたは代表者
Team Retrospective
チームごとにチームの検査と次のスプリントの改善計画を考える。
- 参加者
- (Scrum Master)
- チームの全メンバー
Overall Retrospective
全員で組織システムやチーム間の連携などについて考える。
Team Retrospective のあとに実施する。
- 参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者
LeSS Huge
8 より大きなチームでの開発用のフレームワーク。
Requirement Area で開発対象を分割する。
ひとつの Requirement Area に着目するとチーム目線では (Smaller) LeSS と LeSS Huge には違いが無い。
Requirement Area
プロダクトにおける顧客の懸念事項の主要な領域を分割したもの。
Requirement Area ごとにひとり Area Product Owner を立てる。
ひとつの Requirement Area には 4 から 8 チームが含まれる。
Product Owner は全ての Product Backlog Item に "Requirement Area" の Attribute をつける。
Product Backlog Item を Requirement Area でグルーピングしたものを Area Product Backlog と呼び、各 Requirement Area にとっての Product Backlog となる。
Role
(Smaller) LeSS / Scrum と同じものに Area Product Owner が追加される。
Area Product Owner は Requirement Area において (Smaller) LeSS の Product Owner として振る舞う。
- Product Owner
ひとり。Product Backlog Item の順序を管理する。 - Area Product Owner
Requirement Area ごとにひとり。Area Product Backlog Item の順序を管理する。 - Team
チームはひとつの Requirement Area にのみ属する。
ひとつの Requirement Area には 4 から 8 チームが含まれる。 - Scrum Master
チーム数に応じて Requirement Area ごとに最大 8 人。Scrum Master はそれぞれ 1 から 3 チームを担当する。
Sprint のすすめ方
Area Product Backlog とそれを作る工程以外は (Smaller) LeSS と同じ。 なお、Area Product Backlog を作る工程はイベントとしては明確に定義されていない。
Artifacts
(Smaller) LeSS と同じものに Area Product Backlog が追加される。
- Product Backlog
- Area Product Backlog
- （チームごとの）Sprint Backlog
- Product Increment
Events
Area Product Backlog を作る工程以外は (Smaller) LeSS と同じ。 (Smaller) LeSS の Event の Product Owner を Area Product Owner と読み替えると成立する。
おわりに
LeSS は「Scrum の原理・原則、目的、要素、などを複数チームでの開発に取り入れる」を主観にデザインされているため、非常にシンプルで理解しやすい構造をしています。特に Scrum を既に導入しているチームであれば採用は容易なのではないでしょうか。
今回は LeSS の特徴を紹介したくフレームワークにフォーカスしましたが、公式サイトにはチーム間の連携手法や複数チームでのスクラムイベントなど、多くのエッセンスが記載されています。ぜひチェックしてみてください。
マサカリも絶賛お待ちしております。😊
