私は UX デザイナーとして働いており、機能要件をフォームに文書化するために使用されたアジャイル開発プロジェクトのユーザー ストーリーの経験があります。
【利用者タイプ】として【目的】をしたい【理由】
何人かの同僚と議論した後、[ユーザーのタイプ] がどうあるべきかについて 3 つの異なる解釈を特定しました。
誰が正しいですか？私たち全員が正しければ、これはよくある混乱の原因ではないでしょうか?
ユーザー ストーリーは、その言語で、製品のエンド ユーザーの視点から書かれています。
したがって、ユーザーはまさにそれです。彼らはシステムのユーザーです。
例は次のとおりです。
ユーザーストーリーは、エンドユーザーまたは利害関係者が自分の視点から製品をどのように見て使用するかを示すために、製品のバックログからの要件を説明するのに最適です。PO は、ユーザー ストーリーの正確性についてコメントできる最高の人物であるべきです。PO がユーザー ストーリーの開発のためにチームから情報を収集している場合、ユーザーのタイプを単純に分類するのではなく、製品の使用法をさらに視覚化する必要があります。ユーザーのタイプも重要ですが、1. 医師が医薬品の内容や製造元を知るために医療サイトにアクセスする場合、どのようなアクセス権を医師に与える必要があるかなどの使用法を強調する必要があります。一方、2. 薬剤師が特定の医薬品、入手可能な数量、出荷時間を探している場合は、それに応じたアクセスとワークフローを提供する必要があります。
上記の使用法から、最初のもの、つまりペルソナと彼の観点からのシステムの使用法が適切であることがわかりました。システムの使用ごとに、ユーザー ストーリーを作成することができ、それに応じてワークフローを開発することができます。
1と2はよく使われます。私は多くのチームと仕事をしてきましたが、彼らの製品のために多くのペルソナを作成しました。たとえば、年配の女性のジェーン、スマートフォンですべてをこなす流行に敏感なダフネ、パーソナル アシスタントにすべてを任せる重役のジョンなどです。
これらのペルソナは、システム内で同じ機能を実行している場合や、同じ役割の観点から行動している場合でも、ソフトウェアの要件が大きく異なります。
ある価値ステートメントは、別の価値ステートメントと競合することさえあります。ジェーンが大きなフォントで現在のアクションに関連する情報のみを必要とする場合、ジョン (のアシスタント) はより広い視野を持ち、より多くの情報を詰め込むことができることを意味する場合は、視覚化と小さなフォントを気にしない可能性があります。画面。
したがって、ペルソナは、特定のロールをさらに絞り込み、ユーザー ストーリーをより「人間的」なものにするための手段と見なしてください。ユーザー ストーリーは、ユーザーのストーリーと、その機能がユーザーの達成に役立つこと、ユーザーに何をもたらすかを実際に伝えることを目的としていることを忘れないでください。「管理者」、「顧客」、「ゴールド カスタマー」の役割は、感情が空っぽになりがちで、適切な議論につながらないことがよくあります。
いくつかのチーム ディスカッションで、人々がディスカッションの途中で次のように述べたのを覚えています。これは、提案された機能の変更につながります。
オプション 3 については、かなりの数のチームがそれを行っているのを目にしますが、特定の役割ではそれが理にかなっている場合もあります...運用エンジニアとして、運用インシデントを迅速に分析するために、徹底的なログ記録が必要です。例かもしれません。しかし、要件アナリストとして、ストーリー 27 の要件は行き過ぎです。多くの場合、これらの項目は非機能要件バケットに分類され、真のエンド ユーザー機能を提供しません。これらのタイプのプロダクト バックログ アイテムについては、ユーザー ストーリーがそれらを説明するのに最適な形式であるかどうかを確認する必要がある場合があります。