UXとUIのストーリーをアジャイルフレームワークのどこに配置しますか？
私はアジャイルを実行する（しようとしている）3番目の仕事にいます。要約すると、次の2つの経験があります。
非常にインクリメンタルなスプリントを行う15名の緊密な小さなチーム（大きな拡張に取り組んでいなかったことを意味します）。すべてのUXとUIの作業は、スプリント中に非常にアドホックで協調的な方法で行われました。
2つのUI開発者がいる1つの緊密な開発チームと、いくつかのスプリントを先に進めて、高速で構築できるように準備するUXチーム。
これらは比較的うまくいきました。もちろん、彼らには問題点がありましたが、両方の状況でUXの「全体像」を考えることにはまとまりがありました。
私は今、巨大な製品に取り組んでいる2つのSCRUMチームの1つにいます。 UXとUIの作業がスプリント計画のどこに収まるかという課題に直面しています。
私たちのモデルには前もっての作業はありません。製品の所有者は機能を望んでおり、開発者がそのスプリント中に構築できるように、機能はUX POVから設計し、UI POVに実装する必要があると述べています。
そのようなアジャイル環境で働いたことがありますか？その場合、UXおよびUIタスクのすべてをストーリー内のどこに配置しましたか（たまたまJIRAを使用しています）？
混乱しているのは、次のようにストーリーを分解した可能性があることです。
- ユーザーとして、フォームに記入できるようにしたい...
- ユーザーとして、フォームに間違いを犯した場合に通知を受けたい...
- ユーザーとして、フォームが正常に送信されたかどうかを通知したい...
私の苦労は、UXおよびUIタスクを上記に当てはめることです。すべてのストーリーがこれらのタスクを必要とするように思えます：
- UXデザインUI
- UI CSSとHTMLを構築する
個々のストーリーについて。これは冗長であり、追跡するのは非常に困難です。その理由は、もちろんこれらを個別に設計して実装することはないからです。デザイン、HTML、CSSは全体として機能する必要があります。
1つの提案は、「開発チームとして、誰かがHTMLとCSSを設計する必要がある」というストーリーを作成することでしたが、ユーザー中心ではなくなったため、これはかなり俊敏に見えます。
それで、彼らのために働くと思われるこれに対する解決策を誰かが見つけましたか？あるいは、私がこれまでに経験したほとんどのアジャイル体験や他の人から聞いた経験と同様に、UXはアジャイルプロセス全体を先取りして、雑草に取り憑かれないようにする方法を理解する必要があります。
まず最初に
このシナリオではUXは成功しないと思います。スプリントは、同じ機能の設計と実行の両方を行うには短すぎます。エンジニアリングリクエストになる前に、プロダクトマネージャーが作業を定義することで、問題の前にいる必要があります。
そのアプローチを真剣に受けた場合（100％を実現することはできませんでした）、最終的にはデュアルトラックスクラムが発生します。ディスカバリートラックは、デリバリートラックのバックログをフィードします。ディスカバリーは、理想的には、製品管理、ユーザーエクスペリエンス、およびソフトウェアアーキテクチャのパートナーシップです。
質問に戻る
この作業を行う必要がある場合、Jiraではストーリー/タスク/バグをリンクすることができます。私の役割の1つは、プロジェクトのライフサイクル全体でJiraを使用する疑似デュアルトラックチームです。かんばんボードを埋めるために使用するプロセスは次のとおりです。
- 高レベルのストーリーを作成します。これらは、製品マネージャーで行われた発見作業に基づいています。私はジョブストーリー形式を使用します。これらはあなたがリストした例のような雑草に入らない。ユーザーの活動に集中してください。
- ストーリーの子としてUXタスクを作成します。これは、適切な機能リクエストを行うために必要な調査または設計作業を定義します。
- Xタスクに依存するエンジニアリングタスクを作成します。これらは通常、予備的なUXのアイデアに基づいて、プロジェクトのエンジニアリングリードによって分割されます。これらのタスクが、UX部分の少なくともある程度の完了前に正確に作成できることはまれです。
これはすべてJiraで非常に効率的に実行できます。通常、詳細が記入される前に、ストーリーについてJiraでいくつかの議論があります。特にリモートチームの場合。
エンジニアリングがうまくいかないとき
コメントから
エンジニアリングはUXに依存したくないとおっしゃっていました。それは単に傲慢な愚かさです。それは優越性の問題ではなく、適切な順序、つまり実装前の計画です。このアナロジーをポーズします。
データベースを構築し、スキーマを並行して定義しますか？
彼らがそれに対してイエスと答えることができるなら、あきらめてください。
私はあなたと非常によく似た経験をしました（そして、かなり以前からJIRAを使用しています）。
それは行きます：
ユーザーストーリーは非常に限られています
すべてのアジャイルチームは、ユーザーストーリーを理解したり操作したりすることに失敗しているようです。しかし、正当な理由から-ユーザーストーリーは問題のドメインのごく一部しかキャプチャしません。ユーザーストーリーがキャプチャしないいくつかのことを次に示します。
- 該当する場合は複数のペルソナ（たとえば、会計士と簿記係）。
- 前提条件。例：「銀行と明細書が一致しない場合、不一致が発生するトランザクションを知りたい」そこでは、ユーザーストーリーに前提条件を追加する必要があるというかなりの議論があります。
ユーザーストーリーは主題ドメインに焦点を当てるべきです
ユーザーストーリーは、いわゆる件名ドメインにある必要があります。これは、システムのないユーザーの世界での意味です。これにより、ストーリーに値を簡単に割り当てることができます。例えば：
プロジェクトマネージャーとして、自分が作成したタスクを他のユーザーに割り当てられるようにしたいと考えています。
動機が暗示されていることに注意してください。
システムドメインの側面でユーザーストーリーが乱雑になり始めると、事態は複雑になります。検討してください：
ユーザーとして、フォームに記入できるようにしたい...
どのユーザーがフォームに記入したいですか？ユーザーがフォームに入力する必要があるのはシステム（または銀行）です。私はすべてのユーザーがフォームフィラーの24時間年中無休のアシスタントを望んでいると思います。
ユーザーとして、フォームに間違いがあるかどうかを教えてもらいたい...
細かすぎるので、ユーザーは「フォームを表示」したくなるでしょう。
ユーザーとして、フォームが正常に送信された場合に通知を受けたい...
繰り返しますが、細かすぎます。
では、ユーザーストーリーとは何でしょうか。
OK、つまり、ユーザーストーリーは次のとおりです。
- より複雑なシナリオの説明への単なるタイトル。
- 通常は高レベルです。
- 明確なビジネス/ユーザー価値を持つ何か。
- 理想的にはサブジェクトドメインにあります。
大きな絵
上記の説明を順守する場合、物事を分解する1つの方法は次のとおりです。
- A ユーザーストーリーは、問題ドメインのいくつかの側面に焦点を当てた説明のタイトルです。
- ユーザーストーリーはユースケースのソース、またはその一部です。
- ユースケースには、理想的なパスと代替手段（たとえば、検証エラーが含まれます）が含まれます。
- ユースケースは、さまざまな画面要素（ページ、パネルなど）に分散されています。
そして、スクラムのセットアップ内で：
- 製品の所有者は、チームの優先順位とともに、次のスプリントで配信されるユーザーストーリーを選択します。
- 調査と設計のフェーズが行われ、受け入れテストが考案されます。
- デザイナーはデザインドキュメントを開発者に提供します。開発が行われます。
- QAは、ユーザー（製品所有者）が実装に満足していることを確認します。
ユーザーストーリーの配信とUXの問題/改善。
ユーザーストーリーの提供（明確な価値のあるもの）とUXの問題または改善を概念的に区別する必要があります。
次のユーザーストーリーについて考えてみましょう。
ユーザーとして、[送信]を2回押してもアプリケーションがクラッシュしないようにしたいと思います。
これはバグとして文書化されます-システムの誤動作-期待どおりに動作しない何か。
同様に、報告されたUXの問題または改善は、そのようにマークされ、そのように処理されます。
ユーザーストーリーとタスク
また、ユーザーストーリーとタスク（デザイナーまたは開発者）を区別する必要もあります。 「フォームの実装」や「検証の実装」のようなものは開発者タスクです。確かに、ユーザーストーリーはこのような低レベルの詳細を処理するべきではありません。
JIRAの問題
JIRAの1つの問題は、1つの問題には1レベルのサブタスクしか設定できないことです。これにより、チームのニーズに必ずしも一致しない特定のレベルの細分性が必要になります。 （個人的には、JIRAにこの制限がないことを望みます。）
提案された解決策
- ユーザーのストーリーとUXの問題/改善を区別します。
- ユーザーストーリーを高レベルに保ちます。ユーザーストーリーをより小さなユーザーストーリーに分解できる場合（ユーザーが表現したとおり）、代わりにepicを使用します。
- ユーザーストーリーがスプリントに選ばれたら、タスク（研究、UX設計、ソフトウェア設計、開発、QA）を表すサブに分解します。これらのそれぞれは、異なるチームメンバーに割り当てられ、見積もりがあります。
- 担当者が追加の細分性を必要とする場合（開発者は作業を小さなチャンクに分割したい場合があります）、新しいタスクを作成して、ユーザーストーリーサブタスクをブロックします。
最初にユーザーストーリーに焦点を当てます。それが書かれているように、現状では、最初のストーリーに固有のユーザー価値はありません。ユーザーの観点から書き直してみてください（ユーザーはフォームに記入したくないが、希望するものを取得するにはフォームの記入が必要であると考えてください）。 devとのコラボレーションでuxによって作成された単純なuxワークフローをアタッチします。他の2つのストーリーは、全体的なuxおよび許容基準の一部と見なすことができます。
以下は、本当に俊敏である場合にも役立ちます。
かんばんステージとしてのデザイン
UX/UIデザイン対コーディング用のカードを作成する代わりに、デザインをカンバンボードのステージとして扱います。
オープン->Ready for Design-> Ready for Coding-> In Progress->Ready for UIレビュー->コードレビューの準備->など.
「Ready for UI Review」に注目してください。これにより、カードが「Ready for Code Review」に入る前に、実際に何が作成されたかを確認できます。
現在、チームが一度にアクティブにできるカードのセットは1つだけである場合、これは問題を解決しません。プログラマーはデザイナーを待って座っているでしょう。私たちのチームでは、一度に数回の反復を計画するだけなので、次の反復の設計を事前に開始できます。
真の敏捷性
プロセスを微調整することは、アジャイルの真の意味と一致しており、認証業界はそれを一連の特定の厳格なプラクティスに絞り込むことができませんでした。真のアジャイル開発には、実用的で柔軟であり、継続的に学習、評価、適応することが必要です。 Dave Thomasによる真の敏捷性の防御を参照してください。
あなたの会社が私たちのものであるなら、それはまだ関連があるかもしれません;）
「いくつかのスプリントに先んじて、迅速に構築するための準備を整えるUXチーム。」
これがまさに私がやったことです。私が最大6人のUXチームで大規模なプロジェクトに参加し、最大4つの開発チームがスクラムを担当していました。
まず、UXの多くが機能します。顧客とユーザーの要件などの調査-ストーリーを生成するには、最初に行う必要があります。したがって、この説明は、多くのストーリーがキャプチャされ、改良が必要だった時点から始まります。
UXチームは開発チームよりも先に作業し（スプリントをいくつか目指しましたが、1つのスプリントを先に進めることができてラッキーでした-2週間）、デザインの準備ができたときにストーリーは「開発準備完了」とマークされました。
UIに影響を与えたストーリーは、最初にUXチームを通過しました。 JIRAも使用しました。最も単純なストーリーの場合、必要なUIの変更を説明するコメントをJIRAに書き込むだけです。 （「フィールドaと同じスタイルでxを形成するために別のフィールドを追加します」）、さらに作業が必要なストーリー（モックアップ/リサーチなど）の場合、ストーリーの子としてこれのサブタスクを作成します。 （私たちのストーリーはこの時点では最高レベルではなかったことに言及する価値があるかもしれません-すべてのストーリーは子供としてEpicsにリンクされていたため、すべてを全体像に結び付けることができました。）
@plainclothesによるデータベースの類推は優れたものです。実際、結局、UXチームとまったく同じように機能するデータベースチームができました。彼らがスキーマ設計を行ったときの話は、「開発の準備ができている」だけでした。
私たちの仕事のやり方は、次第に別のスクラムチームになろうとすることから、開発チームに供給するために必要なことだけを行うように進化しました。私たちのボードはかんばんのボードに少し似ていました。最近私は私たちが働いていた方法が実際に認識されていることを発見しましたが、この図はマネージャーで手を振るのに良いかもしれません： http://www.scaledagileframework.com/
到達するのにしばらく時間がかかり、物事は常にスムーズであるとは限りませんでしたが、全体的にこれは良い作業方法であると本当に感じ、もう一度お勧めします。