it-swarm-ja.com

誰がユーザーストーリーを書いていますか?

アジャイル設計/開発では、誰がユーザーストーリーを書き、プロセスは何ですか? UXの研究者は、より良いユーザーストーリーを定義するために、最初に研究を行う必要がありますか?

私の現在のプロジェクトでは、ユーザーストーリーがありますが、UXはこれらのストーリーの定義に役立つユーザー調査に関与していません。これにより、プロジェクトの非効率的な部分が減りました。私はUX戦略の経験はありませんが、ユーザーストーリーを事前のUX調査に基づいたものにするのが賢明なアプローチのようです。はい?番号?

8
MRL

オースティンフランス語の回答で指摘されているように、ストーリーの執筆は通常、「通常の」アジャイルにおけるプロダクトオーナー(PO)の責任です。また、プロジェクトによっては、POがテクニカルリードと協力してストーリーを定義し、実用的な作業に翻訳しやすくなることも珍しくありません。

質問が暗示するように、UXが関与している場合、UXを定義するストーリーをPOが作成することはできません。もしそうなら、彼らは本質的に実装を定義していますが、それは物語の仕事ではありません。

別の答えで引用された例の話を例にとろう...

We need a grid to show Customer Details

このストーリーの問題は、機能(顧客の詳細を表示)UX実装(グリッド)の両方を定義していることです。

POからのストーリーは...

We need to show Customer Details

「方法」を決めるのは開発者次第です。また、UXデザイナーは、顧客の詳細をどのように表示するかを決定します。

つまり、UXデザイナーを開発チームの1人(ストーリーの実装者)として扱うか、リードの1人(ストーリーのガイド)として扱うかを決定できます。

開発チームメンバーとしてのUXデザイナー

このアプローチでは、UXデザイナーは開発者の1人です。開発チームがストーリーのデータ部分を担当するデータベーススペシャリストを抱えているように、UXデザイナーはストーリーのUX部分を担当しています。

Xデザイナーテクニカルリード

一部のアジャイルアプローチでは、テクニカルリードがPOと会ってストーリーの定義を支援し、ストーリーを開発チームに渡します。このアプローチでは、UXデザイナーをリードの1つとして扱うことができます。 UXデザイナーは、ストーリーに直接影響を与える製品への特定のアプローチを念頭に置いている場合があります。

真実は、POがストーリーを作成するときに潜在意識の中でUXを頭の中で想像しているという意味かどうかです。それらが意味するかどうかにかかわらず、不注意にUXの方向に影響を与えます。これが、UXデザイナーと協力してストーリーを作成する手助けをすることが非常に役立つ理由です。

結論

  • POはUXを定義するべきではありません(意識的または無意識的に)
  • UXデザイナは、データベースのリードやソフトウェアエンジニアのような「開発者」です。
  • UXは実際にはデザインとストーリーの原動力になる可能性があるため、ストーリーのオーサリングプロセスの一部となる可能性があります。
4
Tim Holt

一般的に、私はあなたのプロセスと走行距離が変わるかもしれないので、一般的にこれを言います:

  1. プロダクトオーナーには次の要件が必要です。

おそらく要件は次のとおりです。

顧客の詳細を表示するグリッドが必要です

  1. 理想的には、これは手入れされます。リード、PO、およびプロセス中の利害関係者は、要件を確認し、より実行可能なものを定義できます。

    モバイルに適したグリッドが必要です。これには、顧客名、電子メール、および編集アイコンをクリックして編集可能なアドレス付きの拡張可能なボックスが表示されます。

  2. これが実行可能であると見なされ、バックログに入れられると仮定します。次に、スプ​​リント計画時に、チームは、未知の複雑さと要件を特定できる必要があります。考えられる問題は次のとおりです。

    これをすべて実行できることがわかっているグリッドフレームワークはありません。

もしそうなら、私たちが行ったことは、タスクが大きすぎて未知であると感じた場合、POCのスパイクを作成することです。

Angularのマテリアルグリッドを使用したいのですが、これが3ポイント、21、または大量のハッキングなしでは不可能かどうか確信が持てません。

  1. それが事実ではなく、チームが複雑さに同意できると仮定すると、スプリントに組み込まれます。

    4b。そうでない場合は、レビューまたはデモとともに、スパイクをPOCに挿入します。そして、将来のスプリントで実際の作業を行います。

私のさまざまな経験(フルスタック)では、不明な点があると大量のリスクが追加されます。大量のリスク/未知数はより多くのポイントを意味します。もちろん、課題は通常、実際にはアジャイルではない組織であるため、スパイクの作業を遅らせることはできません。優れたスクラムマスターといくつかの成功したスプリントがあれば、チームが自信を持って言うことができれば、次のように簡単になります。

私たちは見積もりに現実的であり、成功したスプリントと迅速な納品はプロセスによるものです。

3
Austin French

誰でもユーザーストーリーを作成できます。アジャイルユーザーストーリーの製品バックログが存在することを確認するのは製品所有者の責任ですが、それは製品所有者がそれらを書いているという意味ではありません。優れたアジャイルプロジェクトの過程で、各チームメンバーがユーザーストーリーの例を作成することを期待する必要があります。また、だれがユーザーストーリーを書いているのかは、だれがそのディスカッションに関与しているよりもはるかに重要ではないことに注意してください。

(ソース)

デザインリサーチなしにユーザーストーリーを作成することは困難です。このような調査なしでは、ユーザーの期待や行動についての理解はほとんどありません。これ以前は、製品は問題ステートメントとしてのみ存在していました。製品のコア機能が定義されている場合にのみ、ユーザーストーリーを作成してさらに設計および開発できます。

3
Ren

だれでもユーザーストーリーを書くことができ、優先順位を付けるのはPOの仕事です。

あなたの質問は、誰が物語の洗練に関与しているべきだと思います。これは、DoR(Definition of Ready)を満たすためのストーリーを取得するプロセスです。

作業方法によっては、準備が整っていることは多くのことを意味しますが、ストーリーが何らかの形でUXに影響を与える場合、UXリソースは絞り込みに入力する必要があります。

ストーリーがバックログに入り、リファインメントを入力し、その後、開発チームが作業を開始できないほど多くの未知のものになってしまうことは非常に一般的です。ストーリーがあまりにも多くの未知数とともにバックログに入るのも一般的であり、UXデザイナーも続行できません。

これが私にとってUXの出番です。それらのストーリーを取り上げ、さまざまな利害関係者と関わり、未知への答えを得て、ストーリーを準備する準備が整います。

それは、POから(その利害関係者経由で)、BA経由で、またはUser Research経由で答えを得ているだけかもしれません。しかし私にとって、ストーリーを前進させることはUXの責任です。製品の方向性を推進したい場合は、その製品のビジョンの作成に関与する必要があります。つまり、ティムが言うように、ストーリーのオーサリングに直接または間接的に関与している必要があります。

3
dougajmcdonald

それはおそらく理想的ですが、ユーザーストーリーは、大規模な研究が行われる前にテストおよび更新できるMVPの作成に焦点を当てたアジャイル開発プロセスの一部として作成されることがよくあります。ここでのUXSEでのほとんどの質問と同様に、それはコンテキストに依存し、この場合、YESまたはNOの回答は等しく有効です。あなたが行ってそれらを検証する限り、あなたは仮定をすることが許されていることを覚えておいてください。

また、理想的な世界では、誰でもユーザーストーリーを記述できる必要があります。これは、アジャイルでユーザー中心の設計プロセスの経験を持つ成熟したチームを示しています。ただし、チームの設計/開発の成熟度が異なる場合は、通常、製品の所有者、UXデザイナー/リード、Devリードなど、経験が豊富な人がこのプロセスを推進します。

1
Michael Lai