Nexusは、Ken Schwaberフレームワークであり、大規模なマルチチームプロジェクト向けの古典的なスクラムの有機的かつ進化的な拡張です。 よく知られている同じスクラムベースに基づいています：役割、アーティファクト、イベント、依存関係を識別および管理するための同様のイベントおよびアーティファクトで補完し、チーム間で情報とドメイン知識をタイムリーに交換し、個々の増分ではなく最終製品に集中します。
役割
新しいものが標準スクラムロールに追加されます。NexusIntegration Teamは 、行われたすべての増分の成功した統合と、チーム間の技術的および非技術的制限の解決を担当します。
この参加者のグループは、チームの関心を表明する選択されたチーム代表者で構成されます。 参加者の勤務時間がNITと開発チームに分かれている場合、Nexus Integration Teamでの作業が優先されます。
統合チームの構成は、必要に応じて変更される場合があります。
イベント
マルチチームスクラムのつまずきのブロック-機能とチーム間の相互依存関係- 洗練セッションがプロセスに公式に追加され、その時間は厳密に設定されず、スプリントの都合の良いときに選択されます。
イベントはいくつかの段階で行われます。最初に、NITはバックログの内容を小さな独立した部分に分割し、1つのチームが1つのスプリントで機能を終了できるレベルにします。
次に、機能とチーム間のすべての依存関係が明らかにされ、視覚化されます。 この段階で、NITは機能と依存関係の特有の「ロードマップ」を定義します。どのチームがどのスプリントで行われるのか。
さらに、機能はチームのレベルまで下がり、同じアプローチを使用してより詳細にレビューされます。小さなパーツに分割し、依存関係を選択して視覚化します。
Nexusでの計画も次の手順で行います。
- すべてのチームが存在する初期段階で、プロダクトオーナーはスプリントの一般的な優先順位、一般的な増加の目標を表明し、説明します。 チームの担当者は、見つかった依存関係に基づいて作業の配分を再度調整します。 また、この段階で、スプリントの全体的な目標が定式化されます。
- その後、チームは個別に計画を継続し、すべてのチームの計画結果がNexus Sprintバックログに入力されます。
各チームのデイリースクラムに加えて、NITのデイリースクラムが追加され、残りの作業を一般的な増分で毎日再スケジュールします。
統合チーム向けの古典的な3つのスクラムの質問は、次のように変換されます。
- 今日のデイリースクラムの前に何がうまく統合されましたか？
- どのような新しい依存関係が発見されましたか？
- 今日、どのような情報をチーム間で配布する必要がありますか？
Nexusデイリースクラム中に取得した情報は、デイリースクラムチームでの議論に使用されます。
Nexus Retrospectiveは3つの部分で構成されています。
- NITは、複数のチームに影響する問題を特定し、それらをチームの回顧に追加の入力として渡します。
- 最初の段階で特定された一般的な問題を必ず考慮に入れるチーム回顧
- 共通のビジョンが形成される回顧展の最後の部分、定式化されたポイントを視覚化し追跡する方法。
Nexusのチームのスプリントの長さは異なる場合がありますが、一般的な計画、スプリントレビュー、および回顧で重複するために、複数（たとえば、1、2および4週間または1および3週間）でなければなりません。
アーティファクト
製品の全体像を見るために、 製品バックログは、増分と同様に常に単数形で保存されます。 Nexusにはチームスプリントレビューはありません。スプリントの結果は、チームによって行われたすべての合計-製品の統合インクリメントです。 Sprint Backlogに加えて、新しいアーティファクトが追加されました。NexusSprint Backlogは、指定された依存関係を持つすべてのチームの機能セットであり、一般的なスプリント計画の一種です。
完了の定義は NITによって形成され、各回顧の後に確認および維持されます。 チームはオプションで独自のDoDを作成できますが、ルールは一般的なものよりも厳密でなければなりません。
スケーリング
スケーリングは、単一のチーム内で適切に構成されたスクラムから始まります-同じ基本と経験がフラクタルにマルチチームレベルに移行されます。 徐々に、元のチームは2つまたは3つのチームに分割され、新しい開発者が反復的かつ段階的に追加されます。 全体的な増分が安定して予測可能なままになるように注意する必要があります。 そうでなければ、費やされる労力は比類なく高くなり、依存関係、統合、および通信の問題の複雑さは、次の各チームの追加とともに指数関数的に増大します。
ネクサスは、3〜9チームの単一の製品に取り組んでいます。 Nexus +もあります。これは、フレームワークの上にある次のレベルのアドオン（Nexus for Nexus）ですが、使用する前に3回検討する価値があります。 ある時点で、依存関係管理に費やす時間が、新しいチームを追加することの利点を上回ります。
単一ソース管理、継続的インテグレーション/ビルド/テスト/デプロイ、SOLID原則の使用、API、DevOpsコンセプトなど -スケーリングが大きいほど、使用する必要があるテクニックとアプローチの数が多くなります。
製品所有者は、製品のトップレベルのビジョン、戦略、優先順位付け、価値決定について責任を負います。 プロジェクトのサイズに関係なく、製品ごとに1つのバックログと1つのPOのみがあります。 彼または彼女は、日常のタスクでアシスタントを持つことができます。ストーリーの基準を説明し、チームに詳細を説明し、特定の分野の専門家から助けを求めます。 しかし、優先順位付けに関する最後の言葉は製品所有者にあります。