SprintレビューでUIのない​​ソフトウェアをどのようにデモしますか？

基本的にはスクラムに従って、アジャイルなソフトウェア開発を行っています。私たちはスプリントレビューを行おうとしていますが、難しいと感じています。私たちのソフトウェアは多くのデータ処理を行っており、ストーリーはしばしばこれに関するさまざまなルールを変更することについてです。

UIまたは目に見えるワークフローの変更がない場合にスプリントで発生した変更をデモするためのいくつかのオプションは何ですか？その代わり、変更は数十分または数時間かかることもある処理ジョブの微妙なビジネスルールです？

スプリント中に価値を生み出します。スプリントの開始時と終了時の違いは常にあります。通常は、クライアントが気づく方法でも。違いを示してください。

場合によっては、スプリントが微妙に聞こえるかもしれない発見または内部の再配置を扱いますが、それでも違いを示し、あなたがそれを良いと思う理由と、加えられたすべての努力の利点は何であるかを公衆に説明できなければなりません。（？コーナーケースでは、動作する電球を作ることが不可能である方法をいくつかの方法で最初に発見したエジソンを参照できます。）

実際の処理に時間がかかる場合は、タイムジップされたビデオまたは図表のみを表示しても問題ありません。または事前に収集された結果の出力。

私自身、バックエンド作業を行うものに対する個人的な好みは、エンドユーザーの変更を見つけることです。処理中のデータが最終的にレポートに表示される場合は、レポートで前/後の違いを示します。

私は変化の欲求が必要から来たと思います。ストーリーを実行する必要性を引き起こした問題は何でしたか？ユーザーストーリーの「ボイスフォーム」は、ストーリーのユーザーとして行動することによって問題をデモできる方法を示す必要があります（つまり、ジョアンとして、ヨーロッパにいるユーザーなしでレポートを表示する必要があります）。

さらに、この場合は、テストチームに支援を求めることができます。テストチームがストーリーが完了したことを確認できた方法があったはずです。彼らはどのようにこれをしましたか？そのプロセスをデモで示すことができますか？

機能が自分で機能していることをどのようにして確認しますか？展開するときに、実際に機能することをどのように確認しますか？

これらの質問に答えられない場合は、スプリントレビューよりも大きな問題があります。デモでそれを示すことができるはずです。

スクラムでは、デモ中にプロダクトオーナーが開発中の各ストーリーをレビューし、受け入れるか、開発に戻します。機能が動作していることを証明できる必要があります。これは通常、自動テストで行うのが最善です。受け入れテストに対応する自動テストを選び、主要な変更を強調できますか？

プロダクトオーナーも支援できる必要があります。開発中の製品を詳細に理解している必要があります。彼らは完全な実装の詳細を理解する必要はありませんが、各機能の目的（またはビジネス価値）の説明を理解できるように十分に理解する必要があります。結局のところ、プロダクトオーナーは、ストーリーを最初に実装するように依頼した人物です。

ビジネス（BSA、BA、マネージャーなど）にとって潜在的に満足のいくものだと思う1つのオプションは、何が期待され、何が達成されたかについて5〜10枚のスライドプレゼンテーションを提供することです。そして、データダンプやSQLクエリの結果など、行われた作業の結果とそれらをいくらか説明する時間を表示する意味のある方法があれば、多くの場合、関係者は満足することがわかります。

多くの場合、プログラマーや技術者ではないスタッフに、バックエンドタイプのシステムで意味のあるデモを提供することは困難です。私は上記を2、3回試しましたが、単にソフトウェアを実行して結果を示したときよりも、利害関係者の反応に満足していると感じています。

しかし、当然のことながら、これはあなたにとってその価値よりも多くの仕事かもしれません。メリットとそれを実現するために必要な作業を重み付けする必要があります。

パワーポイントまたはグラフィカルなものを使用して、変更を伝えることができます。たとえば、スプレッドシートのセルの値に依存する追加されたビジネスルールがある場合、それがどのセルであるかを示し、どのように変更されたかを説明できます。

バックエンドの変更がたくさんあり、UIが変更されていない場合は、それを説明するリストを参照して、全体的な変更を表示できます。違いを強調するチャートやグラフィックを作成できれば、それで十分かもしれません。スプリントで処理されたコードの変更または変更/コミットのリストをフラッシュします。

変更が「バックエンド」の場合、変更が現れる最終的なユーザーインターフェイスが存在する可能性があります。あなたはそれを示すことができます。私のチームはそのシステムを「所有」していないのでそうしたくありませんが、結局のところ、それが顧客が変更を操作する方法である場合は、そのUIに注意し、よく理解する必要があります。完成品を表示するのに十分です。