テストしない限り、何も動かない …

- SAFeの仮説

システムデモの概要

SAFeでは、動作するソフトウェアシステムを2週間ごとにデモすることが進捗の主要な基準である。SAFeは大規模アジャイルを実装するため、各反復終了時にチームデモとシステムデモという2つのデモを実施しなければならない。チームデモは従来のスクラムで定義された儀式で、スプリントレビューと呼ばれている。システムデモはビジネス利害関係者のためのプログラムレベルのレビューである。

システムデモは、アジャイルリリース列車のすべてのチームが最も近い反復内で提供したすべての新しいソフトウェアの統合され集約されたビューを提供する。このデモの重要性は軽視することができない。スポンサー(作業の費用を支払う人々)と顧客(作業を利用する人々)から迅速にシステムレベルのフィードバックを集める手段だからである。システムデモを効果的に計画し実施するには、チームの一部がいくつかの作業を行わなければならないが、それが正しいソリューションの構築に必要な迅速なフィードバックを得られる唯一の方法である。

詳細

図1に示すような各スプリントで開催するシステムデモを行うには、プログラムチーム間の結合と同期を強化するためのスケールアップエンジニアリングプラクティスが必要である。システムデモは、アジャイルリリース列車にとって、プログラムインクリメント内の現在の進捗を事実に基づいて測定する手段となる。そしてこれは、チームやプログラムのベロシティーに関する唯一真の測定手段でもある。

Figure 1. The System Demo provides the real measure of progress and spurs valuable feedback

図 1. システムデモは進捗に関する真の測定手段となり、価値のあるフィードバックを加速させる

目的

システムデモの目的は、ビジネス責任者、経営スポンサー、開発管理、顧客または顧客の代理を含む主要な利害関係者から、開発中のシステムの有効性およびユーザビリティに関するフィードバックを得ることである(図2)。列車が軌道から外れないようにしたり是正措置を取るために必要なフィードバックを提供することができるのは彼らだけなので、このデモは彼らによって彼らのために行われる。

図2. システムデモ

 

タイミング面から見ると、システムデモは反復の終了にできるだけ近い時点で開催する。理想的には翌日である。しかし、以下のような複雑な事情によりそれが現実的でない可能性がある。

  • 通常、全般的な結合の結果が反復の終了時にしか利用できない(もちろん全段階を通じ継続的なインテグレーションを行うよう努力するが、常に実施可能ではない。特にアジャイル導入の初期段階の場合はそうである)。
  • さらに、新しいインクリメントごとに、デモ環境、新しいインタフェース、サードパーティコンポーネント、シミュレーションツールなどを拡張する必要があるかもしれない。もちろん、システムチームアジャイルチームはそのための計画を立てることができるが、いくつかの項目が後で出てくることは避けられない。

しかし、最悪の場合、システムデモは次の反復内で行わなければならない。システムデモを実施しないと、チームへのフィードバックは遅くなり、プログラムインクリメントを危険にさらす可能性がある。

プロセスとアジェンダ

システムデモのミーティングの流れを以下のサンプルに示す。

  • チームのスプリントのビジネス背景とゴールを簡単に確認する(5~10分)
  • これからデモする新しいフィーチャーや性能のそれぞれを簡単に説明する(5分)
  • 個々の新しいフィーチャーとエンドツーエンドのユースケースをデモする(20~30分)
  • 質疑とコメントを受け付ける
  • デモおよび前のスプリントの進捗によって浮かび上がる新しいリスクと妨害事項を識別する
  • 進捗状況、フィードバックとアクション項目をまとめて終了する

参加者

通常、以下の参加者を含む。

ガイドライン

以下にシステムデモを成功させるために役に立つヒントを示す。

  • デモは1時間の時間枠にする。これは主要な利害関係者に2週間ごとに継続的に参加してもらうためには非常に重要である。また、チームのプロ意識やソリューションの準備状況も明らかになる。
  • デモする新しいフィーチャーを持つプロダクト管理者やプロダクトオーナー間でデモの責任を共有する。
  • PowerPointのスライド数は最小限にする。完了したフィーチャーとストーリーの、動作するテスト済みのコードのみをデモする。
  • 現在のインクリメントがシステムのNFRに及ぼす影響を話し合う。

さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. 第9章(邦訳:Dean Leffingwell、アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. 第15章(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)
 

Last update: 22 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.