スクラムプロジェクトのUXは誰ですか？

OK。あなたが教科書スクラムプロジェクトに取り組んでいるとしましょう。あなたは、製品所有者と協力しているスクラムマスターを手に入れました。次のスプリントはUIが重いです。コーダーが画面の作成を開始する頃には、実際に彼らがどのように見えるかを考えている必要があります。

誰がいつワイヤーフレーミングを行うのですか？製品のオーナーは？製品の所有者をサポートしている人はいますか？スクラムマスター？UXのエキスパートがいる場合、スプリントの開始後にコーダーと一緒に作業しますか、それともストーリーカードと制約のそばに座って、開発者が行っている作業をガイドして通知するワイヤーフレームとモックアップを事前に提供しますか？

UXのヘルプが必要だと思いますが、どこに適用すればいいのか本当にわかりません...

編集：質問を言い換えましょう。

アジャイルプロジェクトで一貫した高品質のユーザーエクスペリエンスをどのように提供しますか？

インタラクションデザイナー

UX！= UI プログラマーではないという一般的な信念に反して、優れたユーザーエクスペリエンスを提供するには、経験豊富な対話デザイナーが必要です。UX（私を含む）を実行できると考えるプログラマーの皆さんのために、私にこれを言いましょう。インタラクションデザインを理解するには、少なくともプログラミングを理解するのと同じだけの時間が必要です。純粋なインタラクションデザインを行うためにどのくらいの時間を費やしましたか？

初期段階では、インタラクションデザイナーは次のことを行う責任があります。

1. 製品所有者からソリューションの実際の目標を抽出する
2. ソリューションを使用するペルソナを定義します。
3. ソリューションの使用方法に関するストーリーであるシナリオを記述します。
4. 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を機能コードより先にSprintで構築することはおそらくないでしょう。機能は1つのスプリント内で完全に提供されます。機能に関連付けられたUXが複雑すぎて、機能コードと一緒に単一のSprintで提供できない場合は、機能全体を、UX要素を含め、単一のSprintで実行できる何かに分割します。

ウォーターフォールプロジェクトのUXは誰ですか？XPプロジェクトでメインフレーム開発を行うのは誰ですか？

プロジェクトの方法論は重要ではありません。すべてのテクノロジープロジェクトには、特定の特別な役割が必要です。場合によっては、プロジェクトは、完全にライセンスされ、拘束力のある「インタラクションデザイナー」（それが何であれ）なしに逃げることができます。専門家が必要になることもあります。しかし、他のすべての役割についても同じことが言えます。

それでは、アジャイルを使用して高品質のユーザーエクスペリエンスを提供する方法についての2番目の質問に移ります。私は、ビジネスアナリストと顧客を早期かつ頻繁に関与させることで、私が関わった最後のスクラムプロジェクトでそれを管理しました。また、UXに特に優れた開発者がいました。彼は、開発者がコミットした後、開発者が作業していたUIに小さな調整を加える傾向がありました。

すべてのスプリントの最後に完璧なUXを提供したわけではありません。デモは一般的に、UXの観点から1つまたは2つの問題を明らかにしました。しかし、次のスプリントのためにそれらを修正し（顧客に価値があった場合）、製品版にリリースするまでに、非常に堅実なUXがありました。

UXとは、ユーザーインターフェイスデザイナーを意味する場合、チームのもう1つの役割またはリソースにすぎません。ユーザーインターフェイスの設計は、他の設計と同様に、プロジェクトを切り抜けます。事前に行う必要がある妥当な量のアーキテクチャ/設計作業があり、作業を進めるにつれて実行できる量があります。

UI設計タスクは、多くの場合、開発スプリントと同じスコープに適合しないことに注意してください。UIコンポーネントの設計では、実装に多くのスプリントが必要になる場合があります。

実際には、UI / UXデザイナーは、ソリューション全体で一貫している必要がある側面に対処するために、合理的なリードタイムを必要とする傾向があります。私はそれをソフトウェアアーキテクチャとして考えるのが好きです。特定のコンポーネントの設計は、実装前にスプリントを実行できることがよくありますが、設計者が着手すると、実装のペースをはるかに上回ることがあることに気が付きます。後のスプリントは、ソリューションが具体化し始めると、ルックアンドフィールを実装/探索し、使いやすさのフィードバックを得るのに適した場所になる傾向があります。これらの後半の演習の結果は、次のスプリントの計画にフィードバックされます。