ソフトウェア開発におけるスクラムをスケーリングするためのNexus Framework

スクラムは、ソフ”チーム間の依存関係、複数のチームに影響を与えるリスク、配信のスケジュールに問題がある場合は、スケーリングフレームワークが必要な場合があります。

複数のスクラムチームをさまざまな方法で編成することができます。 この記事では、DevComの経験に基づいて、アジャイルとスクラムをスケーリングするためのNexusフレームワークについて詳しく説明します。 Less、SAFe、DAD(Disciplined Agile Delivery)など、アジャイルをスケーリングするための他のフレームワークがありますが、この記事では説明しません。

ネクサスフレームワークとは?

ネクサスフレームワークは、スクラムの共同作成者Ken Schwaberとによって設立されましたScrum.org 2015年には、幅広いアジャイルプロジェクトでスクラムをスケーリングするためのガイドとしてチーム。
スクラムが多くの組織の不可欠な部分となっているため、プロジェクトはスクラムで使用される典型的な毎日、計画、レビュー、およびレトロな会議セッ 複数のチームが製品で作業する場合、スクラムだけでは十分ではありません。 生産性は、チーム間の依存関係のために侵食されます。
Nexus frameworkはスクラムをビルディングブロックとして使用し、単一の製品で作業する複数のスクラムチームのより良い管理のためにそれを拡張します。 Nexusは3-9のスクラムグループに適用され、どのように協力しなければならないかを案内し、最小限の依存関係で各スプリントでソフトウェアを提供す

Nexus Frameworkはスクラムをどのようにスケールしますか?

スクラムは、プロセスを進化させるフレームワークです。 これは、単一のスクラムチームが単一の製品でどのように動作し、小さな単位でソフトウェアを提供するかに焦点を当てています。 Nexusフレームワークとスクラムの主な違いは、チーム間の依存関係を促進することに焦点を当てた統合チームの追加です。

スクラムフレームワーク

(ソース)

アジャイルスケーリングのためのネクサス

(ソース)

ネクサスプロセスフロー:

  1. プロダクトバックログを改良します。
  2. 開発作業。
  3. ネクサス毎日スクラム。
  4. ネクサススプリントレビュー。
  5. ネクサススプリント回顧。

ネクサスを実装した時点で、スクラムの基礎自体に大きな変更はありません。 Nexusは、ソフトウェア開発の取り組みを成功させるために必要な場合にのみ、スクラムに新しいプラクティス、追加の役割、イベント、成果物を追加する Nexusはスクラムを強化して、スクラムを効果的に拡張できるようにします。 これは、単一のプロダクトバックログから作業することによって、率直さと透明性を高めることによって達成されます。 重要なことは、すべてのスプリントで”完了”インクリメントを提供する責任があるスクラムチーム間の依存関係にもっと注意が払われることです。

“完了”の定義は、各スプリントで開発された統合インクリメントに適用できる厳格な基準であり、ネクサスのすべてのスクラムチームが続いています。

DevCom Nexusがスクラムをどのように拡張するか

Nexus Frameworkの実装

Nexus frameworkはスクラムの経験を前提としています。 すでにスクラムを使用している組織は、Nexusを簡単に実装できます。 Nexusを開始するには、まずNexus内のチーム、最初のNexus統合チーム、単一のプロダクトバックログ、”完了”の定義、スプリントケイデンスを識別する必要があります。

ネクサス実装戦略

スクラムチームを定義する(コンポーネントではなく機能に焦点を当てる)。 1.1. 会議を開催し、チームを形成する方法を定義する;
1.2.
1.3.チームメンバーの割り当て(理想的には自作チーム);1.3. 各チームの主要プレーヤー/代表者を定義します。
(クライアント(テナント)の数とアクセスレベルに基づいて)開発のための環境とレポを定義します。 2.1. 現在のreposのリストを作成する;
2.2. タスクのリードタイムを短縮するために、reposとレビュー環境を再編成する;
2.3. 共通のコードベースを1つ作成します(可能であれば);
ネクサス統合チーム(スクラムチームのメンバー。 Nexus Daily Scrumの結果として普及および解決される情報によって異なる場合があります)。 3.1. 主に統合と依存関係の解決を担当する人々を定義する;
3.2。 各チーム内でスクラムマスターの役割を割り当てます。
スクラム&ネクサスフレームワークを教え、説明します。 4.1. すべてのスクラムチームのための会議を開催し、基本を見直す;
4.2. 必要に応じて会議を容易にする。
作業するツールとその中で作業するツールを定義します。 5.1. 生産性とプロジェクト管理ツールを定義して、連携および統合(セットアップ)します。
“完了の定義”を定義します。 6.1.
6.2. 正式な文書を作成します。
プロダクト所有者(PO)または/および担当者を使用してプロダクトバックログを定義/プロダクトバックログを絞り込みます。 7.1. 上記のツールのいずれかを使用して機能要件を記録する;
7.2。 入力する必要なフィールド(名前、説明、受け入れ基準、制約など)を含むテンプレートを作成します。
製品所有者の承認を得る&彼女にバックログの優先順位を付けさせます。 8.1.
8.2. 製品バックログで作業するためのPOとの継続的なコラボレーション(テンプレート7.2を使用してストーリー、タスクを書きます)。
nitを整理して、相対ポイントを使用してバックログを推定します。 9.1. 見積もり技術を習得するために会議の最初の部分を開催します。
9.2. 会議の第二部を開催して、プロダクトバックログアイテム(Pbi)の大まかな見積もりを行います。
ネクサススプリント計画を実装します。 10.1.
10.2. 依存関係、表示される可能性のある統合の問題を定義します。
10.3。 定義されるスコープ:約少なくとも2つのスプリント前方および現在;
10.4。 チームのスプリント計画でNITメンバーを支援するための会議を開催します。
各スクラムチーム内でスプリント計画を実装します。 11.1. スプリント計画中にタスクとサブタスクに絶対推定値を使用する;
11.2. 各チームのスプリント計画を容易にする;
11.3. ドキュメントテンプレートを作成します。
各チームにNexus Daily ScrumとDaily Scrumを実装します。 12.1.
12.2. 時間を定義し、毎日のスクラムミーティングを容易にする(タイムボックスしておく)。
Nexus Sprintレビュー(最大4時間)を実装します。 13.1. スクラムチームメンバー、PO、その他の利害関係者とNexus Sprintレビュー(必要に応じてデモ録音を含む)を開催します。
各スクラムチームのNexus Sprintレトロスペクティブとレトロスペクティブミーティングを実装する(テンプレートの文書を作成する)(最大1時間と3時間)。 14.1. NITの回顧会議を開催する;
14.2. テンプレートドキュメントを作成する;
14.3. スクラムチームでのレトロスペクティブミーティングを容易にする。
14.4. テンプレート文書を作成します。
製品バックログに基づいてNexus Refinementイベントを定期的に実装します。 15.1. 頻度を定義します(必要に応じて頻繁に、例えば2t/週)。
ストーリーポイントで推定を実装する(POイニシアチブと予測意欲に応じて)。 16.1. スクラムチームの速度の追跡を開始(3スプリント後);
16.2. スプリントバーンダウンチャートを使用して進捗状況を追跡します。
タスク間の視覚的な依存関係とその予測を実装します。 17.1. ユーザーストーリー、タスク間の依存関係を視覚化する(フラグやリンクなど);
17.2. 現在のスプリントと2つのスプリントの依存関係を定義します。
プロジェクトを支援するためのプロジェクト管理活動を開始します。 18.1. 便利かもしれない文書を作成して下さい(例えばプロジェクト憲章、危険管理のマトリックス、Stakeholder管理、チーム管理(incl。 チームメンバー情報、ディスクテスト、モチベーションテスト、チームヘルスチェック));
18.2. プロジェクトKpiを定義し、それらを追跡するテンプレートを作成します。 通常、velocity、Sprint burndown、CSATが含まれます。 その他には、予算計算が含まれます。
18.3。 POおよび主要な利害関係者とのプロジェクトのヘルスチェックのレポートの定義;
18.4. デフォルトのフローに含まれていない場合は、タスクとフロー(手動、単体テスト、自動化)内のテスト戦略を確認します。
上記の手順を実施した後、より多くの価値を提供し、結果を最大化する戦略(未定)。 19.1. 主要な利害関係者との会合を開催する(PO、CEOその他);
19.2. ビジネス戦略に沿った要件を収集し、議論します。

Nexus Teams

Nexusは約3-9人のスクラムチームで構成され、各スクラムチームから1-2人のメンバーで構成され、製品全体のビジョンの計画とチームの調整を担当するNexus Integration Teamで構成されている。

実現可能性に基づいてチームを形成することをお勧めします。 機能チームは、任意のプロダクトバックログ項目で作業することができるので、最も理にかなっています。

しかし、現在のワークフローはコンポーネントチームに傾いているため、それらの間の依存関係が大きくなる可能性があります。 リスクを軽減するためには、コンポーネント以外に属するタスクをチームに委任することが有効なポイントです。 知識共有プロセスは、この場合には不可欠であり、統合する際の情報の不足を軽減します。

ネクサス統合チーム(NIT)は、以下のメンバーで構成されています:

  • ⇒ 製品所有者–製品の価値を最大化し、ネクサスによって完了した結合された作業が少なくともスプリントごとに一度は生産されることを保証するた
  • ⇒Scrum Master–スクラムチームがスクラムとネクサスを正しく行い、開発チームが提供する価値を最大化する責任があります。 潜在的にリリース可能な製品の”完了”増分を提供する責任があります。
  • ⇒開発チーム–”完了”された統合インクリメントを作成する責任があります。 Nitは、ネクサス内のスクラムチームが依存関係を検出するために必要なプラクティスを理解し、実装し、すべての成果物を”完了”の定義に頻繁に統合する”

Nexus統合チームの役割:

  • ⇒ Nexus統合チームは、”完了”の定義を確実にする責任があります。
  • ⇒統合インクリメント(ネクサスによって完了した結合作業)は、少なくともスプリントごとに一度生成されます。
  • †スクラムチームは”完了”を提供する責任があります。
  • nitはNexusの統合の焦点を提供します。 統合には、Nexusが常に統合された増分を提供する能力を妨げる可能性のある技術的および非技術的なチーム間の制約を解決することが含まれます。
  • ⇒Nexusが経験する障害に応じて、メンバーシップは時間の経過とともに変化する可能性があります。

チームメンバーは、各スプリントの最大結果を生成する必要があります。 ソフトウェアだけでなく、チームの定期的なヘルスチェックをお勧めします。 月に一度、各スクラムチーム内のチームの生産性を監視するための迅速なアンケートを開催することができます。

チームメンバーのための質問:

  • ⇒ 彼らは価値を提供していますか?<3915><275>*商品は発売しやすいですか?
  • ▼チームメンバーは楽しんでいますか?
  • ←製品は健康ですか?
  • ←それは持続可能でサポート可能ですか?
  • ←チームメンバーは学習していますか?
  • ⇒彼らは製品の目標を理解していますか?
  • ▼彼らはポーンや選手のように感じるのですか?
  • ⇒彼らは所有権を感じていますか?
  • ⇒彼らの速度は適切ですか?
  • 彼らは適切なプロセスを持っていると感じていますか?
  • ⇒彼らは支持されていると感じていますか?
  • ▼彼らはチームとしてうまく働いていますか?
  • ①会社は従業員の育成に貢献していますか?

DevCom Nexusチームのヘルスチェック

Nexusイベント

1.Refinement

Refinementは、スクラムチームが管理不能な依存関係を作成せずに作業をプルするのに十分な粒度のプロダクトバックログになります。 洗練の間、スクラムチームはこれらの質問に焦点を当てるべきです:

  • ⇒ 各チームはどのような仕事をしますか?
  • §リスクと複雑さを最小限に抑えながら、最大のビジネス価値を早期に提供するためには、その作業をどのような順序で行う必要がありますか?

Nexus Sprint Planning

Nexus Sprint Planningは以下のもので構成されています:

  • ⇒ プロダクトバックログの検証。 スクラムチームはPbiを見直し、Refinementイベントから作業に必要な調整を行います。 すべてのスクラムチームが参加し、コミュニケーションの問題を最小限に抑えるために貢献す; しかし、各スクラムチームの適切な代表者(Pbiの洗練に貢献できると感じる人)だけが出席する必要があります。
  • Nexusの目標は、複数のチームによるPbiの実装を通じて達成されるスプリントの目標です。
  • ⇒スクラムチームスプリント計画。 スプリントのネクサスの目標が理解されると、各スクラムチームは、メンバーが独自のスプリントバックログを作成する個々のスプリント計画イベントを 彼らは他のチームとの依存関係を特定するとき、それらのチームと協力して依存関係を最小限に抑えたり排除したりします。 ほとんどのスプリント計画は8時間かかるはずです。

場合によっては、チーム間の作業の順序を調整して、あるチームが別のチームが開始する前に作業を終了できるようにする必要があることを意味します。

Nexus Daily Scrum

Nexus Daily Scrum meetingは主な質問を網羅しています:

  • ⇒ 前の日の仕事は正常に統合されましたか、そうでない場合は、なぜですか?
  • ⇒新しい依存関係が特定されましたか?
  • ¶Nexus内のチーム間でどのような情報を共有する必要がありますか?

通常は同じ時間と場所で開催されます。

Nexus Sprint Review

Sprint Reviewには以下の要素が含まれています:

  • ⇒ 出席者には、スクラムチームとプロダクトオーナーが招待した主要な利害関係者が含まれます。
  • §プロダクトオーナーは、どのプロダクトバックログ項目が”完了”されたか、および”完了”されていないかについて説明します。;
  • †開発チームは、スプリント中に何がうまくいったか、どのような問題に遭遇したか、そしてそれらの問題がどのように解決されたかについて議論します。
  • †開発チームは、”行った”作業を示し、増分に関する質問に答えます。
  • †製品所有者は、現状のままのプロダクトバックログについて議論します。
  • †スプリントレビューが後続のスプリント計画に貴重なインプットを提供するように、グループ全体が次に何をすべきかについて協力します;
  • ►マーケットプレイスまたは製品の潜在的な使用が、次に行うべき最も価値のあるものをどのように変更したかのレビュー。
  • ►製品の機能または機能の次の予想されるリリースのためのタイムライン、予算、潜在的な機能、およびマーケットプレイスのレビュー。

スプリントレビューの結果は、次のスプリントの可能性のあるプロダクトバックログ項目を定義する改訂されたプロダクトバックログです。 製品バックログは、新しい機会を満たすために全体的に調整することもできます。

この活動は完了するまでに3時間以上かかるべきではありません。

ネクサス回顧会議

5.1. NITレトロスペクティブ

一般的なスケーリング機能不全があるため、すべてのレトロスペクティブは以下の質問に対処する必要があります。

  • ⇒ 彼らはネクサスの目標を満たしていますか? そうでない場合は、なぜですか?
  • ←元に戻す作業は残っていましたか? ネクサスは、技術的な負債を生成しましたか?
  • ⇒すべての成果物、特にコードは、頻繁に(理想的には連続的に)統合され、正常に統合されましたか?
  • ⇒未解決の依存関係が圧倒的に蓄積されるのを防ぐのに十分な頻度で、ソフトウェアの構築、テスト、およびデプロイが成功しましたか?

問題が発見されたとき、代表者は尋ねる必要があります:

  • ⇒ なぜこれが起こったのですか?
  • ▼問題を修正するにはどうすればよいですか?
  • ←再発を防ぐにはどうすればよいですか?

Nexus Retrospective meetingの後、すべてのスクラムチーム内で作業するアクション項目を定義することが重要です。 NITはそのような項目を追跡する必要があり、以下の表を使用することができます。

DevCom Nexusアクションアイテム

5.2. Scrum Teams Retrospective

各スクラムチームは、作業が必要な項目を視覚化するためにボードを使用することができます。 それに加えて、そのような記録を構造化された方法で正式に追跡することが推奨されます。 ほとんどの場合、スプリントがどのように行われたかをチームと話し合うのに4時間かかります。

Scrum teams Retrospective

プロダクトオーナー

プロダクトオーナーは、プロダクトの価値を最大化する責任があります。

プロダクトオーナーは、プロダクトバックログの管理を担当する唯一の人です。 プロダクトバックログ管理には、:

  • ⇒ プロダクトバックログ項目を明確に表現する;
  • ▪目標とミッションを最大限に達成するためにプロダクトバックログ内の項目を注文する;
  • ▪Nexusチー;
  • ▪スクラムチームがプロダクトバックログの項目を必要なレベルまで理解できるようにする。
  • ▪各スプリントのネクサス目標を定義する(milestoneと同様)。

製品所有者は、上記の作業を行うか、Nexusチームにそれを行わせることができます。 ただし、製品所有者は引き続き責任を負います。

主要な課題

  1. スケーリングされたアジャイルは動作し、スケーリングフレームワークを使用すると、迅速なスタートを得るのに役立ちます。
  2. スクラムのスケーリングは単なるスクラムです。 スクラムチームとしての働き方を変えたり、配信される作業を変えたりすることはありません。
  3. スクラムの上にNexusフレームワークを追加することにより、チーム間の依存関係に対処し、共通の目標と製品の増分に向かってすべてが協力していること
  4. スクラムを本当によく知っているなら、Nexusフレームワークはソフトウェア開発チームをスケーリングするための”非常に簡単な”フレームワークであり、他には何も必要ないかもしれません。
  5. Nexusは、すでに一緒に機能しているいくつかのスクラムチームを持っている人にとって便利な議論フレームワークです。
  6. あるいは、プロセスを説明したい場合は、Nexusフレームワークが良い出発点であるため、視点を逃さないでください。
  7. いつものように、アジャイルのスケーリングに関しては、次の三つの重要なことを覚えておいてください:
  • ⇒ 組織に合わせてメソッドを適応させます。
  • ←常に状況を反映しています。
  • ←あなたが一緒に働く方法を改善します。

あなたは”チームを超えて”技術のためのより多くの提案を持っていますか? これらのアイデアを実装する助けをしたいですか?

2000年以来、DevComは、クライアントの目標を達成するために、タイムリーで効果的で効率的なソリューションを作成するように設計された業界標準のアジャイル これらの方法論は、特定のフェーズで概説された目標を達成するために、全体的な努力が複数のリリースに分割される反復的な開発モデルを表します。 私達は開発のライフサイクルの3つの要素の多くの重点を置きました:最初のプロジェクトの査定および計画の質のプロジェクト管理、品質保証。

私たちの開発アプローチは、プロジェクトのリスクを軽減し、市場投入までの時間と予算を制御するために動作します。 私たちは、その経験と知識を新しいクライアントと共有し、スケーリング時に誰もが成功できるようにします。

チームワークによってよりよい結果を得なさい:DevComで私達に今日連絡しなさい!

コメントを残す

メールアドレスが公開されることはありません。