複数のユーザー/ロールを持つユーザーストーリー
これがより一般的な問題だと思いましたが、解決策を提供するものを見つけるのに苦労しています。
現在、2人のユーザー/ロールを持つユーザーストーリーがあります。そのストーリーを分割するためのベストプラクティスソリューションがあるかどうか疑問に思っています。ユーザーストーリーの作成は科学ではなく芸術であることに注意してください。
シナリオ：-2つの外部ユーザータイプがあります-販売者と購入者。 -販売者と購入者の両方が、今後の展示会の詳細を表示したいと考えています（購入者が購入/調査したい、販売者が調査したいなど、さまざまな理由で-販売している場合、彼らはすでに展示会を知っています）。
現在のストーリー：AS売り手OR今後の展示会の詳細（場所/日付/時間）を表示したい買い手SO展示会に参加できること。
役割を一般化せずに、このためのユーザーストーリーを作成する方法はありますか。 「潜在的な展示会参加者」、または「ジョブストーリー」の作成「次の展覧会に行きたいときは、展覧会の場所/日付/時刻を確認したいSO展覧会に参加できます：このシナリオでは、最も単純な解決策は実際には同じです。公開サイトのどこかに今後の展示会をリストし、場所/日付/時間に関する詳細を提供します。
または、この特定のストーリーで特定された2つのユーザーロール（販売者と購入者）を一般化する必要がありますORバックログでユーザーストーリーとジョブストーリーの組み合わせを使用...
考え/コメント/提案？ :)
編集：私もユーザーストーリーの検索で同じ問題を抱えています...製品名で製品を検索できることに関連するユーザーストーリーがありますが、これは複数のユーザータイプ、つまり買い手と売り手に必要です。
あなたはすでにあなた自身の質問に答えたようです：
シナリオ：-2つのexternal userタイプがあります-販売者と購入者。
このことから、内部であると見なされる他の役割があると推測します（例：展示会のホスト、アプリケーション管理者など）。あなたは本質的に「外部ユーザータイプ」として購入者/販売者をリストしました。それが、彼らが他のユーザーの役割から分離するためです（私の推論に従って）。
私の推論が正しいと仮定すると、ここでの正しいアプローチは、「外部」および「内部」ユーザーロールを定義して（辞書がない場合はディクショナリに）、関連する場合はそれらを参照することです。
AS AN 外部ユーザー
今後の展覧会の詳細（場所/日付/時間）を表示したい
私は展覧会に参加できます。
アプローチを一般化するには：抽象概念（この場合は役割のグループ）を参照する必要がある場合は、抽象概念に名前を付けて、理解されることを心配せずに参照できるようにする必要があります。
暗黙的に理解させるための回り道を巧みに見つけようとするのではなく、それを単純に保ち、（概念を明示的に定義することにより）明確に理解させます。
ストーリーの分割方法は、ストーリーのサイズによって異なります。 2つの可能なオプションが表示されます。
最初のオプション、そして私が始めるところは、両方のユーザータイプを網羅する方法でストーリーを書くことです。たとえば、「展覧会の潜在的な参加者として、今後の展覧会のイベントの詳細を表示して、展覧会に参加できるようにしたい」とします。次に、受け入れ基準を使用して、潜在的な展示参加者が誰であるかを定義します。理想的には、特定のユーザーの役割またはペルソナにマップされます。受け入れ基準を使用して、場所と日時を明確にするために、イベントの詳細が何を意味するかを正確に特定します。これは私が最初にチームに提示するものです。
この改善に基づいて、チームは質問や懸念事項を考え出す場合があります。異なるユーザータイプの処理方法に多くの類似点がある場合は、ストーリーを分割しない方が理にかなっています。ただし、実行する必要のある独自の作業がある場合は、ユーザータイプまたはその他の方法で分割して、配信して確認できる小さなストーリーを作成する方が理にかなっている可能性があります。
フォーマットに関する限り、ユーザーストーリー、ジョブストーリー、ユースケースとしてニーズを表現することはそれほど重要ではありません。製品マネージャーまたは開発チームは、1つの形式が望ましいと考える場合があります。しかし、それはチームがユーザーのニーズを関係者全員に役立つ方法で表現することを確実にするための議論です。ただし、同じ考え方が当てはまります。チームは、ストーリーの評価に基づいて必要に応じて、ストーリーを分割するさまざまな方法を評価できます。
個々のケースでは答えが異なる可能性があるため、ユーザーストーリーの目的を見てみましょう。
ユーザーストーリーは、明確に引き渡され、それ以上の会話や説明の必要性を回避することを目的とした堅牢な仕様ドキュメントに対応して作成されました。代わりに、ユーザーストーリーは、チームとユーザー間の会話を容易にするために十分な情報を提供することを目的としていました。あなたの質問への答えは、「どのオプションがより良い会話を促進しますか？」です。
それがすべての参加者にまったく同じように当てはまる場合は、一般化することができます。あるいは、おそらく洗練の間、あなた、開発チーム、および利害関係者は、「ユーザーが買い手であるか売り手である場合、これはどのように違うのですか？」という質問をします。
最後にもう1つ、ユーザーストーリーには「As a、I want、So That」という形式は必要ありません。会話には別の形式が適していますか？
あなたのケースは、いくつかの役割が同じニーズを共有し、同じ機能を必要とすることです：
- 共通の関心事をカバーするより一般的な役割を使用する（利点は、一般化により広い意味で考えることを奨励し、他の関心のあるユーザー集団を特定できることです）
- または、質問で非常に実用的に行ったように、関連する役割を列挙します（具体的に残ることの利点は、明確に識別されたペルソナに頼ることができ、誰も実際に特定できない抽象的な役割を発明するリスクを冒さないことです）。
よりデリケートなケースは、同じ機能に対して異なるユーザーが異なるニーズを持っている（場合によっては競合する）場合です。実際には：
- ストーリーが補完的で矛盾しない場合は、他のストーリーと同様に処理します。2つの独立したストーリーをバックログに残してください（やがて機能の反復的な改良）。
- ストーリーが矛盾する場合は、ユーザーストーリーはディスカッションのプレースホルダーにすぎないことに注意してください。両当事者と（可能な限り）話し合うことで対立を解決し、共通の立場で合意します。最初のケースに戻ります。
- 重複がある場合は、それらをマージするか、上記と同じ手法を使用して独立させます。 1つのストーリーが実際のユーザーストーリーではなく、他のユーザーのストーリーがどうあるべきかについての希望である場合は、それを受け入れ基準にすることを検討してください。