Nexusの概要

Scrumを大規模に適用するためのフレームワークであるNexusの概要

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. Nexusの概要 2016/11/25 Ryuzee.com
2. 概要 ✤ Nexusは3∼9個のスクラムチームのためのフレームワーク ✤ Nexus は、役割・イベント・作成物と、スクラムチームの作業をまとめる技法で構成さ れたフレームワーク ✤ 複数のスクラムチームが、ゴールを達成するインクリメント(出荷可能な製品の増分)を構 築するために、1つのプロダクトバックログに取り組む ✤ 開発はスクラムの父の一人Ken Schwaberと彼自身の会社scrum.org
3. 全体像 Nexusガイド日本語版より https://www.scrum.org/Resources/The-Nexus-Guide
4. 背景 ✤ ✤ 複数チームで協力してスプリントごとに統合済みの製品を作ろうとした場合、それぞれの 作業で多くの依存関係が生まれる。これは以下の影響 ✤ 要求のスコープの重なりや実装方法の相互影響。プロダクトバックログから項目を 選択する際にこれらを考慮する必要 ✤ ドメイン知識が欠如していると進まないので、適切な知識を持つ人をスクラムチー ムに適切に配置しないといけない ✤ 要求はソフトウェアとテストコードで表現される 上記が各チームで っていれば依存関係が減る
5. Nexusの体制 ✤ Nexusは約3∼9のスクラムチームと、Nexus統合チームから構成される
6. Nexus統合チーム ✤ プロダクトオーナー、スクラムマスター、1人以上のNexus統合チームメンバーから構成 ✤ それぞれのチームによって最高の成果を出せるようにNexusの適用、スクラムの運用、 コーチ、コンサルティング、監督、バックログに関する作業等を行う ✤ 成果物を結合したインクリメントをスプリントごとに作成する最終的な責任 ✤ チーム間の技術的・非技術的制約を解消する責任 ✤ 統合チームのメンバーは必要なときに個々のスクラムチームで働くこともあるが、第一は このチームのために働く
7. Nexus統合チーム内のロール (1) ✤ Nexus統合チームのプロダクトオーナー ✤ ✤ 全体で1つあるプロダクトバックログの最終責任者。並び順やリファインメントに 関する最終責任を持つ(スクラムのプロダクトオーナーと同じ) Nexus統合チームのスクラムマスター ✤ Nexusフレームワークが理解され実施されることに対する実行責任
8. Nexus統合チーム内のロール (2) ✤ Nexus統合チームのメンバー ✤ 大規模で必要となるツールやプラクティスに精通した人たちで構成 ✤ これらのツールやプラクティスを各チームに確実に実行させる ✤ 品質を維持するために、組織で求められる開発・インフラ・アーキ テクチャ標準の コーチングを行う ✤ 各チームの成果物を頻繁に統合する ✤ 上記の条件が満たせる場合は他のチームのメンバーになってもよい
9. それぞれのスクラムチーム ✤ 既存のスクラムと変わらない ✤ スクラムマスターと開発チームのメンバーがいる (プロダクトオーナーはNexus統合チー ムに所属している) ✤ Nexusチームのスクラムマスターが1つ以上の個別チームのスクラムマスターを兼任する こともある ✤ クロスファンクショナルであることが求められる ✤ 作業の依存関係を解決するために、チームが適切なメンバーを選択して作業を行うことも ある
10. 技術プラクティス ✤ 大規模の場合はとくに統合に問題を抱えることが多い ✤ そのために自動化を活用する必要がある ✤ 自動化することで作業や作成物のボリュームや複雑さを管理しやすくする ✤ 自動化はスクラムでは定義されていないが、Nexusでは必要な技術プラクティスとして定 義している（定義されているか否かに係わらず大規模では自動化が必須であることには変 わりない） ✤ 当然ながら成果物は完了(完成)の定義を満たしていないといけない
11. Nexusスプリントプランニング(計画) ✤ 全体的な役目は通常のスクラムと同じでスプリントを開始する前に実施 ✤ プロダクトオーナーはドメイン知識の提供や、項目の選択や優先順位付けを指導する ✤ リファインメント済みのプロダクトバックログの順番を、それぞれのスクラムチームの代 表者が確認。ただしコミュニケーションの問題を起こさないために全チームメンバーが参 加する ✤ その後担当項目が決まれば、各チームでスプリントプランニングを実施する。複数チーム が同じ場所でやると問題を見つけられる ✤ 新しい依存関係が見つかった場合は複数チーム間の作業順序を調整する。ただし通常の スクラムと同じくプロダクトバックログ項目間の依存関係は最小に保つ
12. Nexusデイリースクラム ✤ それぞれのチームの適切な代表者が集まって、現在の統合状態を検査したり問題を確認し たり依存関係を確認する ✤ ここでの議題は「統合」に絞られる。3つの質問は以下のようになる ✤ ✤ 昨日はうまく統合できたか、できてなければなぜか？ ✤ 新たな依存関係は何か？ ✤ それぞれのチーム間で共有すべき情報は？ ここででた作業などは個別のスクラムチームのデイリースクラムで共有し計画・対処して いく
13. Nexusスプリントレビュー ✤ このスプリントで統合して完成したプロダクトバックログ項目をレビューしフィードバッ クを受ける（通常のスクラムと同じ） ✤ 製品全体に対するフィードバックを受ける ✤ すべてを詳細に見せることは不可能かもしれないのでやり方に工夫は必要
14. Nexusスプリントレトロスペクティブ(ふりかえり) ✤ 3つのパートから構成される ✤ 第一部：Nexusの適切な代表者が集まり、1つ以上のチームに影響のある問題を特定す る。これにより共通の問題をそれぞれのスクラムチームに共有する ✤ 第二部：それぞれのスクラムチームでのレトロスペクティブを実施。これは通常のスクラ ムと同じ。議論のインプットに第一部の内容を使い、これらの問題に対処するアクショ ンを作る ✤ 第三部：スクラムチームの代表者が集まり、アクションをどう見える化して追跡するかに 合意する
15. レトロスペクティブの話題 ✤ スケールすると機能不全がおこりやすいので以下の議題を扱う ✤ 完成していないものはあるか？技術的負債を作っていないか ✤ コードや作成物は頻繁に統合されているか ✤ 未解決の依存関係が増えない程度に頻繁にビルド・テスト・デプロイされているか ✤ なぜこのようなことが起きたのか？ ✤ どのように技術的負債を解消するのか？ ✤ どのように再発防止するのか？
16. リファインメント ✤ それぞれのチームの依存関係を極力減らすようにプロダクトバックログを手入れする ✤ プロダクトバックログは十分に分解されていないといけない ✤ どのチームがどのプロダクトバックログ項目を作るか予測できるようにする ✤ 依存関係を特定し見える化することで、依存関係の最小化と監視ができるようにする ✤ 普通のスクラムと同じ

Comment

No comments...