Team Demo

動くソフトウェアこそが進捗の最も重要な尺度です。

– アジャイル宣言

百聞は一見に如かず。

– ことわざ

チームデモの概要

人はストーリーやフィーチャーを見えて、触れるまでに、ストーリーやフィーチャーはただの抽象概念である。従って、動作する、テスト済みのシステムを顧客(あるいは顧客の代理)へデモすることは、具体的な、独創性に富んだ瞬間である。そのため、ソリューションのスコープによるが、SAFeでは、ソリューションデモ、システムデモ、とチームデモという3つのデモが必要となる。システムデモはアジャイルリリース列車(ART)におけるすべてのチームから納品された新しいシステムの集約されたビューを提供する。ソリューションデモは主に価値のストリームの進捗を測定するために用いる。

このページはチームデモについて説明する。チームデモは従来スクラムで規定されたイベントであり、そこで、チームは反復の結果であるインクリメントをレビューする。一部のカンバンチームもチームデモを行う。効果的なデモ計画と発表はチームにいくつかの作業が必要となるが、デモがなければ、正しい機会に辿り着けるために必要な迅速のフィードバックをもらえないだろう。

詳細

これらのチームデモの重要性は見くびれない - スポンサーと顧客から即時に、文脈上のフィードバックを収集できる唯一の方法である。そのため、デモは重要な3つの機能を持つ:

  • 1つの反復の時間枠の区切りとなる。その時間枠中に、多くの役割はビジネスに新しい価値を貢献してきた。
  • チームに、ビジネスに対する貢献を披露する機会を与え、作業と進捗に関する満足度とプライドを高める。
  • 顧客と利害関係者が動作するフィーチャーを確認することができ、フィードバックを提供することができる。

目的

プロダクトオーナー及び他の利害関係者に動作するソフトウェアを披露することによって、チームの進捗を測定し、フィードバックを得ることがチームデモの目的である。このデモはは、1-2時間の新機能のデモによって構成される。デモの準備は反復計画時から開始する。そこで、チームは確約するストーリーのデモ方法について考え始める。チームはすべてのストーリースパイクリファクタリング作業と新しい非機能要求(NFR)をデモできなければならない。
この「念頭において」から始めることは、ベクトル合わせと反復計画を容易にし、必要な機能性へのより完全な理解を促す。

プロセス

反復ゴールに対する素早いレビューで、デモが始まる。その後、確約されたストーリーを確認する。各完了したストーリーは動作するテスト済みのシステムで示される。スパイクは調査結果に対するプレゼンテーションによって示される。
完了したすべてのストーリーが示された後、チームはどのストーリーが未完了、もしあれば、チームが完了できなかった理由について振り返りする。一般的に、この議論を通じ、リスクや障害、間違った仮説、優先順位の変更、見積もりの不正確さ、また確約しすぎることを発見する。これらの発見は、次の反復のためにより良い計画と実行の方法に関する反復振り返りでのさらなる議論につながることがある。図1は進行中のチームデモを示す

図1. チームデモ時に、動作するテスト済みのシステムを披露する

チームが前反復での作業の状況を示す以外に、PI目標に向けた進み具合も振り返る。

参加者

チームデモの参加者は以下でする。

  • プロダクトオーナーとスクラムマスターを含むアジャイルチーム
  • 反復に関わる他のARTの利害関係者や共有サービス
  • ビジネス責任者、経営スポンサー、顧客及びほかのチームのメンバーも参加可能が、彼らの関心事と詳細レベルは通常システムデモともっと一致している。また、チームデモは彼らにとっては細かすぎる詳細であるため、彼らは注意を保持できない可能性があり、「デモ疲れ」が発生する可能性がある

アジェンダー

チームデモのアジェンダーのサンプルは以下に示す

  • 反復のビジネス背景と反復ゴールをレビューする
  • 各ストーリー、スパイク、リファクタリング作業、適用した非機能要求をデモする。フィードバックを収集する
  • どのストーリーが完了されないか、またその理由に関して議論する(理由に対する回答は次の反復計画に情報を与える可能性がある)
  • 現反復中やデモ時に表したかもしれない在新しいリスクや障害を識別する

ガイドライン

以下はデモの開催を成功させるためのヒントである。

  • チームメンバーによるストーリーデモに関する準備時間は1-2時間以内に制限する
  • このミーティングは1-2時間の時間枠を設定する
  • PPTスライド数を最小限にする
  • 完了したストーリーの動作するテスト済みのシステムだけをデモする(完了の定義をリリースページをご参考)
  • 主要な利害関係者は参加できない場合、プロダクトオーナーは進捗報告とフィードバックをもらうため、単独的にフォローなければならない

さらに知りたい場合

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

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

Last update: 18 October 2015

The information on this page is © 2010-2017 Scaled Agile, Inc. 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. Please contact us for permissions.