2. Introduction to LeSS
• こちらのまとめ・一部訳・物語の台本
• https://less.works/less/framework/introductio
n.html
3. Introduction to LeSS
• Large-Scale Scrum: More with LeSSの第2章
2人のエコノミストが道を歩いていた。
1人が道ばたに紙が落ちているのを見つけた。
「あれは100ドル紙幣じゃないか?」
「違うさ」もう1人が答えた。「100ドル紙幣だったら、
もう誰かが拾っているよ」
54. LeSS Huge:
Requirement Areas
• だがLeSS Hugeフレームワークでは、8チームより大きい場
合、職能やアーキテクチャでは分割しない。分割は顧客の関
心事の主要なエリアでおこなう。これを要求エリアと呼ぶ。
LeSSの原則である顧客中心を反映した分割だ。
55. LeSS Huge:
Requirement Areas
• たとえば、証券取引のプロダクトを考えよう(証券のトレードや
管理をする)。顧客の要求の主要なエリア――要求エリア
――は、以下のようになる。
• トレードの処理(取引の開始から完了まで)
• 資産のサービス(株式分割、配当など)
• 新興市場への対応(ブラジルなど)
56. LeSS Huge:
Requirement Areas
• 概念的には、単一のプロダクトバックログに「要求エリア」属性を追加し、
アイテムにそれぞれ要求エリアを必ず1つだけ持たせる。
• そうして、エリアプロダクトバックログに集中できるようになる。概念的
には、単一のプロダクトバックログを参照するビューと考えられる。新市
場対応のエリアプロダクトバックログは次のようになる。
順序 アイテム 要求エリア ……
1 B 新市場対応
2 C トレード処理
3 D 資産サービス
4 F 新市場対応
順序 アイテム 要求エリア ……
1 B 新市場対応
4 F 新市場対応
57. Area Product Owner and
Teams
• LeSS Hugeでは新しいロールが1つ増える。要求エリアにはそれぞれ1人
エリアプロダクトオーナーがつき、そのエリアの専門家として、エリアプ
ロダクトバックログを管理する。また複数の――けっして1つではない
――フィーチャーチームがエリアプロダクトオーナー1人につき、そのエリ
アの専門チームとなる。
• したがって、たとえば証券プロダクトには、以下が存在することになる。
• 全体のプロダクトオーナーが1人、エリアプロダクトオーナーが2人、3人をサポートす
るプロダクトマネージャーたち
• (一番大きな)*証券トレード*要求エリアには6つのチーム
• あとの2つの要求エリアには、4チームずつ
• 要求エリアを担当するチームは固定だろうか?そうではない。時間ととも
にゆっくり、エリアの重要性が変化するのに合わせて、チームも増えたり
減ったりする――他のエリアと行き来するのが一般的だ。
58. LeSS Huge
Framework Elements
• 簡単に言ってしまうと、要求エリアそれぞれは(小さい方
の)LeSSを導入して、全体で統一したスプリントで並行して動
く。巨大な組織への導入時期のいろいろなやり方について、
顧客価値による導入と組織の章で議論する。
• 役割 ―― LeSSと同じだが、以下が変更点だ。2人以上のエ
リアプロダクトオーナーと、要求エリアごとに「4~8」チーム。
1人のプロダクトオーナー(プロダクト全体の最適化にフォー
カスする)、複数のエリアプロダクトオーナーが、プロダクト
オーナーチームを構成する。非常に大きなプロダクトグルー
プでは、サポート役のプロダクトマネージャもいることが多い。
67. Creating a New Requirement
Area
• 翌日、プロダクトオーナーチームが集まった
• ピーター「監査官が満足するだけのものを今年度中に出せ
なかったら、取引停止だ」
• 新しいエリアを作ることになり、アリエルがエリアプロダクト
オーナーを務める
• 現在ロブのエリアバックログにあるアイテム(「Dodd-Frank
に着手」)をアリエルのエリアバックログに移して、分割する
• 次スプリントはゾンビチームが新エリアを担当する。数スプリ
ント以内に他のチームも参加する見込み
要約
68. Sprint Planning in the New
Requirement Area
• スプリントプランニングはエリアごとに分かれて並行して実
施
• アリエルのプランニングには、さらに2人監査に詳しい専門家
が参加(PBRやスプリント中の問い合わせにも対応する)
• アリエル「続く2スプリントでやりたいことが3つあります」
1. Dodd-Frankについて学び、分割する
2. ひとくち分の開発をして、システムへの影響を探る
3. 他のチームが参加できるよう準備する
• 後から3チーム、順次エリアに参加してくる見込みで、ゾンビ
チームは開発と同時に、後続チームをリードし、全体像を維
持する責任がある
• サイモン「アーキテクチャ・プロダクトマネジメントチームみたいだねw」
• トム「Dodd-Frankのビジョンを維持するけど、調整は各チームの責任だよ」
要約
69. The First Sprint in the New
Requirement Area
• 最初のスプリントでは、全体の時間の半分をリファインメント
にあてて、Dodd-Frankの理解に取り組んだ
• 半分の時間は開発に使い、小さなアイテムではあるものの
全体的な設計の議論に時間を費やしながら進めた
要約
70. Sprint Review in the New
Requirement Area
• 全エリアは同じスプリントで進み単一の出荷可能なプロダク
トインクリメントを作っているものの、スプリントレビューはエリ
アごとでおこなう
• ゾンビチームは1アイテム完成できた
• アリエル「予定では2アイテムだったけれど、でも1アイテム
完成できただけですごいわ」
要約
71. The Second Sprint
• 前よりも進めるようにはなったが、このスプリントでもやはり半
分くらいの時間はリファインメントにかけた
• このエリアに参加してくる予定のチームと、マルチチームの
PBRを実施したり、デザインワークショップを開催したりして、
Dodd-Frankの内容と設計について共有した
• Dodd-Frankの規模感とヤバさは、ゾンビチーム自身がいち
ばんよくわかっていた
要約
73. Adding a Third Team
• また数スプリント後の、プロダクトオーナーチームミーティン
グにて
• ピーター「アリエルには2チームしかいない。今年度の最重要
事項として、チームを増やしたいと思う。ラビ、君が4チーム必
要だというのもわかるが、全体の状況を考えて、君のところ
から1チームアリエルのところに回すのが最善だ。立候補す
るチームを募ってくれ」
要約