web-dev-qa-db-ja.com

アジャイルに「UXストーリー」はありますか？

UXが「全体像」の考え方を処理するために使用できる、アジャイル内のユーザーストーリーの代替案が文書化されていますか？

たとえば、3つの異なる「チャンク」の開発があるWebページがあるとします。開発者はこれらを個別のストーリーに分解して、それらを機能させるためにすべてのバックエンド接続の構築を開始できるようにする必要があります。

ただし、これらの3つの「チャンク」は、UXおよびUIの観点から、1つの全体的なページとして設計する必要があります。

JIRAのコンテキストでこれに対応する方法に苦労しています。そこでは、ストーリーを毎日の追跡可能なタスクに分解することが期待されています。

各ユーザーストーリーの下にUXタスクを追加することは、それを処理する1つの方法ですが、それは本質的にタスクの複製です。

たとえば、「ワイヤーフレームの作成」は各ストーリーのタスクです。ただし、ワイヤーフレームは1つしかありません。ページのワイヤーフレームです。

そこで、開発者が使用しているストーリーと重複/干渉しない個別に追跡可能な要素としてUXタスクを引き出す方法を見つけようとしています。

1つの考えは、「UXストーリー」（より適切な用語がないため）と考えられ、次のようになります。

[私たちのチームの開発者]として、[ソリューションを構築する]ために[UIがどうなるかを知る]必要があります。

私にはそれはばかげているように聞こえ、何よりもハックのようですが、これにより、UXが1つのストーリー内で処理して簡単に追跡するためのタスクを構築できます。

これを処理するためのより良い方法を誰かが見つけましたか（最初にスプリントからUXを移動する前に...）？

「デザインスパイク」は1つの提案でしたが、私が読んだものはすべて控えめに使用する必要があると述べています。そして、UXが開発者が次のスプリントを実装できるタスクに取り組むことができるように、スプリントごとのソリューションが必要です。

design-processagile
7
DA01

すばらしい質問です。全体像とタスク管理を提供する方法のいくつかのコンポーネントに分解してみます（可能な場合はJiraドキュメントを参照してください）。あなたが説明したことから、「全体像」の考え方を処理するユーザーストーリーはEpicと呼ばれます。エピックは本質的に大きなユーザーストーリーであり、いくつかの小さなユーザーストーリーに分解できます（ エピックの定義に関するJIRAリファレンス） 。エピックを使用すると、開発チームが要件を包括的に把握するために必要なユーザーストーリーの「チャンク」をロールアップするための優れた方法が提供されます。 JIRA環境の設定方法がよくわからないので、次のリンクは、Jiraでエピックを操作するためのユーザーガイドへのリンクと、EpicをユーザーストーリーにリンクするJIRA環境での実装に関するQ＆Aリンクです。

タスク管理に関するあなたの例は、私が反対の視点を提供する興味深いものです（タスクの管理方法はプロジェクトマネージャーごとに異なる場合がありますが、どのように管理するかを説明します）。 「ワイヤーフレームの作成」の例から、そのタスクは叙事詩に完全に適しています（ページ全体のワイヤーフレームを作成すると言ったように）。ただし、これらの各ユーザーストーリーには、そのページ内で設計/ワイヤーフレーム化する必要のある特定のコンポーネントがあります。ユーザーストーリーレベルでタスクを管理することにより、UXデザイナーがそのエピックのすべての要件を確実にカバーできるようにします。ユーザーストーリーレベルでUXタスクを管理するもう1つの利点は、エピックの完了を待たずに、UXタスクが完了すると、開発チームがユーザーストーリーのコンポーネントの開発を開始できることです（私はあなたが開発チームよりも前にUXを1つスプリントします）。

要約すると、いくつかの関連するユーザーストーリーの全体的なビューを提供するために、私はエピックの使用を開始しますが、ユーザーストーリーレベルでUXタスクを管理し続けます。

6
Clint

答えはスパイクストーリーです

アジャイルにはUXデザインの余地はないと言われているようです。しかし、あなたがそれを最大限に活用する場合があります。バックログから実際のユーザーストーリーを取得する前に、スパイクストーリーを実行できます。スパイクとは、出荷可能な製品の生産ではなく、質問への回答や情報の収集を目的としたストーリーまたはタスクです。 UXデザインの問題を解決するために開発チームが実際の作業を行うまでは推定できないユーザーストーリーが生成されることがあります。解決策は、「スパイク」を作成することです。これは、答えまたは解決策を提供することを目的とするストーリーです。他のストーリーやタスクと同様に、スパイクには見積もりが与えられ、スプリントバックログに含まれます。

読んでください ：

http://agiledictionary.com/209/spike/

http://agileatlas.org/articles/item/spikes-in-scrum-the-exception-not-the-rule

この急上昇中に、利用可能なオプション（ワイヤーフレーム）を考え出し、それを顧客または利害関係者にフィードバックのために実行する必要がある場合があります（UX Reaserch）。

3
Sachux

そこには多くのベストプラクティスがあります。私の作業には、Ivar Jacobsenのユースケース2.0モデルが適しています。一般に、ユースケースのような確立されたプロセス管理モデルについて考え、ユーザーストーリー/エピック/ ...のようなアジャイルなものについて考え、ビジネスのためにそれらを組み合わせることについて考えます。

ユースケース2.0ホワイトペーパー

0
Gustav