©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%SAFe 19%
===========LeSS 3%Nexus 未掲載
*複数回答
©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%SAFe 19%
===========LeSS 3%Nexus 未掲載
*複数回答
©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翻訳:角征典、守田憲司
https://www.scrum.org/Resources/The-Nexus-Guide
Nexus ガイドにもとづいて説明します。
©2016 Kenji Morita
NexusThe 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のチーム間で共有が必要な情報は何か?
l特定された作業は各スクラムチームのデイリースクラムに伝えられる。
©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スプリントにおける依存関係や作業の流れを強調するために使用する。
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 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS(Large-Scale Scrum)
http://less.works/
©2016 GaiaxCo.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_takubonhttp://facebook.com/kimura.takao
http://about.me/tw_takubon
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
http://www.gaiax.co.jp/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS Study
https://www.facebook.com/groups/less.study/
https://less-study.doorkeeper.jp/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
絶賛翻訳中・・・
PBI = 75
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
おことわりただいま、翻訳中かつ、less.workの内容も変わることがあります。今回使⽤した⽤語について、今後変わることもあります
まだまだ理解が⾜りていないところもあるかも…
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS アジェンダnLeSSの構成と特徴nLeSSのフレームワークl役割lイベントl作成物
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成nLeSSは、複数チームのコンテキストにスクラムを適⽤するためのガイドとルールのセットからなるlLeSS FrameworklLeSS Rules(January 2016)
n2つのスケーリングフレームワークlLeSSØ2~8チーム(それぞれ8名)
lLeSS HugeØ1プロダクト数千⼈まで
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSSの構成nガイドとルールlLeSS FrameworklLeSS HugelLeSS Rules
n実験(秘訣)l原則(Principles)l構造(Structure)lマネジメント(Management)l技術的優位性(Technical Excellence)l採⽤(Adoption)
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター&フィーチャーチーム
スプリントレビュー
レトロスペクティブ
全体的なレトロスペクティブ
デイリースクラム
プロダクトバックログ
リファインメント
スプリントバックログ
スプリントプランニング 1
スプリントプランニング 2 協調
LeSS Framework
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントレビュー
レトロスペクティブ
全体的なレトロスペクティブ
デイリースクラム
プロダクトバックログ
リファインメント
スプリントバックログ
スプリントプランニング 1
スプリントプランニング 2 協調
スクラムマスター&フィーチャーチーム
プロダクトオーナー
出荷可能なプロダクトの
インクリメント
LeSS Huge
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS Hugen8チーム以上に適したLeSSの第2のフレームワーク
n概念的には、LeSSフレームワークの上に複数のLeSSフレームワークを積み重ねてスケールアップされる
n基本的にはLeSSのフレームワークと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS RulesnLeSS Frameworkの定義が書かれているn最新版は 2016年1⽉版
nLeSS Framework RuleslLeSS StructurelLeSS ProductlLeSS Sprint
nLeSS Huge Framework RuleslLeSS Huge StructurelLeSS Huge ProductlLeSS Huge Sprint
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
Large-scale Scrumはスクラム 透明性
より少ない労⼒で⼤きな成果を
プロダクト全体にフォーカス
顧客中⼼
完成に向けた継続的改善
リーン思考
システム思考
経験的プロセスコントロール
待ち⾏列理論
原則
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター
フィーチャーチーム
組織構造
チーム
顧客価値による組織化
コミュニティ
構造
構造
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS での組織構造プロダクトグループ⻑
フィーチャーチーム #1
フィーチャーチーム #2
フィーチャーチーム #n
未完了に対応する
部⾨
プロダクトオーナー(チーム)
プロダクトグループ⻑(Head of the Product Group)
全てのチームの階層的なマネージャー彼らは現場主義によってチームをサポートし、それらが障害の除去し、チームが成⻑するのを助けます
フィーチャーチーム(Feature teams)
開発作業を⾏う各フィーチャーチームは、スクラムマスターとクロスファンクショナル(機能横断的)、⾃⼰組織化なチーム
プロダクトオーナー(チーム) プロダクトマネジメントチームとプロダクトオーナーの関係が対等である
未完了に対応する部⾨(Undone department)
未完了作業(Undone Work)に対応する理想的には存在しない彼らは最初からチームに統合されるべき
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
マネージャーの役割
現場主義
問題解決の⽅法を教える
⾃⼰組織化
改善サービス
スクラムマスターとしてのマネージャー
マネージメント
マネジメント
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
技術的優位性
技術的優位性
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
3つの原則
継続的改善
フィーチャーチーム採⽤マップ
開始
コーチング
採⽤
採⽤
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
基本は1チームのスクラムと同じスクラムのプラクティスとアイデアを保持
n1つのプロダクトバックログn1つの完成の定義n各スプリントの終わりに出荷可能な成果物をインクリメント
n1⼈の(全体の)プロダクトオーナーnクロスファンクショナル(機能横断的)なチームnスプリントlLeSSでは、全てのチームが共通のスプリントで共通の出荷可能な成果物をデリバリーする
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
協調と統合(Coordination & Integration)
nとりあえず話すnコードで会話するnデイリースクラムにオブザーバーを送り込むnコミュニティと監視者(guardians)を構成するnスクラムオブスクラムnマルチチームのミーティングnボトルネックを活⽤し、壊し、スキルを⽣み出す旅⾏者(経験豊富な技術の専⾨化)
n主導的なチーム
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スクラムマスター&フィーチャーチーム
スプリントレビュー
レトロスペクティブ
全体的なレトロスペクティブ
デイリースクラム
プロダクトバックログ
リファインメント
スプリントバックログ
スプリントプランニング 1
スプリントプランニング 2 協調
LeSSのフレームワーク
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS での役割nプロダクトオーナーl全体で1⼈のプロダクトオーナー
nスクラムマスターnチーム
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
プロダクトオーナーnプロダクトバックログの管理者n開発チームの成果を検証するnプロダクトバックログの優先順位付けlビジネス上に関する情報を収集し分析する
nプロダクトバックログアイテムの明確化l振る舞いの詳細化、品質、ユーザーエクスペリエンス、その他設計上の問題を明確化する
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
明確化よりも優先順位付けn優先順位付けは、ひとりのプロダクトオーナーn明確化は、チームで協業するlユーザー/顧客とチームとの直接会話することを奨励する
lその場を提供し、場をつなげる役割としてのプロダクトオーナー
nメリットlプロダクトオーナーは全体像を描くことに集中することができる
lチームが直接顧客と協⼒することで、モチベーションや、顧客への共感を向上させる
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スクラムマスターnチームにプロダクト全体を意識するよう働きかけるl⼤きなプロダクトグループの⼈々の相互作⽤、遅延、原因、ポテンシャル(潜在リスク)などの各個⼈の考えの範囲を超えてサポート
lプロダクト全体の狙いをチームに意識付けをおこなう
n透明性を保つよう働きかけるnフルタイムで専任n場合によっては3チームまで兼務は可能
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
チームn⾃⼰組織化nクロスファンクショナル(機能横断的)n全てのチームの作業に共同で責任を負うnチームのゴールを持つnコンポーネントチームではなくフィーチャーチーム
n外部のチームや⼈々との関係を管理する責任を負う
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
プロダクトバックログ
顧客中⼼フィーチャー
フィーチャーチーム:- 安定かつ⻑寿命- クロスファンクショナル
(機能横断的)- コンポーネント横断
出荷可能なプロダクトのインクリメント
チームは、エンドツーエンドの顧客中⼼のフィーチャーを完了するために必要な知識とスキルを持っています。ない場合は、チームが学ぶか、必要な知識とスキルを獲得することが期待されます。
フィーチャーチーム
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS でのイベントnスプリントプランニング(1部、2部)nデイリースクラムnスプリントレビューnスプリントレトロスペクティブn全体的なスプリントレトロスペクティブnプロダクトバックログリファインメントn全体的なプロダクトバックログリファインメントn(スクラムオブスクラム)
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
初期のプロダクトバックログリファインメントnプロジェクト最初に⾏うn基本的にはプロダクトバックログリファインメントと同じ
nビジョンを定義するn完成の定義を作成する
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントn1つの統合的な出荷可能なプロダクトのインクリメントのために、1つのプロダクトレベルのスプリントがある
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントバックログスプリントバックログ
チームの代表者
スプリントバックログ
プロダクトバックログ
2h タイ
ムボ
ック
ス
2h タイ
ムボ
ック
ス
マル
チチ
ーム
スプ
リン
トプ
ラン
ニン
グ第
2部
選ばれたプロダクトバックログアイテム
選ばれたプロダクトバックログアイテム
スプリントプランニング
第2部
チームの代表者
プロダクトオーナースプリント
プランニング第1部
スプリントプランニング
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントプランニング第1部nタイムボックス:1時間/1週間スプリントn参加者:各チーム毎に2名+プロダクトオーナー
nチームの代表者たちは、依存関係を特定し、連携を議論することによって、⾃分たちでプロダクトバックログの割り振りを決定する
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントプランニング第2部n各チーム毎に実施するnチーム間の連携に課題がある場合l他のチームのミーティングをオブザーブ出来る
nマルチチームスプリントプランニング第2部l2つのチームが似たようなフィーチャーに取り組むまたは、同じコンポーネントに影響を与える場合に実施する
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
デイリースクラムn各チーム毎に実施するn情報共有を⾼めるために他のチームのミーティングをオブザーブ出来る
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スクラムオブスクラムn チームの代表者たちは、情報共有と連携を⾼めるた
めに、週に数回開催することが出来るn 各チームの代表者(Not スクラムマスター)
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
全体的なプロダクトバックログ
リファインメント
プロダクトバックログ
リファインメント
チームの代表者
プロダクトオーナー
プロダクトバックログチームの代表者
プロダクトバックログ
チームの代表者
潜在的なアイテム
マル
チチ
ーム
バッ
クロ
グリ
ファ
イン
メン
ト
潜在的なアイテム
スプ
リン
トの
5-10%短
めで
(4h)プロダクトバックログリファインメント
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
プロダクトバックログリファインメントn実施内容l⼤きなプロダクトバックログアイテムの分割lプロダクトバックログアイテムの詳細化l⾒積もり
n同じ場所にいるのであればl同じ時間、1つの⼤きな部屋で実施するl各チーム別の壁を利⽤するなど
nいくつかのレベルで実施されるl全体的lチームレベルlマルチチーム
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
全体的なプロダクトバックログリファインメントn参加者:チーム毎に2名、プロダクトオーナーn次回実施するであろうプロダクトバックログアイテムの分割に集中するl軽量な分析l⾒積りØチーム間で共通した⾒積りのベースラインを確保するためにクロスチームで⾒積もる
l強い関連のあるプロダクトバックログアイテムの特定Ø共同での作業Ø共通的な作業の提案または調整
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
チームレベルのプロダクトバックログリファインメントnプロダクトバックログアイテムが1チームで完結している
n他のプロダクトバックログアイテムと強い関連が無い
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
マルチチームのプロダクトバックログリファインメントn参加者:全てのチームメンバーまたは、
チーム毎に2名(関連するチームのみ)n同じ時間、同じ場所で⾏うn共通のプロダクバックログアイテムまたは強い関連のあるプロダクバックログアイテムの連携強化
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
1.5h タイ
ムボ
ック
ス2h タ
イム
ボッ
クス
プロダクトオーナー
全体的なレトロスペクティブ
レトロスペクティブ
スプリントレビュー
スプリントレビュー〜レトロスペクティブ
1.5h
http://less.works/
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントレビューn参加者:各チームごとに2名+プロダクトオーナー+ステークホルダー
nスプリントレビューバザールl複数のエリアがある⼤きな部屋で実施lエリア毎にチームの代表が、そのチームによって開発されたフィーチャーをデモし、議論する
lステークホルダーは興味のあるエリアに訪れ、チームはフィードバックを記録する
n最初と最後は、全体的なフィードバックと整合性を⾼めるために、全員で議論する
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントレトロスペクティブn全てのチームを妨げている障害は、組織の改善バックログに挙げる
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
全体的なレトロスペクティブnタイムボックス:45分/1週間スプリントn参加者:各チームごとに1名+スクラムマスターn次のスプリントの最初の早い時期に開催nプロダクトや組織全体のための改善策の特定と改善計画を⾏う。
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS での作成物nプロダクトバックログnスプリントバックログn出荷可能なプロダクトのインクリメント
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
プロダクトバックログn1つのプロダクトバックログn良いプロダクトバックログは以下を備えている:l全て⾒積もられているl上位は粒度が細かく、下位は粒度が粗いl優先順位が付いている
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
スプリントバックログnプロダクトバックログアイテムから選択された、チームがこなす必要がある作業のリストである。
nチーム毎に存在する
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
出荷可能なプロダクトのインクリメントnスプリントのアウトプットn全てのチームの作業が統合されているn出荷可能lソフトウェアの市場性または価値ではないl技術的にプロダクトが出荷可能であり、現在実装したフィーチャーに必要な作業が完了している
n完成の定義に依存する
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
完成の定義nプロダクトバックログアイテムについて合意した、満たす基準の⼀覧lプロダクト全体のために、⼀つの完成の定義が共有される
lNot 受⼊基準Ø全てのプロダクトバックログアイテムに均⼀に適⽤される
n最初の完成の定義は、初期プロダクトバックログリファインメントで⾏われる
n各チームは、独⾃拡張した完成の定義を持つことができる
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
未完了作業(Undone Work)=出荷可能ー完成の定義l未完了作業が存在する場合は以下を決定しなくてはならな
いØどのように未完了作業を対処するのか?Øどのように将来的に未完了作業を少なくするための改善を
⾏うのか?lリスクと遅延を引き起こすØ遅延:未完了作業を⾏う⼿間が必要になる•プロダクトオーナーは、市場のニーズや変化に対応出来
ない→柔軟性の⽋如につながるØリスク:透明性の⽋如の原因となる•プロダクトのリリースに近くまで、⾏わないことのリス
ク(パフォーマンステスト等)
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSSまとめnガイドとルールのセットからなるlLeSS FrameworklLeSS Rules
n2つのスケーリングフレームワークが存在するlLeSS (2~8チームまで)lLeSS Huge (1プロダクトで数千⼈規模)
nLeSS = スケールしたScrum
基本的には1チームのスクラムと同じ
©2016 GaiaxCo.Ltd,. ©2016 Kanataku,LLC.
LeSS まとめn⼤規模であるがための⼯夫lチームの代表者が参加するイベントが存在するØ スプリントプランニング第1部Ø スプリントレビュー
lスクラムには無いイベントが定義されているØ 全体的なプロダクトバックログリファインメントØ 全体的なレトロスペクティブ
l協調と統合Ø オブザーブØ コミュニティと監視者(guardians)を構成するØ スクラムオブスクラムØ マルチチームのミーティングØ ボトルネックを活⽤し、壊し、スキルを⽣み出す
旅⾏者(経験豊富な技術の専⾨化)Ø 主導的なチーム
©2016 Kenji Morita
Nexus と LeSS の比較
©2016 Kenji Morita
共通点
l1つのプロダクトプロダクトバックログ
l1人のプロダクトオーナー
l無料(PDF, Webs)
l複数(〜8 or 9)のスクラムチーム
lスクラムチーム内はスクラムで
l代表者が集まって、バックログリファインメントを実施する。
lスクラムマスターは複数チーム兼務可能
©2016 Kenji Morita
特徴的な言葉(抜粋)
lNexus「スクラムフレームワークと同様に、Nexusの役割・作成物・イベント・ルールは不変である。Nexusの一部だけを導入することも可能だが、それはNexusではない。」
lLeSS「LeSSは、大きな複数チームやマルチサイト、あるいはオフショアのアジャイル開発を先導するのに上手くいくことが分かった追加のルールと秘訣のセットである。これらの秘訣は伝統的なスクラムのコンテクストにおける実験である 。」
©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/28/scaling-the-nexus-and-scrumbling/
Sprint Sprint Sprint SprintScrumble
http://less.works/less/structure/organizational-structure.html
(理想ではない)
©2016 Kenji Morita
LeSSに有ってNexusに無い物
lマネージャーの役割への言及
「中間管理職の役割は、全体を見て、素晴らしい製品を作れるよう組織の能力開発を行うことです。」
lビジネスパーソンの役割への言及
「製品開発におけるプロダクトオーナーは、ビジネス側から来るべきです。」
©2016 Kenji Morita
Nexusに有ってLeSSに無い物
l依存関係の最小化への強いこだわり•10Pで「依存関係」という言葉が35回!
•Nexus統合チーム
•Nexusスプリントバックログ
•毎日Nexus(代表者)デイリースクラム
•3パートのレトロスペクティブ
•リファインメントの目的も依存関係最小化
l最後はNexusを解消?
©2016 Kenji Morita
比較のまとめ
lNexus• ドキュメントが小さいので読みやすい。
• 理想的にチーム構成できる時にはシンプル。
• 依存関係の最小化と見える化にコストを使う。
• 大規模チームを分割する方向に向かいやすい。
lLeSS• 複数チームになってしまった時の改善策になる。
• よく起きる課題に対する現実的な解決策がある。
• マネージャー、ビジネスパーソンの役割がわかる。
• LeSS Huge(9チーム〜)も公開されている。
©2016 Kenji Morita
最後に
lチームが大きくなっても、変わらないマインドセットで、楽しくアジャイルに開発しましょう。
l今後事例を持ち寄ったり、知識の共有を進めていきましょう。
https://www.facebook.com/groups/ScaledScrum/
Top Related