以下は、実際のプロジェクトの経験です。 主な問題を検討し、スプリント結果の効果的な準備と成功したデモンストレーションの側面に焦点を当てます。
プロジェクトの概要
チームは、会社全体で使用される主要な製品を開発しています。 彼はモスクワに10人以上の主要な利害関係者を持ち、世界中に10人以上います。 それらの半数以上はトップマネジメント（非常に忙しい人々）です。 プロダクトオーナー、チームリーダー、アナリストはモスクワにいます。 スクラムマスターと開発チーム（約15人）はドネプロペトロフスクにいます。
どうでしたか
だから、最も簡単な方法は、みんなに来て見てもらうことです。 そして、チームはこのようにして行きました。
しかし、次のことが起こりました。
会議は15〜20分の遅延で始まりました
•チームはすべての招待者を待っていました
•チームは会議の開始時にトレーニングを開始しました：WebEx、音声会議、システムへの接続など。
•マイクが機能しないか、うまく機能しませんでした。
デモのカオス
•デモセッションの開始時刻と終了時刻を全員が理解していない
•明確な実証計画の欠如
•デモセッションリーダーの不足
•デモの範囲外で長時間の議論を開始
•この会議の意味を完全に理解した人はいなかった
モスクワからの参加者のみが積極的に参加しました
•他の場所の人々は議論を聞かず、会議の他の参加者とコミュニケーションを取ることができませんでした
明快さと透明性の欠如
•参加者は何が示されているのか理解できなかった
•参加者はプロジェクトの完全なステータスを理解していませんでした
•参加者は多数の複雑で不明瞭なスライドを受け取りました
無効なユーザーストーリー
•部品を実証できませんでした
•テストデータの使用：「12345」、「qwerty」、「test surname_1」。 参加者は、これが実際にどのように機能するかを理解していませんでした。
•ユーザーストーリーの実際の量は不明でした。 この物語が完成したかどうかを理解することは困難でした。
•実装を選択した理由は明確ではありませんでした
技術的なストーリーは完全に非技術的な人々に示されました 。 多数の技術的な詳細は、このような対象者には受け入れられませんでした。
忘れられたアクションアイテム 。 会議後に失われた、または誤解された多くのポイントがありました。
助けた解決策と方法
だから、誰もがこの会議が効果的ではなかったことを理解しています。 状況を改善するのにどのような方法が役立ちましたか：
定期的な予定を作成します 。 Outlookで繰り返し会議を作成しました。すべての参加者は、次のデモがいつどこで行われるかを常に知っていました。 これにより、すべての参加者が事前にスケジュールを計画できました。
スケジュールの準備。 これで、デモの実施を担当するすべての人に準備する時間がありました（オーディオ/ビデオ会議の開始、接続の確認、会議室の空き状況など）。 これらすべてが行われたので、関係者が会議に来たとき、すべての準備が整い、開始できました。
開始の条件を決定します 。 主要な参加者（2〜3人）がいるときにデモを開始することにしました。 関心のあるすべての関係者は、主要な参加者が来たときに正確に開始し、これ以上の遅延がないことを知っています。
厳格な会議の議題 。 アジェンダに従ってデモが続きます。 アジェンダは、各会議の前にスケジュールされ、思い出されます。 これで、このアイテムまたはそのアイテムがいつ議論されるかがわかり、混doとした議論は発生しません。
労働協約 。 これは、会議の有効性を維持し、会議の目標を達成することに集中するためのツールです。 作業契約は、各デモのマーカーボードに記載されています。 デモリーダーは、ディスカッション管理ツールとしてそれらを使用できます。
「駐車場」 。 議論が議題の範囲を超えたり、時間がかかりすぎたりすると、デモのリーダーはアクションアイテムとして「駐車場」に入れます。 会議中に発生したすべてのアクションアイテムもそこに配置されます。
配布資料 。 全員がプレゼンテーションのスライドを見て、自分でメモを取ることができるように、カラフルな配布資料を印刷しました。 また、プロジェクタがプレゼンテーションだけでなく、動作中のアプリケーションを表示するのにも役立ちます。
アジャイルチャート 。 すべてのスライドをリリースまたはスプリントステータスに変更しました。 以前は「クラシックアプローチ」を使用していましたが、より「アジャイル」にしました。 これにより、進捗状況に対する理解が深まりました。
それは：
次のようになりました：
デモリーダー 。 デモリーダーの役割を紹介しました。 これは、デモを実行し、他の人に投票権を与え、時間、議題を追跡し、デモを管理するためのツールとして作業契約を使用する会議室の1人のプレゼンターのみです。 これで誰がリーダーであり、誰が会議を管理する権利を持っているかがわかります。
別の場所のアシスタント 。 ドネプロペトロフスクのチームメンバーの1人をデモリーダーのアシスタントにしました。 アシスタントは、画面に表示されるすべてを制御し、チームメンバーをディスカッションに接続できます。 また、アシスタントはアクションアイテムを駐車場に手動で追加して、すべてが正しく書き込まれ、正しく書き込まれていることをリアルタイムで確認できるようにします。
ビデオブリッジ 。 退屈で非効率的な音声会議を拒否し、ビデオブリッジを導入しました。 プレゼンテーションとアプリケーションは、プロジェクターを使用して示されました。 現在、利害関係者とチームメンバーは、アプリケーションを見てプレゼンテーションを聞くだけでなく、お互いに会ったときに効果的にコミュニケーションをとることができます。
技術的なストーリーを削除します。 デモ記事から技術的なストーリーを削除しました。それらは関係者にとって興味深くなく、誤解を招く可能性があるためです。 ただし、それらを表示したいすべての人（たとえば、利害関係者の中に技術者がいる場合）には、デモの直後に表示のための時間間隔が割り当てられます。
疑問符 。 疑問符は、デモを停止するための非常に高速で効果的なメカニズムです。 これは、話している人を別の場所から中断しようとするよりもうまく機能します。
別の会議でカスタムストーリーを受け取ります 。 デモの前に、ストーリーを受け入れるための別の会議を行いました（製品所有者によって定義された受け入れ基準を使用）。 詳細な受け入れプロセスは、関係者にとって興味深いものではありません。彼らは、各ストーリーを詳細に示すことに興味がありません。 そのため、デモでは、製品所有者が受け入れたユーザーストーリーのみを表示し、フィードバックを収集します。
高速フィードバック 。 デモ後の関係者に、デモの構成（良い点と悪い点）について迅速なフィードバックをお願いします。 これにより、デモの品質を継続的に改善できます。
回顧的デモ 。 各デモの後に短いフラッシュバックがあります。 これは弱点の改善に役立ちます。
以上です。 魔法、ロケット科学、複雑なソリューションはありません。これは、チームがデモの実施においてより効果的になり、顧客を満足させるのに役立つ一連のシンプルだが強力な方法です。
これは、デモで改善できるものの完全なリストではありません。 なぜアジャイルにデモがあるのか、それを効果的に行う方法など、 トレーニングで詳細を明らかにしています。
デモはどのように行いますか？