ユーザーストーリーは、伝統的に「[ユーザータイプ]として[機能]が欲しい[いくつかの利点]」という表現として書かれています。書籍やオンラインリソースでは、[ユーザータイプ]は通常、人間の役割に対応しています。ただし、システム内部の機能を説明する場合、ユーザーの代わりに無人サービスを配置する方が簡単な場合がよくあります。たとえば、「ServiceXとして、最新の情報を使用してXYZを実行できるようにデータを定期的に更新したい」などです。
このようなフォームを使用すると、システムの関連部分について、わかりやすい受け入れテストを簡単に作成できます。しかし、これは概念的に正しいのでしょうか？ユーザーストーリーはビジネス価値を与える機能に基づくべきではなく、システムやサービスはビジネス価値の獲得に関心がないため、ユーザーストーリーのアクターであってはなりませんか？
俳優が人間でなければならない理由がわかりません。あなたの例は、人間でなければならない完全な理由です。
このような方法論では、定義されたプラクティスの細部に固執することに夢中にならないようにする必要があります。もともと「ユーザーストーリー」のコンセプトを思いついた人が、人間にしか当てはまらないと思っていたとしても、そのコンセプトに固執することを強制する法律はありません。
ユーザーストーリー、アジャイル、スクラム、およびその他すべての方法論の要点は、開発プロセスではなく、開発プロセスを支援することです。方法論は、プロセスを改善する場合にのみ価値があるため、そのように使用する必要があります。独自の状況に合わせて方法論を自由に適応させる必要があります。方法論が実際のコード開発よりも重要にならないようにしてください。
システムは間違いなくビジネス価値の獲得に関心を持っています。アクターは、サードパーティによって作成され、そのサードパーティの意図を具体化する自動化されたエージェントである可能性があります。実際、これは、Webサービスが主要なWebサイトでより一般的な機能になり、ユーザーに代わって複雑なサイト間対話を可能にするが、マシンのみが関与するようになるにつれて、対話の主要な形式になりつつあります。
これが秘密です。それらはユーザー ストーリーではありませんが、ユーザー シナリオです。
ユーザーとは、相互作用を行うもの、つまり機械または人です。
利害関係者は、相互作用から利益を得ている個人または企業です( AI 開発のこの段階では決して機械ではありません)。通常、特定のプロジェクトには競合するニーズを持つ複数の利害関係者がいます。誰がプロジェクトにお金を払っているのか、そしてその理由を突き止めることで、主要な利害関係者を突き止めることができます。
ユーザーが主要な利害関係者になることはめったにありません。通常、利害関係者は、利害関係者が利益を得ることができるように、ユーザーに何かをしてもらいたいと考えています。
たとえば、Twitter の投資家は、ユーザーが将来お金を稼ぐためのすべてのオプションを保持できるように、ユーザーに Twitter を楽しんでもらいたいと考えています。上司は、秘書がワープロを使用して、手紙をより速く入力し、土壇場で気が変わることを望んでいます。StackOverflow は、優れた投稿に賛成票を投じて、広告収入を得たいと考えています。
これは、ユーザーと利害関係者の懸念を分離するために使用できるテンプレートを含む、この件に関して私が書いたブログ投稿です。投稿のユーザーであるあなたがそれを読んだときに誰が恩恵を受けるかを想像するための演習として残します.