Nexusフレームワークについて簡単に調べてみた

RyuzeeさんのTwitterで、InfoQの『スクラムのためのNexus Guideを公開』という記事を教えてもらったので読んでみました。

Android開発の記事かな？と思ったら、『スクラムガイド』で有名なKen Schwaberさんによる、スクラムをより大きなプロダクト・チームで活用するためにスケールするための新しいフレームワークなんですね。

既に『Nexus Guide』を公開しているということだったので、実際に読んでみました。ちなみに『Nexus Guide』は、https://www.scrum.org/の右下の「HOW DO YOU SCALE SCRUM?」をクリックすると閲覧することができます。

ポイント

基本は、スクラムをベースとしたフレームワークです。但し、以下の点に特徴があります。

• 3-9チームで、1つのプロダクト／ソフトウェアを開発するケースを想定しています。
• 1スプリント毎に、各チームの成果物（ソフトウェア）を統合します。
  • これを実現するために、「自動化」の必要性が言及されています。

複数チームで１つのものを作るので、以下のものを各チーム間で調整・統合する必要が出てきます。

• 要求（requirements）
• ドメイン知識（domain knowledge）
• ソフトウェア・テスト成果物（software/test artifacts）

これらを調整するために、既存のスクラムの上に以下の「調整・統合の場」的なイベントと、「Nexus Integration Team」という調整チーム（スクラムチームとは別）とを設けています。

• Nexus Sprint Planning（各チームで行うものとは別に行う）
• Nexus Daily Scrum（各チームで行うものとは別に行う）
• Nexus Sprint Review（全チームで一緒に行う）
• Nexus Sprint Retrospective（各チームで行うものとは別に行う）
  • 次のトライをどう「見える化」してトラックするか（≒メトリクスを取るか）といったことにも言及されています。
• Refinement

依存を如何に扱うか？

3-9チームで1つのプロダクト／ソフトウェアを開発し、スプリント毎に統合するため、各チーム間での依存関係をどう扱うかが鍵になります。依存関係の解決方法として、次の3つが言及されています。

• 依存を洗練する
• 依存を取り除く
• 依存を極小化する

スクラム色が濃い

以下の点は、スクラムの影響が濃い、もしくは同一だと言えそうです。

• Transparency（透明性）
• Inspection（検査）
• Adaptation（適応）
• Definition of Done(DoD)

「スケール」という次のメインテーマ

Nexusの他にも、近年スクラムをスケールするためのフレームワークや方法論が多く提唱されるようになってきました。

• SAFe (Scaled Agile Framework)
• Disciplined Agile (DAD)
• LeSS (Large Scale Scrum)

いよいよ、「スケール」について広く真剣に考える時が来たのかも知れませんね。