Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
©2016 Kenji Morita
Nexus と LeSS の
概要説明、比較
キヤノン株式会社 守⽥ 憲司
株式会社ガイアックス ⽊村 卓央
©2016 Kenji Morita
守田 憲司
Kenji Morita
キヤノン株式会社
デジタルシステム開発本部
主幹研究員
@wsfjp
Nexus Guide 共訳
©2016 Kenji Morita
本日のテーマ
開発チームが10人
超えたらどうする?
©2016 Kenji Morita
3人
3
©2016 Kenji Morita
6人
15
©2016 Kenji Morita
9人
36
©2016 Kenji Morita
12人
66
メンバーか9人を超えた場合は、調整の機会
が多くなってしまう。また、チームの規模が
大きいと、経験的プロセスの管理が複雑に
なってしまう。 (スクラムガイド)
©2016 Kenji Morita
大人数で
開発するには
分割が必要
©2016 Kenji Morita
出典:9TH ANNUAL State of Agile™ Survey (Version one)
使われているスケール手法の割合
Scrum / Scrum of Scrum 69%
独自手法 25%
...
©2016 Kenji Morita
SAFe (19%)
http://www.ogis-ri.co.jp/solution/1210904_6793.html
©2016 Kenji Morita
出典:9TH ANNUAL State of Agile™ Survey (Version one)
使われているスケール手法の割合
Scrum / Scrum of Scrum 69%
独自手法 25%
...
©2016 Kenji Morita
「スクラムガイド」より
「複数のスクラムチームが同じプロ
ダクトの作業をすることがよくある。
そうした場合、プロダクトの作業は1
つのプロダクトバックログに記述す
る。また、アイテムをグループにま
とめる属...
©2016 Kenji Morita
「スクラムガイド」より
「複数のスクラムチームが同じプロ
ダクトの作業をすることがよくある。
そうした場合、プロダクトの作業は1
つのプロダクトバックログに記述す
る。また、アイテムをグループにま
とめる属...
©2016 Kenji Morita
コンウェイの法則
アーキテクチャは組織にしたがう
組織はアーキテクチャにしたがう
©2016 Kenji Morita
チーム分けで考慮すべきこと
組織
プロセス
アーキ
テクチャ
©2016 Kenji Morita
チーム分けで考慮すべきこと
組織
プロセス
アーキ
テクチャ
©2016 Kenji Morita
スケール階層と手法自体の大きさ
2階層 3階層
SAFe
LeSS
(2∼8チーム)
LeSS Huge
(9∼チーム)
Nexus
(約3∼9チーム)
Nexus+
(約10∼チーム)小さい
大きい
手法...
©2016 Kenji Morita
Nexusの概要
©2016 Kenji Morita
Nexus ガイド
•無料公開されています。
•短いです。(10ページ)
英語版 2015年8月公開
日本語版 2015年12月公開
開発:Ken Schwaber and Scrum.org
翻訳:角 征...
©2016 Kenji Morita
Nexus
The exoskeleton(外⾻格) of scaled Scrum
©2016 Kenji Morita
スコープ
l約3〜9スクラムチーム
l1つのプロダクトバックログ
「チームが3つ以上になると、さらに事
態は複雑になる」
©2016 Kenji Morita
スクラムチーム
lチーム間の依存関係が少なくなるように
分割する
l関連する以下の要素をチーム内にそろえ
る
• 要求
• ドメイン知識
• ソフトウェアやテストの作成物
©2016 Kenji Morita
ソフトウェアプラクティス
l多くのソフトウェアプラクティスが必要
である。
l大規模な環境では特に自動化が必要であ
る。
©2016 Kenji Morita
Nexusの説明
©2016 Kenji Morita
NEXUSの役割
©2016 Kenji Morita
Nexusの役割
Nexus統合チーム
約3〜9のスクラムチーム
プロダクトオーナー(全体で1人)
スクラムマスター(兼任可)
チームメンバー(兼任可)
適切な代表者
(特に定義されてないが)
スクラムマス...
©2016 Kenji Morita
Nexus統合チーム
lすべての作業の統合を成功させる最終的
な責任がある。
lチーム間の技術的・非技術的な制約を解
消する。
l依存関係やチーム間の問題に対する認識
を高める。
lコーチング、コンサルティ...
©2016 Kenji Morita
Nexus統合チームの
プロダクトオーナー
lNexus全体で1人のプロダクトオー
ナー
l統合インクリメントの価値を最大化する。
lプロダクトバックログの順番とリファイ
ンメントに最終的な責任を持つ。
©2016 Kenji Morita
Nexus統合チームの
スクラムマスター
lNexusが理解され、実施されることに
責任を持つ。
©2016 Kenji Morita
Nexus統合チームメンバー
l(3ではなく)1人以上
lスクラムチームが獲得、実施、学習でき
るようにコーチングや指導をする。
• プラクティス、ツール、開発、インフラ、
アーキテクチャ標準
©2016 Kenji Morita
Nexusの役割
Nexus統合チーム
約3〜9のスクラムチーム
プロダクトオーナー(全体で1人)
スクラムマスター(兼任可)
チームメンバー(兼任可)
適切な代表者
(特に定義されてないが)
スクラムマス...
©2016 Kenji Morita
NEXUSのイベント
©2016 Kenji Morita
イベント
lNexusスプリントプランニング
lNexusデイリースクラム
lNexusスプリントレビュー
lNexusスプリントレトロスペクティブ
lリファインメント
©2016 Kenji Morita
Nexusスプリントプランニング
l代表者
l各チームで
©2016 Kenji Morita
Nexusスプリントプランニング1
l各スクラムチームの代表者が
作業の順番を確認・調整する。
lNexusスプリントゴールを作
成する。
l成果物
• Nexusゴール
©2016 Kenji Morita
Nexusスプリントプランニング2
l各スクラムチームでスプリン
トプランニングを実施する。
• 他のチームと情報交換する。
• 同じ場所で実施すると新しく発
見した依存関係が共有できる。
l成果物(チーム...
©2016 Kenji Morita
Nexusデイリースクラム
lチームの代表者(毎日)。
l各スクラムチーム
©2016 Kenji Morita
Nexusデイリースクラム1
l3つの質問
ü 昨日の作業はうまく統合された
か?うまく統合されていなけれ
ば、それはなぜか?
ü 新たに特定された依存関係は何
か?
ü Nexusのチーム間で共有が必要
...
©2016 Kenji Morita
Nexusデイリースクラム2
lNexusデイリースクラムで特定
された統合の問題を解決できる
ように、その日の計画を立てる。
©2016 Kenji Morita
Nexusスプリントレビュー
lすべてのチームがプロダク
トオーナーのもとに集まり、
統合されたインクリメント
をレビューする。
l全ての機能をレビューでき
ないかもしれない。
Ø上手くやってね♪
©2016 Kenji Morita
Nexusスプリントレトロスペクティブ
l代表者
• 共通課題の特定
l各スクラムチーム
• 個別に実施
l代表者
• 必要なアクションの見える化、
追跡について合意する。
©2016 Kenji Morita
Nexusスプリントレトロスペクティブ
l全てのレトロスペクティブで扱うべき議
題
• 完成していないものはあるか?Nexusは技
術負債を作り出していないか?
• 作成物(特にコード)は、 (できれば毎
...
©2016 Kenji Morita
リファインメント
1. 十分に詳細になるまで分解する。
• 担当するチームを予測するために必要にな
る。
2. 依存関係を特定して見える化する。
• 作業順番や割り当てを見直し、チーム間の
依存関係を最小化...
©2016 Kenji Morita
NEXUSの作成物
©2016 Kenji Morita
プロダクトバックログ
l全体で1つのプロダクトバックログ
lPBIがNexusスプリントプランニングに
向けて(Ready)準備完了とは?
• スクラムチームによって選択可能
• 依存関係は排除または最小化...
©2016 Kenji Morita
Nexusスプリントバックログ
lNexus統合チームのスプリントバック
ログ
• 「スクラムチームのスプリントバックログ
にある全てのプロダクトバックログアイテ
ムをまとめたものである。」
lスプリントに...
©2016 Kenji Morita
プロダクトバックログ
バックログとスプリントゴール
Nexus
スプリントバックログ
Nexus
スプリントゴール スプリントゴール
スプリントゴール
スプリントゴール
スプリントゴール
スプリントゴール
...
©2016 Kenji Morita
統合インクリメント
l完了した「統合された作業」すべての総
和である。
l利用可能でリリース判断可能なものでな
ければいけない。
l「完成」の定義を満たしていなければい
けない。
lNexusスプリントレビ...
©2016 Kenji Morita
作成物の透明性
l技術的負債が許容不可能になる前に、依
存関係を検出および解消しなければいけ
ない。
l許容不可能な技術的負債かどうかは、結
合する時にはじめてわかる。
©2016 Kenji Morita
「完成」の定義
lNexus統合チームは「完成」の定義に
実行責任を持つ。
lチーム独自の「完成」の定義は、インク
リメントの完成の定義より緩い基準を適
用してはいけない。
©2016 Kenji Morita
Nexusについて質問等
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS(Large-Scale Scrum)
http://less.works/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
Certified Scrum Professional®/Scrum Developer®/ScrumMaster®/Scrum Product Owner®
...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
http://www.gaiax.co.jp/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS Study
https://www.facebook.com/groups/less.study/
https://less-study.doorkee...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
絶賛翻訳中・・・
PBI = 75
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
おことわり
ただいま、翻訳中かつ、less.workの内容も変わるこ
とがあります。
今回使⽤した⽤語について、今後変わることもあり
ます
まだまだ理解が⾜りてい...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS アジェンダ
nLeSSの構成と特徴
nLeSSのフレームワーク
l役割
lイベント
l作成物
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成
http://less.works/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成
nLeSSは、複数チームのコンテキストにスクラムを
適⽤するためのガイドとルールのセットからなる
lLeSS Framework
lLeSS Ru...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成
nガイドとルール
lLeSS Framework
lLeSS Huge
lLeSS Rules
n実験(秘訣)
l原則(Principles)
l...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター
&フィーチャーチーム
スプリントレビュー
レトロスペクティブ
全体的な
レトロスペクティブ
デイリースクラム
プロダクト
バックログ
リファイン...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントレビュー
レトロスペクティブ
全体的な
レトロスペクティブ
デイリースクラム
プロダクト
バックログ
リファインメント
スプリント
バックログ
スプリン...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS Huge
n8チーム以上に適したLeSSの
第2のフレームワーク
n概念的には、LeSSフレームワークの上に
複数のLeSSフレームワークを積み重ねて
...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS Rules
nLeSS Frameworkの定義が書かれている
n最新版は 2016年1⽉版
nLeSS Framework Rules
lLeSS S...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
Large-scale Scrum
はスクラム
透明性
より少ない労⼒で
⼤きな成果を
プロダクト全体に
フォーカス
顧客中⼼
完成に向けた
継続的改善
リーン思...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター
フィーチャーチーム
組織構造
チーム
顧客価値による
組織化
コミュニティ
構造
構造
http://less.works/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS での組織構造
プロダクト
グループ⻑
フィーチャー
チーム #1
フィーチャー
チーム #2
フィーチャー
チーム #n
未完了に
対応する
部⾨
プロ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
マネージャーの役割
現場主義
問題解決の⽅法を教える
⾃⼰組織化
改善サービス
スクラムマスターとしての
マネージャー
マネージメント
マネジメント
http:/...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
技術的優位性
技術的優位性
http://less.works/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
3つの原則
継続的改善
フィーチャーチーム
採⽤マップ
開始
コーチング
採⽤
採⽤
http://less.works/
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
基本は1チームのスクラムと同じ
スクラムのプラクティスとアイデアを保持
n1つのプロダクトバックログ
n1つの完成の定義
n各スプリントの終わりに出荷可能な成果物...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
協調と統合(Coordination & Integration)
nとりあえず話す
nコードで会話する
nデイリースクラムにオブザーバーを送り込む
nコミュニテ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター
&フィーチャーチーム
スプリントレビュー
レトロスペクティブ
全体的な
レトロスペクティブ
デイリースクラム
プロダクト
バックログ
リファイン...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS での役割
nプロダクトオーナー
l全体で1⼈のプロダクトオーナー
nスクラムマスター
nチーム
基本的には1チームのスクラムと同じ
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
プロダクトオーナー
nプロダクトバックログの管理者
n開発チームの成果を検証する
nプロダクトバックログの優先順位付け
lビジネス上に関する情報を収集し分析する
...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
明確化よりも優先順位付け
n優先順位付けは、ひとりのプロダクトオーナー
n明確化は、チームで協業する
lユーザー/顧客とチームとの直接会話することを
奨励する
l...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター
nチームにプロダクト全体を意識するよう働きかける
l⼤きなプロダクトグループの⼈々の相互作⽤、遅
延、原因、ポテンシャル(潜在リスク)などの
各...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
チーム
n⾃⼰組織化
nクロスファンクショナル(機能横断的)
n全てのチームの作業に共同で責任を負う
nチームのゴールを持つ
nコンポーネントチームではなく
フィ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
プロダクト
バックログ
顧客中⼼
フィーチャー
フィーチャーチーム:
- 安定かつ⻑寿命
- クロスファンクショナル
(機能横断的)
- コンポーネント横断
出荷...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS でのイベント
nスプリントプランニング(1部、2部)
nデイリースクラム
nスプリントレビュー
nスプリントレトロスペクティブ
n全体的なスプリントレト...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
初期の
プロダクトバックログリファインメント
nプロジェクト最初に⾏う
n基本的にはプロダクトバックログリファインメント
と同じ
nビジョンを定義する
n完成の定...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリント
n1つの統合的な出荷可能なプロダクトのインクリメ
ントのために、1つのプロダクトレベルのスプリン
トがある
基本的には1チームのスクラムと同じ
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントバックログ
スプリントバックログ
チームの
代表者
スプリントバックログ
プロダクトバックログ
2hタイムボックス
2hタイムボックス
マルチチーム
ス...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントプランニング第1部
nタイムボックス:1時間/1週間スプリント
n参加者:各チーム毎に2名+プロダクトオーナー
nチームの代表者たちは、依存関係を特定し...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントプランニング第2部
n各チーム毎に実施する
nチーム間の連携に課題がある場合
l他のチームのミーティングをオブザーブ出来る
nマルチチームスプリントプラ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
デイリースクラム
n各チーム毎に実施する
n情報共有を⾼めるために
他のチームのミーティングをオブザーブ出来る
基本的には1チームのスクラムと同じ
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スクラムオブスクラム
n チームの代表者たちは、情報共有と連携を⾼めるた
めに、週に数回開催することが出来る
n 各チームの代表者(Not スクラムマスター)
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
全体的な
プロダクト
バックログ
リファインメント
プロダクト
バックログ
リファインメント
チームの
代表者
プロダクトオーナー
プロダクトバックログ
チームの...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
プロダクトバックログリファインメント
n実施内容
l⼤きなプロダクトバックログアイテムの分割
lプロダクトバックログアイテムの詳細化
l⾒積もり
n同じ場所にいる...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
全体的な
プロダクトバックログリファインメント
n参加者:チーム毎に2名、プロダクトオーナー
n次回実施するであろうプロダクトバックログアイテ
ムの分割に集中する...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
チームレベルの
プロダクトバックログリファインメント
nプロダクトバックログアイテムが1チームで
完結している
n他のプロダクトバックログアイテムと
強い関連が無...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
マルチチームの
プロダクトバックログリファインメント
n参加者:全てのチームメンバーまたは、
チーム毎に2名(関連するチームのみ)
n同じ時間、同じ場所で⾏う
n...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
1.5hタイムボックス2hタイムボックス
プロダクトオーナー
全体的な
レトロスペクティブ
レトロスペクティブ
スプリント
レビュー
スプリントレビュー
〜レトロ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントレビュー
n参加者:各チームごとに2名+プロダクトオーナー+
ステークホルダー
nスプリントレビューバザール
l複数のエリアがある⼤きな部屋で実施
lエ...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントレトロスペクティブ
n全てのチームを妨げている障害は、組織の改善バッ
クログに挙げる
基本的には1チームのスクラムと同じ
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
全体的なレトロスペクティブ
nタイムボックス:45分/1週間スプリント
n参加者:各チームごとに1名+スクラムマスター
n次のスプリントの最初の早い時期に開催
n...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS での作成物
nプロダクトバックログ
nスプリントバックログ
n出荷可能なプロダクトのインクリメント
基本的には1チームのスクラムと同じ
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
プロダクトバックログ
n1つのプロダクトバックログ
n良いプロダクトバックログは以下を備えている:
l全て⾒積もられている
l上位は粒度が細かく、下位は粒度が粗い...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
スプリントバックログ
nプロダクトバックログアイテムから選択された、
チームがこなす必要がある作業のリストである。
nチーム毎に存在する
基本的には1チームのスク...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
出荷可能なプロダクトのインクリメント
nスプリントのアウトプット
n全てのチームの作業が統合されている
n出荷可能
lソフトウェアの市場性または価値ではない
l技...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
完成の定義
nプロダクトバックログアイテムについて合意した、
満たす基準の⼀覧
lプロダクト全体のために、⼀つの完成の定義が共
有される
lNot 受⼊基準
Ø全...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
未完了作業(Undone Work)
=出荷可能ー完成の定義
l 未完了作業が存在する場合は以下を決定しなくてはならな
い
Øどのように未完了作業を対処するのか?...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSSまとめ
nガイドとルールのセットからなる
lLeSS Framework
lLeSS Rules
n2つのスケーリングフレームワークが存在する
lLeSS...
©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS まとめ
n⼤規模であるがための⼯夫
lチームの代表者が参加するイベントが存在する
Ø スプリントプランニング第1部
Ø スプリントレビュー
lスクラムに...
©2016 Kenji Morita
Nexus と LeSS の比較
©2016 Kenji Morita
共通点
l1つのプロダクトプロダクトバックログ
l1人のプロダクトオーナー
l無料(PDF, Webs)
l複数(〜8 or 9)のスクラムチーム
lスクラムチーム内はスクラムで
l代表者が集まって、バック...
©2016 Kenji Morita
特徴的な言葉(抜粋)
lNexus
「スクラムフレームワークと同様に、Nexusの役
割・作成物・イベント・ルールは不変である。
Nexusの一部だけを導入することも可能だが、そ
れはNexusではない。」...
©2016 Kenji Morita
全体的な違い
lNexus
• Scrum並みに小さい!10P
• 最もScrumっぽいスケール手法
• 最小限で実行必須な事が決められている。
• 少ない決め事の割にオーバーヘッドはありそう。
lLeSS...
©2016 Kenji Morita
デイリースクラム
Nexus
毎日
LeSS
オプション
他チームにオブザーバー参加
(時間をずらす必要あり?)
©2016 Kenji Morita
レトロスペクティブ
Nexus
課題特定 アクション決め
ス
プ
リ
ン
ト
終
了
ス
プ
リ
ン
ト
終
了
LeSS
(次スプリントの
早い時期に実施)
©2016 Kenji Morita
チーム分割
lNexus
• 依存関係の最小化
• それ以上何も教えてくれない。ww
• スクラム同様ソフトウエア開発にも適用し
やすい?
lLeSS
• 基本的にフィーチャーチーム推奨
• わかりやすい。...
©2016 Kenji Morita
Scrumには無いチーム
lNexus
• Nexus統合チームが存在する。
• 必須、マネージャーチームではない。
lLeSS
• プロダクトグループ(マネージャー)
• Undoneチーム
• プロダク...
©2016 Kenji Morita
Undoneへの対処
lNexus
• Scrumble(Nexus Guide外)
lLeSS
• Undone チーム
https://kenschwaber.wordpress.com/2015/09...
©2016 Kenji Morita
LeSSに有ってNexusに無い物
lマネージャーの役割への言及
「中間管理職の役割は、全体を見て、
素晴らしい製品を作れるよう組織の能
力開発を行うことです。」
lビジネスパーソンの役割への言及
「製品開...
©2016 Kenji Morita
Nexusに有ってLeSSに無い物
l依存関係の最小化への強いこだわり
• 10Pで「依存関係」という言葉が35回!
• Nexus統合チーム
• Nexusスプリントバックログ
• 毎日Nexus(代表者...
©2016 Kenji Morita
比較のまとめ
lNexus
• ドキュメントが小さいので読みやすい。
• 理想的にチーム構成できる時にはシンプル。
• 依存関係の最小化と見える化にコストを使う。
• 大規模チームを分割する方向に向かいやす...
©2016 Kenji Morita
最後に
lチームが大きくなっても、変わらないマ
インドセットで、楽しくアジャイルに開
発しましょう。
l今後事例を持ち寄ったり、知識の共有を
進めていきましょう。
https://www.facebook....
Upcoming SlideShare
Loading in …5
×

Nexus and LeSS #rsgt2016

9,077 views

Published on

RSGT2016でお話した
NexusとLeSSの概要と比較のスライドです。

Published in: Technology
  • Login to see the comments

Nexus and LeSS #rsgt2016

  1. 1. ©2016 Kenji Morita Nexus と LeSS の 概要説明、比較 キヤノン株式会社 守⽥ 憲司 株式会社ガイアックス ⽊村 卓央
  2. 2. ©2016 Kenji Morita 守田 憲司 Kenji Morita キヤノン株式会社 デジタルシステム開発本部 主幹研究員 @wsfjp Nexus Guide 共訳
  3. 3. ©2016 Kenji Morita 本日のテーマ 開発チームが10人 超えたらどうする?
  4. 4. ©2016 Kenji Morita 3人 3
  5. 5. ©2016 Kenji Morita 6人 15
  6. 6. ©2016 Kenji Morita 9人 36
  7. 7. ©2016 Kenji Morita 12人 66 メンバーか9人を超えた場合は、調整の機会 が多くなってしまう。また、チームの規模が 大きいと、経験的プロセスの管理が複雑に なってしまう。 (スクラムガイド)
  8. 8. ©2016 Kenji Morita 大人数で 開発するには 分割が必要
  9. 9. ©2016 Kenji Morita 出典:9TH ANNUAL State of Agile™ Survey (Version one) 使われているスケール手法の割合 Scrum / Scrum of Scrum 69% 独自手法 25% SAFe 19% =========== LeSS 3% Nexus 未掲載 *複数回答
  10. 10. ©2016 Kenji Morita SAFe (19%) http://www.ogis-ri.co.jp/solution/1210904_6793.html
  11. 11. ©2016 Kenji Morita 出典:9TH ANNUAL State of Agile™ Survey (Version one) 使われているスケール手法の割合 Scrum / Scrum of Scrum 69% 独自手法 25% SAFe 19% =========== LeSS 3% Nexus 未掲載 *複数回答
  12. 12. ©2016 Kenji Morita 「スクラムガイド」より 「複数のスクラムチームが同じプロ ダクトの作業をすることがよくある。 そうした場合、プロダクトの作業は1 つのプロダクトバックログに記述す る。また、アイテムをグループにま とめる属性をプロダクトバックログ に追加する。」
  13. 13. ©2016 Kenji Morita 「スクラムガイド」より 「複数のスクラムチームが同じプロ ダクトの作業をすることがよくある。 そうした場合、プロダクトの作業は1 つのプロダクトバックログに記述す る。また、アイテムをグループにま とめる属性をプロダクトバックログ に追加する。」
  14. 14. ©2016 Kenji Morita コンウェイの法則 アーキテクチャは組織にしたがう 組織はアーキテクチャにしたがう
  15. 15. ©2016 Kenji Morita チーム分けで考慮すべきこと 組織 プロセス アーキ テクチャ
  16. 16. ©2016 Kenji Morita チーム分けで考慮すべきこと 組織 プロセス アーキ テクチャ
  17. 17. ©2016 Kenji Morita スケール階層と手法自体の大きさ 2階層 3階層 SAFe LeSS (2∼8チーム) LeSS Huge (9∼チーム) Nexus (約3∼9チーム) Nexus+ (約10∼チーム)小さい 大きい 手法自体 の大きさ
  18. 18. ©2016 Kenji Morita Nexusの概要
  19. 19. ©2016 Kenji Morita Nexus ガイド •無料公開されています。 •短いです。(10ページ) 英語版 2015年8月公開 日本語版 2015年12月公開 開発:Ken Schwaber and Scrum.org 翻訳:角 征典、守田 憲司 https://www.scrum.org/Resources/The-Nexus-Guide Nexus ガイドにもとづいて説明します。
  20. 20. ©2016 Kenji Morita Nexus The exoskeleton(外⾻格) of scaled Scrum
  21. 21. ©2016 Kenji Morita スコープ l約3〜9スクラムチーム l1つのプロダクトバックログ 「チームが3つ以上になると、さらに事 態は複雑になる」
  22. 22. ©2016 Kenji Morita スクラムチーム lチーム間の依存関係が少なくなるように 分割する l関連する以下の要素をチーム内にそろえ る • 要求 • ドメイン知識 • ソフトウェアやテストの作成物
  23. 23. ©2016 Kenji Morita ソフトウェアプラクティス l多くのソフトウェアプラクティスが必要 である。 l大規模な環境では特に自動化が必要であ る。
  24. 24. ©2016 Kenji Morita Nexusの説明
  25. 25. ©2016 Kenji Morita NEXUSの役割
  26. 26. ©2016 Kenji Morita Nexusの役割 Nexus統合チーム 約3〜9のスクラムチーム プロダクトオーナー(全体で1人) スクラムマスター(兼任可) チームメンバー(兼任可) 適切な代表者 (特に定義されてないが) スクラムマスター
  27. 27. ©2016 Kenji Morita Nexus統合チーム lすべての作業の統合を成功させる最終的 な責任がある。 lチーム間の技術的・非技術的な制約を解 消する。 l依存関係やチーム間の問題に対する認識 を高める。 lコーチング、コンサルティングを行う。
  28. 28. ©2016 Kenji Morita Nexus統合チームの プロダクトオーナー lNexus全体で1人のプロダクトオー ナー l統合インクリメントの価値を最大化する。 lプロダクトバックログの順番とリファイ ンメントに最終的な責任を持つ。
  29. 29. ©2016 Kenji Morita Nexus統合チームの スクラムマスター lNexusが理解され、実施されることに 責任を持つ。
  30. 30. ©2016 Kenji Morita Nexus統合チームメンバー l(3ではなく)1人以上 lスクラムチームが獲得、実施、学習でき るようにコーチングや指導をする。 • プラクティス、ツール、開発、インフラ、 アーキテクチャ標準
  31. 31. ©2016 Kenji Morita Nexusの役割 Nexus統合チーム 約3〜9のスクラムチーム プロダクトオーナー(全体で1人) スクラムマスター(兼任可) チームメンバー(兼任可) 適切な代表者 (特に定義されてないが) スクラムマスター
  32. 32. ©2016 Kenji Morita NEXUSのイベント
  33. 33. ©2016 Kenji Morita イベント lNexusスプリントプランニング lNexusデイリースクラム lNexusスプリントレビュー lNexusスプリントレトロスペクティブ lリファインメント
  34. 34. ©2016 Kenji Morita Nexusスプリントプランニング l代表者 l各チームで
  35. 35. ©2016 Kenji Morita Nexusスプリントプランニング1 l各スクラムチームの代表者が 作業の順番を確認・調整する。 lNexusスプリントゴールを作 成する。 l成果物 • Nexusゴール
  36. 36. ©2016 Kenji Morita Nexusスプリントプランニング2 l各スクラムチームでスプリン トプランニングを実施する。 • 他のチームと情報交換する。 • 同じ場所で実施すると新しく発 見した依存関係が共有できる。 l成果物(チーム毎) • スプリントゴール • スプリントバックログ
  37. 37. ©2016 Kenji Morita Nexusデイリースクラム lチームの代表者(毎日)。 l各スクラムチーム
  38. 38. ©2016 Kenji Morita Nexusデイリースクラム1 l3つの質問 ü 昨日の作業はうまく統合された か?うまく統合されていなけれ ば、それはなぜか? ü 新たに特定された依存関係は何 か? ü Nexusのチーム間で共有が必要 な情報は何か? l特定された作業は各スクラム チームのデイリースクラムに伝 えられる。
  39. 39. ©2016 Kenji Morita Nexusデイリースクラム2 lNexusデイリースクラムで特定 された統合の問題を解決できる ように、その日の計画を立てる。
  40. 40. ©2016 Kenji Morita Nexusスプリントレビュー lすべてのチームがプロダク トオーナーのもとに集まり、 統合されたインクリメント をレビューする。 l全ての機能をレビューでき ないかもしれない。 Ø上手くやってね♪
  41. 41. ©2016 Kenji Morita Nexusスプリントレトロスペクティブ l代表者 • 共通課題の特定 l各スクラムチーム • 個別に実施 l代表者 • 必要なアクションの見える化、 追跡について合意する。
  42. 42. ©2016 Kenji Morita Nexusスプリントレトロスペクティブ l全てのレトロスペクティブで扱うべき議 題 • 完成していないものはあるか?Nexusは技 術負債を作り出していないか? • 作成物(特にコード)は、 (できれば毎 日)頻繁に統合されているか? • 未解決の依存関係が蓄積されない程度に、 頻繁にソフトウェアがビルド・テスト・デ プロイされているか?
  43. 43. ©2016 Kenji Morita リファインメント 1. 十分に詳細になるまで分解する。 • 担当するチームを予測するために必要にな る。 2. 依存関係を特定して見える化する。 • 作業順番や割り当てを見直し、チーム間の 依存関係を最小化するために、これらの情 報が必要となる。
  44. 44. ©2016 Kenji Morita NEXUSの作成物
  45. 45. ©2016 Kenji Morita プロダクトバックログ l全体で1つのプロダクトバックログ lPBIがNexusスプリントプランニングに 向けて(Ready)準備完了とは? • スクラムチームによって選択可能 • 依存関係は排除または最小化されている。 • そのスクラムチームだけでプラクトバック ログアイテムを完成できなければいけない。
  46. 46. ©2016 Kenji Morita Nexusスプリントバックログ lNexus統合チームのスプリントバック ログ • 「スクラムチームのスプリントバックログ にある全てのプロダクトバックログアイテ ムをまとめたものである。」 lスプリントにおける依存関係や作業の流 れを強調するために使用する。 l少なくとも毎日更新する。
  47. 47. ©2016 Kenji Morita プロダクトバックログ バックログとスプリントゴール Nexus スプリントバックログ Nexus スプリントゴール スプリントゴール スプリントゴール スプリントゴール スプリントゴール スプリントゴール スプリントゴール スプリントゴール スプリントバックログ
  48. 48. ©2016 Kenji Morita 統合インクリメント l完了した「統合された作業」すべての総 和である。 l利用可能でリリース判断可能なものでな ければいけない。 l「完成」の定義を満たしていなければい けない。 lNexusスプリントレビューで検査する。
  49. 49. ©2016 Kenji Morita 作成物の透明性 l技術的負債が許容不可能になる前に、依 存関係を検出および解消しなければいけ ない。 l許容不可能な技術的負債かどうかは、結 合する時にはじめてわかる。
  50. 50. ©2016 Kenji Morita 「完成」の定義 lNexus統合チームは「完成」の定義に 実行責任を持つ。 lチーム独自の「完成」の定義は、インク リメントの完成の定義より緩い基準を適 用してはいけない。
  51. 51. ©2016 Kenji Morita Nexusについて質問等
  52. 52. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS(Large-Scale Scrum) http://less.works/
  53. 53. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. Certified Scrum Professional®/Scrum Developer®/ScrumMaster®/Scrum Product Owner® Project Management Professional (PMP)® EXIN Agile Scrum Foundation 認定講師 アジャイルサムライ 横浜道場主催(休眠) PMI⽇本⽀部 アジャイルプロジェクトマネジメント研究会 会員 TOCfE横浜塾主催 LeSS Study主催 Fearless Changeアジャイルに効くアイデアを⼈めるための48のパターン共訳 木村 卓央 KIMURA Takao R&D PMO @tw_takubon http://facebook.com/kimura.takao http://about.me/tw_takubon
  54. 54. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
  55. 55. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. http://www.gaiax.co.jp/
  56. 56. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS Study https://www.facebook.com/groups/less.study/ https://less-study.doorkeeper.jp/
  57. 57. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 絶賛翻訳中・・・ PBI = 75
  58. 58. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. おことわり ただいま、翻訳中かつ、less.workの内容も変わるこ とがあります。 今回使⽤した⽤語について、今後変わることもあり ます まだまだ理解が⾜りていないところもあるかも…
  59. 59. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS アジェンダ nLeSSの構成と特徴 nLeSSのフレームワーク l役割 lイベント l作成物
  60. 60. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSSの構成 http://less.works/
  61. 61. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSSの構成 nLeSSは、複数チームのコンテキストにスクラムを 適⽤するためのガイドとルールのセットからなる lLeSS Framework lLeSS Rules(January 2016) n2つのスケーリングフレームワーク lLeSS Ø2~8チーム(それぞれ8名) lLeSS Huge Ø1プロダクト数千⼈まで
  62. 62. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSSの構成 nガイドとルール lLeSS Framework lLeSS Huge lLeSS Rules n実験(秘訣) l原則(Principles) l構造(Structure) lマネジメント(Management) l技術的優位性(Technical Excellence) l採⽤(Adoption)
  63. 63. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スクラムマスター &フィーチャーチーム スプリントレビュー レトロスペクティブ 全体的な レトロスペクティブ デイリースクラム プロダクト バックログ リファインメント スプリント バックログ スプリント プランニング 1 スプリント プランニング 2 協調 LeSS Framework http://less.works/
  64. 64. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントレビュー レトロスペクティブ 全体的な レトロスペクティブ デイリースクラム プロダクト バックログ リファインメント スプリント バックログ スプリント プランニング 1 スプリント プランニング 2 協調 スクラムマスター &フィーチャーチーム プロダクト オーナー 出荷可能な プロダクトの インクリメント LeSS Huge http://less.works/
  65. 65. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS Huge n8チーム以上に適したLeSSの 第2のフレームワーク n概念的には、LeSSフレームワークの上に 複数のLeSSフレームワークを積み重ねて スケールアップされる n基本的にはLeSSのフレームワークと同じ
  66. 66. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS Rules nLeSS Frameworkの定義が書かれている n最新版は 2016年1⽉版 nLeSS Framework Rules lLeSS Structure lLeSS Product lLeSS Sprint nLeSS Huge Framework Rules lLeSS Huge Structure lLeSS Huge Product lLeSS Huge Sprint
  67. 67. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. Large-scale Scrum はスクラム 透明性 より少ない労⼒で ⼤きな成果を プロダクト全体に フォーカス 顧客中⼼ 完成に向けた 継続的改善 リーン思考 システム思考 経験的プロセス コントロール 待ち⾏列理論 原則 http://less.works/
  68. 68. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スクラムマスター フィーチャーチーム 組織構造 チーム 顧客価値による 組織化 コミュニティ 構造 構造 http://less.works/
  69. 69. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS での組織構造 プロダクト グループ⻑ フィーチャー チーム #1 フィーチャー チーム #2 フィーチャー チーム #n 未完了に 対応する 部⾨ プロダクト オーナー (チーム) プロダクトグループ⻑ (Head of the Product Group) 全てのチームの階層的なマネージャー 彼らは現場主義によってチームをサポートし、それら が障害の除去し、チームが成⻑するのを助けます フィーチャーチーム (Feature teams) 開発作業を⾏う 各フィーチャーチームは、スクラムマスターとクロス ファンクショナル(機能横断的)、⾃⼰組織化なチーム プロダクトオーナー(チーム) プロダクトマネジメント チームとプロダクトオーナーの関係が対等である 未完了に対応する部⾨ (Undone department) 未完了作業(Undone Work)に対応する 理想的には存在しない 彼らは最初からチームに統合されるべき http://less.works/
  70. 70. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. マネージャーの役割 現場主義 問題解決の⽅法を教える ⾃⼰組織化 改善サービス スクラムマスターとしての マネージャー マネージメント マネジメント http://less.works/
  71. 71. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 技術的優位性 技術的優位性 http://less.works/
  72. 72. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 3つの原則 継続的改善 フィーチャーチーム 採⽤マップ 開始 コーチング 採⽤ 採⽤ http://less.works/
  73. 73. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 基本は1チームのスクラムと同じ スクラムのプラクティスとアイデアを保持 n1つのプロダクトバックログ n1つの完成の定義 n各スプリントの終わりに出荷可能な成果物を インクリメント n1⼈の(全体の)プロダクトオーナー nクロスファンクショナル(機能横断的)なチーム nスプリント lLeSSでは、全てのチームが共通のスプリントで 共通の出荷可能な成果物をデリバリーする
  74. 74. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 協調と統合(Coordination & Integration) nとりあえず話す nコードで会話する nデイリースクラムにオブザーバーを送り込む nコミュニティと監視者(guardians)を構成する nスクラムオブスクラム nマルチチームのミーティング nボトルネックを活⽤し、壊し、スキルを⽣み出す 旅⾏者(経験豊富な技術の専⾨化) n主導的なチーム
  75. 75. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スクラムマスター &フィーチャーチーム スプリントレビュー レトロスペクティブ 全体的な レトロスペクティブ デイリースクラム プロダクト バックログ リファインメント スプリント バックログ スプリント プランニング 1 スプリント プランニング 2 協調 LeSSのフレームワーク http://less.works/
  76. 76. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS での役割 nプロダクトオーナー l全体で1⼈のプロダクトオーナー nスクラムマスター nチーム 基本的には1チームのスクラムと同じ
  77. 77. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. プロダクトオーナー nプロダクトバックログの管理者 n開発チームの成果を検証する nプロダクトバックログの優先順位付け lビジネス上に関する情報を収集し分析する nプロダクトバックログアイテムの明確化 l振る舞いの詳細化、品質、ユーザーエクスペリエ ンス、その他設計上の問題を明確化する 基本的には1チームのスクラムと同じ
  78. 78. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 明確化よりも優先順位付け n優先順位付けは、ひとりのプロダクトオーナー n明確化は、チームで協業する lユーザー/顧客とチームとの直接会話することを 奨励する lその場を提供し、場をつなげる役割としてのプロ ダクトオーナー nメリット lプロダクトオーナーは全体像を描くことに集中す ることができる lチームが直接顧客と協⼒することで、モチベー ションや、顧客への共感を向上させる
  79. 79. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スクラムマスター nチームにプロダクト全体を意識するよう働きかける l⼤きなプロダクトグループの⼈々の相互作⽤、遅 延、原因、ポテンシャル(潜在リスク)などの 各個⼈の考えの範囲を超えてサポート lプロダクト全体の狙いをチームに意識付けをおこ なう n透明性を保つよう働きかける nフルタイムで専任 n場合によっては3チームまで兼務は可能
  80. 80. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. チーム n⾃⼰組織化 nクロスファンクショナル(機能横断的) n全てのチームの作業に共同で責任を負う nチームのゴールを持つ nコンポーネントチームではなく フィーチャーチーム n外部のチームや⼈々との関係を管理する責任を負う 基本的には1チームのスクラムと同じ
  81. 81. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. プロダクト バックログ 顧客中⼼ フィーチャー フィーチャーチーム: - 安定かつ⻑寿命 - クロスファンクショナル (機能横断的) - コンポーネント横断 出荷可能な プロダクトの インクリメント チームは、エンドツーエンドの顧客中⼼のフィーチャーを完了するために 必要な知識とスキルを持っています。 ない場合は、チームが学ぶか、必要な知識とスキルを獲得することが 期待されます。 フィーチャーチーム http://less.works/
  82. 82. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS でのイベント nスプリントプランニング(1部、2部) nデイリースクラム nスプリントレビュー nスプリントレトロスペクティブ n全体的なスプリントレトロスペクティブ nプロダクトバックログリファインメント n全体的なプロダクトバックログリファインメント n(スクラムオブスクラム) 基本的には1チームのスクラムと同じ
  83. 83. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 初期の プロダクトバックログリファインメント nプロジェクト最初に⾏う n基本的にはプロダクトバックログリファインメント と同じ nビジョンを定義する n完成の定義を作成する
  84. 84. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリント n1つの統合的な出荷可能なプロダクトのインクリメ ントのために、1つのプロダクトレベルのスプリン トがある 基本的には1チームのスクラムと同じ
  85. 85. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントバックログ スプリントバックログ チームの 代表者 スプリントバックログ プロダクトバックログ 2hタイムボックス 2hタイムボックス マルチチーム スプリントプランニング 第2部 選ばれたプロダクト バックログアイテム 選ばれたプロダクト バックログアイテム スプリント プランニング 第2部 チームの 代表者 プロダクトオーナー スプリント プランニング 第1部 スプリントプランニング http://less.works/
  86. 86. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントプランニング第1部 nタイムボックス:1時間/1週間スプリント n参加者:各チーム毎に2名+プロダクトオーナー nチームの代表者たちは、依存関係を特定し、連携を 議論することによって、⾃分たちでプロダクトバッ クログの割り振りを決定する
  87. 87. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントプランニング第2部 n各チーム毎に実施する nチーム間の連携に課題がある場合 l他のチームのミーティングをオブザーブ出来る nマルチチームスプリントプランニング第2部 l2つのチームが似たようなフィーチャーに取り組 むまたは、同じコンポーネントに影響を与える場 合に実施する 基本的には1チームのスクラムと同じ
  88. 88. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. デイリースクラム n各チーム毎に実施する n情報共有を⾼めるために 他のチームのミーティングをオブザーブ出来る 基本的には1チームのスクラムと同じ
  89. 89. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スクラムオブスクラム n チームの代表者たちは、情報共有と連携を⾼めるた めに、週に数回開催することが出来る n 各チームの代表者(Not スクラムマスター)
  90. 90. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 全体的な プロダクト バックログ リファインメント プロダクト バックログ リファインメント チームの 代表者 プロダクトオーナー プロダクトバックログ チームの 代表者 プロダクトバックログ チームの 代表者 潜在的な アイテム マルチチーム バックログ リファインメント 潜在的な アイテム スプリントの5-10%短めで(4h) プロダクトバックログリファインメント http://less.works/
  91. 91. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. プロダクトバックログリファインメント n実施内容 l⼤きなプロダクトバックログアイテムの分割 lプロダクトバックログアイテムの詳細化 l⾒積もり n同じ場所にいるのであれば l同じ時間、1つの⼤きな部屋で実施する l各チーム別の壁を利⽤するなど nいくつかのレベルで実施される l全体的 lチームレベル lマルチチーム
  92. 92. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 全体的な プロダクトバックログリファインメント n参加者:チーム毎に2名、プロダクトオーナー n次回実施するであろうプロダクトバックログアイテ ムの分割に集中する l軽量な分析 l⾒積り Øチーム間で共通した⾒積りのベースラインを確保 するためにクロスチームで⾒積もる l強い関連のあるプロダクトバックログアイテムの 特定 Ø共同での作業 Ø共通的な作業の提案または調整
  93. 93. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. チームレベルの プロダクトバックログリファインメント nプロダクトバックログアイテムが1チームで 完結している n他のプロダクトバックログアイテムと 強い関連が無い 基本的には1チームのスクラムと同じ
  94. 94. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. マルチチームの プロダクトバックログリファインメント n参加者:全てのチームメンバーまたは、 チーム毎に2名(関連するチームのみ) n同じ時間、同じ場所で⾏う n共通のプロダクバックログアイテムまたは強い関連 のあるプロダクバックログアイテムの連携強化
  95. 95. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 1.5hタイムボックス2hタイムボックス プロダクトオーナー 全体的な レトロスペクティブ レトロスペクティブ スプリント レビュー スプリントレビュー 〜レトロスペクティブ 1.5h http://less.works/
  96. 96. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントレビュー n参加者:各チームごとに2名+プロダクトオーナー+ ステークホルダー nスプリントレビューバザール l複数のエリアがある⼤きな部屋で実施 lエリア毎にチームの代表が、そのチームによって 開発されたフィーチャーをデモし、議論する lステークホルダーは興味のあるエリアに訪れ、 チームはフィードバックを記録する n最初と最後は、全体的なフィードバックと整合性を ⾼めるために、全員で議論する
  97. 97. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントレトロスペクティブ n全てのチームを妨げている障害は、組織の改善バッ クログに挙げる 基本的には1チームのスクラムと同じ
  98. 98. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 全体的なレトロスペクティブ nタイムボックス:45分/1週間スプリント n参加者:各チームごとに1名+スクラムマスター n次のスプリントの最初の早い時期に開催 nプロダクトや組織全体のための改善策の特定と改善 計画を⾏う。
  99. 99. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS での作成物 nプロダクトバックログ nスプリントバックログ n出荷可能なプロダクトのインクリメント 基本的には1チームのスクラムと同じ
  100. 100. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. プロダクトバックログ n1つのプロダクトバックログ n良いプロダクトバックログは以下を備えている: l全て⾒積もられている l上位は粒度が細かく、下位は粒度が粗い l優先順位が付いている 基本的には1チームのスクラムと同じ
  101. 101. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. スプリントバックログ nプロダクトバックログアイテムから選択された、 チームがこなす必要がある作業のリストである。 nチーム毎に存在する 基本的には1チームのスクラムと同じ
  102. 102. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 出荷可能なプロダクトのインクリメント nスプリントのアウトプット n全てのチームの作業が統合されている n出荷可能 lソフトウェアの市場性または価値ではない l技術的にプロダクトが出荷可能であり、現在実装 したフィーチャーに必要な作業が完了している n完成の定義に依存する 基本的には1チームのスクラムと同じ
  103. 103. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 完成の定義 nプロダクトバックログアイテムについて合意した、 満たす基準の⼀覧 lプロダクト全体のために、⼀つの完成の定義が共 有される lNot 受⼊基準 Ø全てのプロダクトバックログアイテムに均⼀に適 ⽤される n最初の完成の定義は、初期プロダクトバックログリ ファインメントで⾏われる n各チームは、独⾃拡張した完成の定義を持つことが できる 基本的には1チームのスクラムと同じ
  104. 104. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. 未完了作業(Undone Work) =出荷可能ー完成の定義 l 未完了作業が存在する場合は以下を決定しなくてはならな い Øどのように未完了作業を対処するのか? Øどのように将来的に未完了作業を少なくするための改善を ⾏うのか? l リスクと遅延を引き起こす Ø遅延:未完了作業を⾏う⼿間が必要になる • プロダクトオーナーは、市場のニーズや変化に対応出来 ない→柔軟性の⽋如につながる Øリスク:透明性の⽋如の原因となる • プロダクトのリリースに近くまで、⾏わないことのリス ク(パフォーマンステスト等)
  105. 105. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSSまとめ nガイドとルールのセットからなる lLeSS Framework lLeSS Rules n2つのスケーリングフレームワークが存在する lLeSS (2~8チームまで) lLeSS Huge (1プロダクトで数千⼈規模) nLeSS = スケールしたScrum 基本的には1チームのスクラムと同じ
  106. 106. ©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC. LeSS まとめ n⼤規模であるがための⼯夫 lチームの代表者が参加するイベントが存在する Ø スプリントプランニング第1部 Ø スプリントレビュー lスクラムには無いイベントが定義されている Ø 全体的なプロダクトバックログリファインメント Ø 全体的なレトロスペクティブ l協調と統合 Ø オブザーブ Ø コミュニティと監視者(guardians)を構成する Ø スクラムオブスクラム Ø マルチチームのミーティング Ø ボトルネックを活⽤し、壊し、スキルを⽣み出す 旅⾏者(経験豊富な技術の専⾨化) Ø 主導的なチーム
  107. 107. ©2016 Kenji Morita Nexus と LeSS の比較
  108. 108. ©2016 Kenji Morita 共通点 l1つのプロダクトプロダクトバックログ l1人のプロダクトオーナー l無料(PDF, Webs) l複数(〜8 or 9)のスクラムチーム lスクラムチーム内はスクラムで l代表者が集まって、バックログリファイ ンメントを実施する。 lスクラムマスターは複数チーム兼務可能
  109. 109. ©2016 Kenji Morita 特徴的な言葉(抜粋) lNexus 「スクラムフレームワークと同様に、Nexusの役 割・作成物・イベント・ルールは不変である。 Nexusの一部だけを導入することも可能だが、そ れはNexusではない。」 lLeSS 「LeSSは、大きな複数チームやマルチサイト、 あるいはオフショアのアジャイル開発を先導する のに上手くいくことが分かった追加のルールと秘 訣のセットである。これらの秘訣は伝統的なスク ラムのコンテクストにおける実験である 。」
  110. 110. ©2016 Kenji Morita 全体的な違い lNexus • Scrum並みに小さい!10P • 最もScrumっぽいスケール手法 • 最小限で実行必須な事が決められている。 • 少ない決め事の割にオーバーヘッドはありそう。 lLeSS • 全部やれとは言っていない。 • 上手くいった事を集めている。 • マネージャーの役割にも言及している。
  111. 111. ©2016 Kenji Morita デイリースクラム Nexus 毎日 LeSS オプション 他チームにオブザーバー参加 (時間をずらす必要あり?)
  112. 112. ©2016 Kenji Morita レトロスペクティブ Nexus 課題特定 アクション決め ス プ リ ン ト 終 了 ス プ リ ン ト 終 了 LeSS (次スプリントの 早い時期に実施)
  113. 113. ©2016 Kenji Morita チーム分割 lNexus • 依存関係の最小化 • それ以上何も教えてくれない。ww • スクラム同様ソフトウエア開発にも適用し やすい? lLeSS • 基本的にフィーチャーチーム推奨 • わかりやすい。 • 詳細に解説されている。
  114. 114. ©2016 Kenji Morita Scrumには無いチーム lNexus • Nexus統合チームが存在する。 • 必須、マネージャーチームではない。 lLeSS • プロダクトグループ(マネージャー) • Undoneチーム • プロダクトオーナーチーム
  115. 115. ©2016 Kenji Morita Undoneへの対処 lNexus • Scrumble(Nexus Guide外) lLeSS • Undone チーム https://kenschwaber.wordpress.com/2015/09/28/scaling-the-nexus-and-scrumbling/ Sprint Sprint Sprint SprintScrumble http://less.works/less/structure/organizational-structure.html (理想ではない)
  116. 116. ©2016 Kenji Morita LeSSに有ってNexusに無い物 lマネージャーの役割への言及 「中間管理職の役割は、全体を見て、 素晴らしい製品を作れるよう組織の能 力開発を行うことです。」 lビジネスパーソンの役割への言及 「製品開発におけるプロダクトオー ナーは、ビジネス側から来るべきで す。」
  117. 117. ©2016 Kenji Morita Nexusに有ってLeSSに無い物 l依存関係の最小化への強いこだわり • 10Pで「依存関係」という言葉が35回! • Nexus統合チーム • Nexusスプリントバックログ • 毎日Nexus(代表者)デイリースクラム • 3パートのレトロスペクティブ • リファインメントの目的も依存関係最小化 l最後はNexusを解消?
  118. 118. ©2016 Kenji Morita 比較のまとめ lNexus • ドキュメントが小さいので読みやすい。 • 理想的にチーム構成できる時にはシンプル。 • 依存関係の最小化と見える化にコストを使う。 • 大規模チームを分割する方向に向かいやすい。 lLeSS • 複数チームになってしまった時の改善策になる。 • よく起きる課題に対する現実的な解決策がある。 • マネージャー、ビジネスパーソンの役割がわかる。 • LeSS Huge(9チーム〜)も公開されている。
  119. 119. ©2016 Kenji Morita 最後に lチームが大きくなっても、変わらないマ インドセットで、楽しくアジャイルに開 発しましょう。 l今後事例を持ち寄ったり、知識の共有を 進めていきましょう。 https://www.facebook.com/groups/ScaledScrum/

×