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

アジャイル宣言

百聞は一見に如かず。

ことわざ

チームデモの概要

人はストーリーやフィーチャーを見えて、触れるまでに、ストーリーやフィーチャーはただの抽象概念である。従って、動作する、テスト済みのソフトウェアを顧客(あるいは顧客の代理)へデモすることは具体的な、独創性に富んだ瞬間である。この活動は2週間ごとに繰り返し実施される。SAFeではチームデモシステムデモという2つのデモが必要となる。

  • チームデモ:従来のスクラムによって定義された儀式(ビジネス利害関係者はシステムデモにより適しているので、参加者は若干違うかもしれない)である。
  • システムデモ:システムデモはSAFe独自なものである。システムデモによって、プログラムにおけるすべてのチームから納品されたすべての新しいソフトウェアの集約されたビューを提供する。通常、システムチームがシステムデモを主催し、プロダクトオーナーやプロダクト管理がビジネス利害関係者向けに説明する。

このページはチームデモについて説明する。効果的なデモ計画と発表はチームにいくつかの作業が必要となるが、デモがなければ、正しい機会に辿り着けるために必要な迅速のフィードバックをもらえないだろう。

詳細

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

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

図1に示したように、スプリントの時間枠(タイムボックス)の終了時に、チームデモは行われる。

teamDemoFig1

目的

該当する開発チーム、プロダクトオーナー及び他の利害関係者に動作するソフトウェアを披露することによって、チームの進捗を測定することがチームデモの目的である。このフィードバックは、1-2時間の新機能のデモによって構成される。スプリントが計画される時からデモの準備は開始する - チームはスプリント計画中に、ストーリーのデモ方法について考え始める。チームはすべてのストーリー、スパイクリファクタリング作業と新しい非機能要求(NFR)をデモすべきである。目的を持って始めることは、スプリント計画を大いに促進し、最終的に、成功するデモをサポートするためにどのようにストーリーを完了させるべきかという考えを促進する。

プロセス

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

図2. チームデモ時に、動作するテスト済みのソフトウェアを披露する

 

チームが前スプリントの作業の状況を示す以外に、PI目標に向けた進み具合も振り返る。デモ後に、振り返りを行う。

参加者

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

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

アジェンダー

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

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

ガイドライン

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

  • チームメンバーによるチームデモに関する準備時間は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: 14 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.