it-swarm-ja.com

開発プロセスのどの時点でUXがアジャイル作業環境で機能する必要がありますか?

UXとアジャイル開発プロセスがうまく連携している成功例は何ですか?従来のアジャイルは通常それを説明しません。

22
Christie Day

UXは、プロジェクトに関係する他のすべての分野とともに、初日から関与する必要があります。チームは、できる限り互いに並行して作業するように努める必要があります。これを達成するには、UXリソースがすべての毎日のアジャイルの儀式と会議に参加することが不可欠です。これは、バックログのグルーミングと優先順位付けに特に当てはまります。さらに、チームのUXリソースは、設計プロセスをチーム全体に開放し、開発者、製品マネージャー、QA、マーケティングなど、どこからでもアイデアやアイデアを得ることができるようにする必要があります。

これらのグループブレーンストーミングセッションを介して、UXデザイナーはデザインのファシリテーターおよびスチュワードになります。彼らの目標は、チーム全体で共通の理解を構築することにより、製品のビジョンを伝えることです。この共通の理解は、初期のデザインアイデアに関する定期的な会話とディスカッションによってもたらされます。これらのアイデアは、顧客と利害関係者との間で頻繁に検証して、チームが適切なソリューションの改良と構築に時間を費やしていることを確認する必要があります。別の言い方をすれば、チームは、間違ったソリューションの追求に費やす時間を最小限に抑える必要があります。

リーンUXは、このアジャイルUX統合問題を解決する1つのアプローチです。リーンUXで支持されたアイデア(少なくとも私が定義したとおり)では、UXデザインチームは、以前よりもはるかに透過的な方法で作業する必要があります。さらに、彼らが採用するプロセスは、従来の設計方法よりもはるかに包括的でなければなりません。これらのプロセスは、ホワイトボードスケッチ、大まかなワイヤーフレーム、体験のプロトタイプ(最終的には製品の「仕様」になる)などの「軽い」成果物(存在する場合)の形で現れます。

Smashing Magazineのために私が書いた記事には、さらに詳細な説明があります Lean UX:Getting Out Of the Deliverables Business

14
Jeff Gothelf

純粋なUXリサーチ、戦略、デザイン会社を経営しているため、私の反応は偏っているかもしれませんが、UXの実践者として、私たちは最初からアジャイルプロジェクトに携わっています。 zsiberianが述べたように、プロセスを俊敏に保つ唯一の方法は、スプリントを1〜2スプリント早く進めることです。反復計画セッションでのUXの関与により、ユーザーストーリーの定義をフロントエンドの開発よりも先に進めることができます。私たちの経験では、開発がさまざまなバックエンドを識別して立ち上がっているときに、概念/相互作用モデル、ブランディング/ビジュアルデザインコンセプト、および最初の1-2ユーザーストーリー(ワイヤ)をクランクすることで、開発に1-2のスプリントジャンプをもたらしますテクノロジー/アーキテクチャ。お役に立てれば。

12
Jon Fukuda

アジャイルはさまざまなフレーバーで登場するようですが、理論はすべて同じであり、その理論に基づいて、UXは1日目からのミックスの一部です...ビジネスラインの所有者、顧客、IT、マーケティングなどもそうです。

私は通常、UXがウォーターフォールを実行しているが、開発者がアジャイルに移行しようとしているときに問題が発生することを発見しました。多くのUXチームは、まだワイヤーフレームの山をポンプで送りたいと思っています。これは、アジャイルの本来の姿とは正反対です。

開始するのに最適な場所は、グーグル「リーンUX」とそれらの概念のいくつかを読んでみることです。私の意見では、「リーンUX」は「アジャイル」をブランド化してUXチームが受け入れられるようにする賢い方法です。

9
DA01

UXの役割がアジャイル(この場合はスクラム)の開発のどこに介入する必要があるかについて、私が非常に適していると思うアプローチは次のとおりです。

  • 製品のバックログで、エンドユーザーのフィードバックを仕様に変換します。
  • スプリント計画会議では、モックアップを提供して、チームとプロダクトオーナーの両方が、何がどのように構築されるかについてより良いアイデアを持つようにします。
  • 完了した各タスクの最後に、テストまたは単体テストが実行される場合、ユーザビリティとUXもテストする必要があります。
  • レビューミーティングでは、全体的なUXをテストし、次の増分について考慮します。

The role of UX in Scrum

多くの SlideShareのUX + Agileに関するプレゼンテーション が見つかります。

5
Naoise Golden

私自身の経験から、開発の前後で並行ストリームで作業します、そしてそれを文字通りアジャイル開発ではまったく受け取らない場合、.

どうして?私の理解では、私たちの会社で行うスクラムは、反復的な生産と開発に関するものだからです。しかし、タスク自体はそうではありません。あなたは単一のタスクを取り、それが完了するまでそれで作業します。次は。それがコーディングの仕組みです。あなたが言ったように伝統的なアジャイルは通常それを説明しません。

ただし、タスクに反復があるため、デザインは異なります。それで、私は自分がタスクカードで作業し、それをToDo列(スクラム)に戻し、最終的に完了するまで、それをさらに改善するなどの作業をしていることに気付きました。 (実際には、私は1日でデザインを完了できないので、それが私のやり方です。数日後に新しいビューを表示したいのです。)したがって、デザインではタスクの反復がありますが、スクラムでは不可能です。また、ナオワーズのスキームをよく見ると、スクラムスプリントに最初と最後だけのUXデザイナーは表示されません。

ほとんどのデザイナーが並列ストリームで作業するのはそのためだと思います。デザイン用のスクラムボードでも作業できるかどうかはわかりません。デザインはまだ小さな滝です。自分が何をしているのかを考え、知る必要があります。全体像を垣間見る必要があります。ただ行うだけでなく、考えて試す必要があります。小さな、とても鮮やかな滝としましょう。

私はそれをうまく実行するためにいくつかの問題を抱えていました(小さなチームで働いています)と現在私はアジャイル環境での設計に最も適していると思います 、まだ試していません。デザインと開発の両方の作業プロセスをマージしたり、デザイン専用のかんばんボードを開いたりできるので、かんばんが好きです。かんばんとスクラムはかなり近いですが、主な違いは、TodoとProcessだけでなく、必要なだけ列を配置できることです。 enter image description here

ここに、分析、Raw Design、Fine Design、Testing、Productionなどの列を配置して、デザイナーワークフローのスコープを設定できます。

かんばんリンク: かんばんとは および かんばんとスクラム-両方を最大限に活用 画像ソース後者のPDF。

この答えは、このかんばんのものとは少し話題から外れそうです。しかし、そのアジャイルおよび開発/設計プロセスも同様です。

5
FrankL

理想的には、UXリードが潜在的なクライアントとの最終会議に招待され、SOWをレビューしたときに、機会追求の最終段階から早く開始する必要があります。それは2つの重要なことを行います。スコープについての会話であなたに発言権を与え、それは後にプロジェクトとそれが何をするかについての頭を与えます。

クリスティ-「開発プロセス」について具体的に質問されたのは承知していますが、そのようなことは、ディスカバリー(6〜10週間)を経て、アプローチと1〜2を維持するためのいくつかの高レベルの配線をすでに実施していることを意味します先にスプリント。

開発が始まるまでに状況が把握できたら、それはアジャイルではなくなります。開発チームより先に進むには、かなり高速に実行する必要があります。

1
zsiberian
1
zsiberian

最初は、標準のux設計プロセスをかんばんに合わせるのが難しいと感じていましたが、しばらくしてから機能し始めました。ただし、変更や再考にはかなりの時間がかかりました。

これは私にとって少しインスピレーションでした: http://kanbantool.com/blog/kanban-for-ux-design

0
paulchalmers

エージェンシーから来たアジャイルは、私にとって新しいコンセプトでした。しかし、アジャイルショップで6か月以上経過した後、それが揺らいでいるのは、ワイヤーフレームと要件を前面に出そうとすることです(私は、開発チームよりも1か月から6週間ほど進んでいます)。キックオフミーティングがあり、私はDesignとDevから多くのフィードバックを受け取ります。別の1、2回の繰り返しで、それらのドキュメントがスプリントの基礎を形成します。リリースがアルファ版になった後、レビューの期間があり、通常はいくつかの修正WFがあり、さらに開発が進んでベータ版、QA、最終リリースに進みます。

軽量プロジェクトは、それに応じて「リーン」なドキュメントを取得します。

0
RobC

Xは初日から積極的にテストする必要があるものです、そして製品の開発中もテストを続けます。

注意!UXテストを忘れるのは非常に簡単です開発者を激しく押し込んでいる間、誰もがチームで地獄のように働いています。

Xテストは完了の定義の一部である必要があります! UXテストが完了していない場合、「ストーリー」を完了と見なすべきではないことを意味します。 (明らかにバックエンドストーリーに必要なメモ)

社内にデザイナーやUXエキスパートがいない場合。自分で行う必要があります。 UXについてはたくさんのすばらしいリソースがオンラインにあるので、Googleは地獄が好きです。

最近、スムーズなUXは差別化要因ではありません。新製品には必需品です。だからあなたのビジネスを壊すことができます!

0