スクラムプロジェクトのUXは誰が担当しますか？
OK。あなたが教科書スクラムプロジェクトに取り組んでいるとしましょう。あなたは、製品所有者と協力しているスクラムマスターを手に入れました。次のスプリントはUIが重いです。コーダーが画面の作成を開始する頃には、実際にsomeがどのように表示されるかを考えている必要があります。
誰がいつワイヤーフレーミングを行うのですか？製品のオーナーは？製品の所有者をサポートしている人はいますか？スクラムマスター？ UXエキスパートがいる場合、彼らはコーダーと連携して動作しますか後スプリントが開始されますか、またはストーリーカードの横に座ってワイヤフレームとモックアップを提供し、ガイドと通知のための制約を提供しますか？開発者が行っている作業？
UXのヘルプが必要だと思いますが、どこに適用すればいいのか本当にわかりません...
編集：質問を言い換えましょう。
アジャイルプロジェクトで一貫した高品質のユーザーエクスペリエンスをどのように提供しますか？
インタラクションデザイナー
UX！= UI一般的な考えであるnotプログラマーとは異なり、優れたユーザーエクスペリエンスを提供するには、経験豊富な対話デザイナーが必要です。 UX（私を含む）を実行できると思うプログラマーの皆さんのために、これについてお話しさせてください。インタラクションデザインを理解するには、少なくともプログラミングを理解するのと同じくらいの時間が必要です。純粋なインタラクションデザインを行うためにどのくらいの時間を費やしましたか？
初期段階では、インタラクションデザイナーは次のことを行う責任があります。
- 製品所有者からソリューションの実際の目標を抽出する
- ソリューションを使用するペルソナを定義します。
- ソリューションの使用方法に関するストーリーであるシナリオを記述します。
- UXの観点から、曖昧さの余地がほとんどない設計ドキュメントをコンパイルする
プロジェクト中は、これらのガイドラインが遵守されていることを確認し、発生する（および発生する）追加の問題に対処することがインタラクションデザイナーのタスクです。
多くのプログラマーがこのアプローチに前向きになるでしょう。「素晴らしい」インターフェースを設計できるのは例外だと誰もが思うので、おそらくそうではありません。一方、優れたインタラクションデザイナー-プログラマーとの関係は、プログラマーにとって「非常に良い」ものであり、「愚かな仕様」に対抗する必要もありません。残念ながら、私の経験では優れたインタラクションデザイナーを見つけるのは難しいですが、彼らはそこにいます。
いつものように、私はこのテーマに関するアラン・クーパースの本を強くお勧めします（「顔について」と「囚人は亡命を実行しています」）
他のチームと同じようにUXの人の仕事を整理することをお勧めします。彼はチームの同等のメンバーと見なされ、スタンドアップに参加し、プログラマーと緊密にコミュニケーションする必要があります。
理想的には、モックアップは少なくとも1つのスプリントを事前に行う必要がありますが、小さな機能の場合、モックアップを現在の反復で計画されたストーリーのサブタスクとして作成することを検討することは理にかなっています。
いつもアジャイルと同じように、常識を使い、さまざまなアプローチを試し、特定の状況でうまく機能するアプローチに固執してください。
私の意見では、これはどういうわけか特別なケースであり、特別な方法で処理する必要があります。スクラムマスターは絶対にこれに参加しないでしょう-それは彼の役割ではありません。チームは通常、開発者のグループであり、そのほとんどはUXの経験がなく、これを強制するのは時間の無駄です。 UXエキスパートを採用します。エキスパートはチームの一員ではありません。チームは部門を超えており、UXエキスパートはおそらく開発者ではありません。また、UXの専門家は、その期間全体にわたってプロジェクトに参加しません。 UXエキスパートは、製品オーナーと1スプリント先で協力して、次のスプリントで何を行う必要があるかをチームが把握できるように、次のユーザーストーリーのモックアップとワイヤーフレームを準備します-モックアップは計画会議中に利用可能になります。製品の所有者は次のスプリントで実行される最も優先順位の高いユーザーストーリーを知っているため、無駄が多すぎないようにする必要があります（顧客からの要件が大幅に変更されるまれな場合を除く）。
編集：
これについてどこかで読んだことがわかっていて、ついにそれを Succeeding with Agile：Software Development Using Scrum by Mike Cohn で見つけたので、追加の調査を行いました。 Mikeは、チームにおけるUXデザイナーの役割について正確に話し合っています。彼の最初の説明は私のものと似ており、会社が開発方法をウォーターフォールからスクラムに変更したとき、彼はそれを自然な変化と考えていますが、後で彼はそれを推奨されていない方法であると結論付けています。その理由は、UXデザイナがチームに属していない場合、自分は別のチームであると考えることができ、開発チームのコミットメントを共有する必要がないためです。
これにもかかわらず、@ Adam Byrtekの答えは正しいように見えます。 UX担当者をチームに参加させ、現在実装されているユーザーストーリーについて開発者と協力できるようにします。 UX担当者がいつも時間を費やすわけではないので、彼は製品の所有者または顧客と協力して、1つまたは2つのスプリントに向けてモックアップとワイヤーフレームを準備します。
私はJakob Nielsenのアラートボックスを購読しています（主に彼の迷惑なWebデザインプラクティスに対する彼の批判が原因です）、最近トピックに関するいくつかの記事を読んだことを思い出します（ただし、アジャイル開発プロセス全体について少しでも理解しているわけではありません）。あなたのための使用：
「教科書スクラム」の場合：
まず、スクラムマスターはプロダクトオーナーと協力しません。SMとPOを含むチーム全体がシステムを構築するために協力すること以外は、まったく意味がありません。
第二に、スクラムチームは、部門を超えたチームメンバーと均質であることが想定されています。したがって、「UX Guy」はありません。
また、UXをスプリントで機能コードより先に構築することはおそらくないでしょう。機能は1つのスプリント内で完全に提供されます。機能に関連付けられたUXが複雑すぎて、機能コードと一緒に単一のSprintで提供できない場合は、機能全体を、UX要素を含め、単一のSprintで実行できる何かに分割します。
ウォーターフォールプロジェクトのUXは誰ですか？ XPプロジェクトのメインフレーム開発は誰が行いますか？
プロジェクトの方法論は重要ではありません。すべてのテクノロジープロジェクトには、特定の特別な役割が必要です。場合によっては、プロジェクトは、完全にライセンスされ、拘束力のある「インタラクションデザイナー」（それが何であれ）なしに逃げることができます。専門家が必要になることもあります。しかし、他のすべての役割についても同じことが言えます。
それでは、アジャイルを使用して高品質のユーザーエクスペリエンスを提供する方法についての2番目の質問に移ります。私は、ビジネスアナリストと顧客を早期かつ頻繁に関与させることで、私が関わった最後のスクラムプロジェクトでそれを管理しました。また、UXに特に優れた開発者がいました。開発者がコミットした後、開発者が作業していたUIにマイナーな調整を加える傾向がありました。
すべてのスプリントの最後に完璧なUXを提供したわけではありません。デモは一般的に、UXの観点から1つまたは2つの問題を明らかにしました。しかし、次のスプリントのためにそれらを修正し（顧客にとって価値がある場合）、製品化するまでに、非常に堅実なUXを実現しました。
UXとは、ユーザーインターフェイスデザイナーを意味する場合、チームのもう1つの役割またはリソースにすぎません。ユーザーインターフェイス設計は、他の設計と同様に、プロジェクトを切り抜けます。事前に行う必要がある妥当な量のアーキテクチャ/設計作業があり、作業を進めるにつれて実行できる量があります。
UIデザインタスクは、多くの場合、開発スプリントと同じスコープに適合しないことに注意してください。 UIコンポーネントの設計では、実装に実装するために多数のスプリントが必要になる場合があります。
実際には、UI/UXデザイナーは、ソリューション全体で一貫している必要がある側面に対処するために、合理的なリードタイムを必要とする傾向があります。私はそれをソフトウェアアーキテクチャとして考えるのが好きです。多くの場合、特定のコンポーネントの設計は、実装前にスプリントを実行できますが、設計者が着手すると、実装のペースをはるかに上回ります。後のスプリントは、ソリューションが具体化し始めると、ルックアンドフィールを実装/探索し、ユーザビリティフィードバックを得るのに適した場所になる傾向があります。これらの後半の演習の結果は、次のスプリントの計画にフィードバックされます。