UCDはアジャイルプロセスになりますか？
アジャイルUXに関するすべての議論は、UXアクティビティをアジャイル開発プロセスに調整する方法に関連していますが、開発アクティビティをサポートするアジャイルプロセスにUCDをどのように変換できるかを知りたいです。
アジャイルUCDのアイデアはありますか？
UCDを特徴付ける反復設計は、アジャイルを特徴付ける反復開発と非常によく適合します。設計の反復が開発の反復と一致するようにしたい。
しかしその前に、開発者がコーディングを開始してユーザーの目標と問題点を特定するための予備調査を行い、製品のビジョンを得るために、事前に時間をかける必要があります。しかし、私はお勧めします 研究を完了する前に設計を開始します（自分自身のみ） 。これにより、研究に集中でき、より早く完了します。場合によっては、完了する前であっても、ユーザーの視点から製品の概要を把握し、サポートに必要なバックエンドを開始できるように開発者に渡すことができます。
この基盤が整ったら、開発者の責任者として1つのステップを実行し、ミニデザインを開始し、迅速で汚れたユーザビリティテストでプロトタイプをテストし、落書きされたワイヤーフレームを開発者に渡します。開発の特定の時点で、開発者が作成したコードはプロトタイプであり、開発者と同期しています。その後、ユーザビリティテストは、アジャイルイテレーションの一部である通常の利害関係者のフィードバックの一部になります。その段階で、戦略的な方向性を提供するのではなく、UIを微調整してフェードバックし始めます。
UX/UCDとAgileの適合およびUX/UCDへのAgileの適合の詳細：
アジャイルとスクラムを混同しないことが重要だと思います。この質問に答えるには、UCDについて考えてから、以下の アジャイルマニフェストの原則 を読んでください。
- 私たちの最優先事項は、貴重なソフトウェアの早期かつ継続的な提供を通じて顧客を満足させることです。
- 開発の後半であっても、変化する要件を歓迎します。アジャイルプロセスは、変化を利用して顧客の競争力を高めます。
- 作業期間の短いソフトウェアを優先して、数週間から数か月の作業用ソフトウェアを頻繁に配信します。
- ビジネスマンと開発者は、プロジェクト全体で毎日一緒に作業する必要があります。
- やる気のある個人を中心にプロジェクトを構築します。彼らに必要な環境とサポートを与え、仕事を成し遂げることを彼らに信頼してください。
- 開発チームへ、または開発チーム内で情報を伝達する最も効率的で効果的な方法は、対面式の会話です。
- 動作するソフトウェアは、進行状況の主要な尺度です。
- アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。
- 卓越した技術と優れたデザインへの継続的な注意が俊敏性を高めます。
- 単純さ、つまり行われない作業量を最大化する技術は不可欠です。
- 最高のアーキテクチャ、要件、設計は、自己組織化チームから生まれます。
- 定期的に、チームはより効果的になる方法を検討し、それに応じてその動作を調整および調整します。
個人的に、私はこれらを読んで考えます：
- 彼らが説明するこのチームのデザイナーはいますか？
- 開発者が実用的なソフトウェアを迅速に提供したいと言う前に、デザイナーはどのくらいの時間UIを理解する必要がありますか？
- 情報アーキテクチャの変更は非常に困難です。彼らは本当にゲームの後半に彼らを歓迎しますか？
- これが本当に最高のUXを作り出す方法ですか？
私はMarketoで非常にUCDであり、優れたUXを備えた優れた製品を提供しました。私たちのプロセスはちょっと面倒だった。 アジャイルとは呼ばず、Fragileと呼びました。
私の答えは、開発者はデザイナーではなく、ビジネスマンでもありません。アジャイルは素晴らしいUXの邪魔になりますか？はい、時々。しかし、物事をやり直す能力は重要であり、私はそれを滝と交換するつもりはありません。
これは Waterfallよりもアジャイル手法が好きな理由 を示すグラフです。
昨年ポートランドで開催されたUPA会議で、パネリストが次のように言っているのを聞きました（言い換えれば）。
アジャイルは、開発者にとって古い問題を解決します。間違ったものを提供するのが遅すぎるという問題です。アジャイルはその問題に対処するため、デザインと使いやすさの両方を重要なパスに配置します。開発者と協力して、問題の解決策が問題に対処する必要があることを開発者が理解できるようにする必要があります。
私にとって、この時点から続くのは、アジャイルチーム全体（開発者、QA、その他すべて）がすべてデザインとユーザビリティに共に関与しているか、またはこれを十分に実行できない場合はアジャイルです。プロセスは、できるスペシャリストのための場所を作ります。
-=-ジェローム
UCDプロセスはアジャイルを強化し、それを両側（ビジネス/開発）に成功させることができます。
UX担当者がビジネスと開発の両方に関与し、アナリスト（またはアナリスト）と協力して、ユーザーストーリーに書き込み/参加し、ランク付けされたときに（チームがUXに設定された優先順位を理解できるようにするため）、日々のスクラムに参加して、開発が抱えている問題、開発者が加えたい変更、QAのテストプロセスと問題などに耳を傾けます。それが勝利/勝利の状況であり、アジャイルプロジェクトの成功です。
一部のデザイナーはアジャイルプロセスと闘う場合があります。ピクセルの完全性と逸脱のないことがプロジェクトを成功させるものであると考えるデザイナーですが、実際の競合はありません。アーキテクチャ、データ、コードが調整できるのと同じように、デザインはreqの変更に応じて柔軟に対応できます。
この質問が最初に提起されて以来、業界には間違いなく、より「機敏」で「リーン」なバージョンのUXを採用しようとする変化がありました。たとえば、最近質問されたこの質問は、設計でアプローチと哲学の両方を活用するためにアジャイルとUXのバランスをとる必要性を反映しています： 厳しい締め切りのあるプロジェクトのUXプロセスを最適化するには？
私の質問への回答では、設計目標を満たすために重要ではないUXの実践と方法論を省くことについてであり、質問への私の回答の要約は、ドキュメントとのコミュニケーションを改善し、ワークフローを単純化/合理化することでした。最終目標に。研究とテストがどのように実行されるかは、設計者がどのように想定を行い、それを将来の反復で進めるかによって異なります。
したがって、それは可能であり、おそらく今では一般的な慣行です。