ユーザビリティテスト時に、アジャイルプロジェクトでスコープクリープを防ぐにはどうすればよいですか。
最近この問題について私に尋ねたクライアントがいます。あなたはそれをどう処理するのだろうと思っていましたか？
それらはUXとアジャイルメソッドにとって新しいものであるため、興味深い方法で苦労しています。
最近のプロジェクトの一環として、スプリントにユーザビリティテストをいくつか追加しました。彼らはこれまでにユーザビリティテストを行ったことはなく、その結果、設計に多くのユーザビリティの問題が発見されました。
しかし、彼らが見つけた問題の多くは、プロジェクトの本来の範囲外でした。 UXチームのメンバーは、プロジェクトのバックログに多くの問題を追加することを必死に望んでいましたが、配信を遅らせたくない製品の所有者からの抵抗をすぐに見つけました。その結果、UXの人々は、製品の所有者が優れたユーザーエクスペリエンスを気にしていないと感じました。
私の質問は、この問題をどのように回避できたのでしょうか。私は当初、チームがプロジェクトの範囲内にあるものとそうでないものをより明確に定義し、将来のプロジェクトの範囲外のユーザビリティの問題を記録する方法が必要であることを示唆していました。
どう思いますか？
私はプロジェクトでこの正確な問題に遭遇しました。チームの全員がすでに製品を出荷するための限界に達しています。たとえば、特定の国際的なイベント（たとえば）の前に製品を出荷することが重要です。したがって、開発ライフサイクルの遅すぎるUXレビューでは、誰も予想していなかった重大な問題が発生します。何をすべきか、そして次のプロジェクトで学ぶためにそれをどのように回避できたのか。
スコープのクリープを防ぐために、継続的なスコープの再評価と優先順位付けのプロセスが必要です。変更、時間、およびリスクの評価は、機能の影響とほとんどのユーザーの経験に対する影響とともに行う必要があります。そして、誰もが無視されていると誰もが感じないように、正確にこれに参加する必要があります。
さらに、それはリリースに何を入れるかを管理する方法だけでなく、の後の次のステップを管理する方法（== --- ==）です。次のバージョンの機能をdeferするdrop機能。 「はい、多分あなたは最初に機能リストにあったものを手に入れていませんが、結局のところ、最終的にはより良い製品を手に入れている」という問題を乗り越えたら、関係者の考え方その結果、チームの全員が大幅に改善できます。
そのため、これがアジャイル開発の目的である1日目から関係者の賛同を得るのに役立ちます。適応、反復、改善。 目標は、できる限り最高の製品を入手することです-機能のリストにある一連のチェックボックスをチェックしないでください-機能ごとに支払いを受けることはありません！
問題がその日の遅くに発生した場合、それは本当にパニックになる時間ではありませんです。実際には反対です。 「再設計せずに調整」する時が来ました。最もリスクが少なく、最も迅速な変更に対する最大の影響。
UXレポートは、たまたまスコープの再評価を行うのに適しています。 シナリオの問題は、それがshockとして来ることです-ヘッドライトにうさぎが捕まったようなものです。ショックではありません。製品を作成するために組み合わされるすべてが、ユーザーエクスペリエンスの一部を構成します。他の場所で他のあらゆる種類のテストが行われている可能性があるのに、なぜそのテストを最後まで残しておくのですか。
可能性としては、実際には非常に簡単な一連の変更があり、これらは本当に簡単なものです。可能性としては、機能の一部が未完成または危険な領域が既に存在し、これらが実際にユーザーのエクスペリエンスにless値を追加することです。印象」や「サインアップ」フォームなど、投げられたもの。妥協が必要になることは間違いありませんが、それはコースの標準に過ぎません-妥協する必要がなかった1つのプロジェクトを見せてください。
今日私が目にする最大の問題の1つは、企業がユーザーエクスペリエンスのメリットとそれがユーザーとその製品に与える影響について教育する必要があること、そしてXの検討は0日目から開始する必要がありますです。十分に速く変化していません。みんなのための無料のUXゴーグル、それが私の考えです。長い答えをごめんなさい:-)
「0日目から始まるUX」の+1.
[私は開発者であり、UXの人ではないので、細かい注意点があるので、UXの観点から何が行われるか/何が行われる必要があるかについて少し単純に理解しているかもしれません]。
私はUXの人々がチームの不可欠な部分であり、うまく機能していると思われるいくつかのことをしているアジャイルチームに取り組んできました。
初期のUXの関与
多くの場合、インタラクションデザイナーは、バックログを1つまたは複数のスプリント（現在の速度に基づく）に「調べて」、UXがどうあるべきかについて考え始めます
今後の「ストーリー」に関する初期のUX /開発/製品所有者の会話
これは、バックロググルーミングセッション中に行われました（スクラムを使用しました）。チーム全体は、少なくとも前のスプリントでバックログを調べます。 POやUXがストーリーの説明に役立ちます。 UXには、UIのワイヤーフレームが含まれている可能性があり、やり取りをチームに説明します
初期のユーザビリティテスト
可能な限り早期にテストを開始する場合は、現在のスプリントのahead。はい、これは機能しているアプリケーションでテストしないことを意味します。低fiクリッカブルワイヤーフレームまたはモックアップを作成してみてください。私は、htmlを使用して、少なくとも最初のユーザビリティの感覚を得るのに十分な主要なインタラクションを備えた、ストリップされたUIをワイヤリングしたインタラクションデザイナーと協力してきました。 Balsamiqのようなツールを試してみてください。紙でテストをしている人も見ました（「どこでxを期待しますか？」）。
代替案を見積もる
この「グルーミング」プロセスの一部として、開発チームは、記述されているものを推定またはサイジングする責任があります。多くの場合、UXは複数の選択肢を提案し、devは各オプションを推定します。 POを交渉する可能性が低くなるのは、オプションがないという感覚に他なりません。
延期のコストを見積もる
これは、POに延期されたUX関連のストーリーを優先順位を上げるよう説得しようとする場合に役立つアプローチです。開発チームと協力して、延期のコストを見積もります。物事は、多くの場合、前に直面するよりも、後で再実行する方がコストが高くなります。何かを今実行するコストと後で実行するコストの見積もりを試してください。これは、POが「後でやります。今は機能に集中する必要があります」と言った場合にプレイするカードです。後でPOにいくらかかるかを伝え、ボールは彼/彼女のコートにあります。
これは通常、POを操作するときの私の戦略であり、宿題を出し、オプションを提示し、それらが正しい選択をすることを信頼します。
スクラムチームの場合、チームでのコラボレーションを促進することはスクラムマスターの仕事であることを付け加えます。チーム（POを含む）としてチームがよりよく機能するのを支援する方法を積極的に探しているはずです。
したがって、短いバージョン：early、early、early、estimate、estimate ：p
私が働いている会社では、XチームはPRDの作成を担当していますで、これはエンジニアリングチームへの要件の詳細な計画です。これは、UXチームが（最初に）物事をうまく設計する機会を得たことで、問題を回避するのに役立ちます。
問題が見つかると、ロードマップで問題を把握するのが非常に難しいことがわかりました（質問で気づいたように）。私は文字通り4年間待って、UXで私（およびユーザー）を夢中にさせる特定の問題を修正しました。問題はリリースを滑らせていませんでした、問題はまったく修正を得ています。通常、修正はコンポーネントをやり直すまで待機します。
これは"1オンスの予防は1ポンドの治療に値する"の場合です。
最後に考えたのは、ある時点で、ユーザビリティテストは品質保証のようなものだと言いました。バグレポートを作成しましょう。エンジニアは牛を飼っていました。 「私たちのコードは間違っていなかった、あなたのデザインは間違っていた！」うん。
実際、Rogerが述べているように、UXチームは「0日目」から開発チームに参加していなかったようです。あなたは1つのチームであり、一緒に機能を作成する必要があります（すべての必要な分野）。これにより、テスト中に発生するユーザビリティの問題は軽減されますが、おそらく解消されません。 UXも戦略設計に組み込まれている必要があります。
もしそれが私だったら、スプリントにユーザビリティテストタスクを挿入し、ユーザビリティから外れたもののためのユーザビリティ修正タスクも挿入したでしょう。これは全体的な速度を低下させますが、それは現実です。
別の方法は、ユーザビリティフォールアウトストーリーを取り、それらをバックログに置くことです。これは、製品所有者の責任です。誰かがこれらのものをバックログに入れるのを止めないでください。多くのアジャイルチームでは、誰でもバックログに追加できるようになっています。最も重要なものが最初に来るように、バックログのアイテムに優先順位を付けるのはPOの仕事です。しかし、彼らは製品のROIに責任があるので、それはPOの決定です。
Jaredは agile-usabilityメーリングリスト でもこれを尋ねました、そして人々は興味のある そこに返信 を見つけるかもしれません。オースティンは特に含まれています いくつかの非常に素晴らしいヒント 。
Jaredへの私の返信には、興味のある人のために以下が含まれています。
アジャイルに固有の問題ではありません。使いやすさのテストに間に合うように予算を組んでいる人の数に驚いていますが、その発見は魔法のように追加の作業なしで統合できると期待しています:-)
あなたの最初の提案は良いものだと思います。チームでユーザーテストを開始する前に、実装の可能性と不可能を理解します。これには2つの理由があります。
1）結果で行われることの両側に期待を設定するのに役立ちます。ですから、私の賢明なアドバイスが無視されていることにイライラすることなく、現在のリリース計画の範囲では修正できない一連の高レベルの問題がチームに与えられていません。
2）UXリソースをより的確にターゲティングできます。機能Fooを完全に再実装する時間が現実的ではないことがわかっている場合は、代わりに機能バーをより多くの時間を費やすことができます。または、他の場所で優れたUX作業を教える/促進することにもっと時間をかけることができます。
チームにUXを評価してもらう際に、すぐに対処できるアドバイスを提供することでmuchより効果的であり、そのアドバイスの価値をすばやく確認できます。価値を示し始めると、より大きな問題への対処について合意を得るのがはるかに簡単になります。
ユーザビリティテストが最終製品にどのように影響するかについて話し合うことは、いくつかの興味深い場所につながる可能性があります。
たとえば、製品開発チームがより機敏になる必要がある状況を強調する場合があります。
リリース計画はどのように修正されていますか？正当な理由で修正されていますか？新機能Fooは、機能バーの修正よりも本当に重要ですか？ Nか月前にリリース計画に同意することは、より優れた製品の構築に役立ちますか、それとも妨げられますか？
ユーザビリティテストの結果がどのように適合するかについての会話は、プロセス全体、完了の定義、および機能の優先順位付けについて、はるかに大きな議論になる可能性があります。
このより大きな会話は有用で良いですが、次の数回の反復のコンテキストで実行可能な短期の問題に対処するのに邪魔になる場合があります。特に、クライアントのように、大きなユーザビリティの負債に直面している場合。
最初に小さな問題に対処します。彼らが助けることを示しなさい。その証拠を燃料として使用して、より大規模な問題への取り組みを推進します。
乾杯、
エイドリアン
発生した問題をバックログに追加すると配信が遅れる理由を私も理解していません。確かに、バックログのすべてを一部のリリースに追加する必要があると言っていることは何もありません。
ただし、発見された問題に対処することで追加されるユーザーの価値を正直に評価します。製品により多くの時間を費やすことは常に価値を付加する必要がありますが、その付加価値は、他の機能を落としたり、納期を押し上げたりするコストと比較検討する必要もあります。製品の所有者には、これらの新しいストーリーと既存のストーリーの相対的な価値を比較検討し、それに応じてプロジェクト計画を調整するのに十分な情報を提供する必要があります。もちろん、すべての問題がバックログにある場合、これらの相対値の比較ははるかに簡単です。
アジャイルメソッドを使用する主な目的の1つは、このような状況を問題のないものにすることです。最初のリリースにならないものはすべてバックログに追加でき、（おそらく）開発して後のリリースでプッシュできます。ベン・ライスも述べたように、バックログへの追加はリリース日を危険にさらすべきではありません。
Roger Attrillや他の人たちも述べたように、UXテストは最初からプロセスの一部である必要があり、機能テストと密接に関連している必要があります。 UXテストを実行するために活用できる多くのさまざまな手法と方法（その多くは社内で処理できます）を使用すると、実際にそれを行わないための良い言い訳はありません。
製品の所有者が（機能テストではなく）UXテストで発見された問題をバックログに追加したくない場合は、valueテストの結果ではないようです。そのため、手続き上の問題ではなく、より文化的/政治的な問題になる可能性が高く、疑問を投げかけます。なぜ最初からUXテストに悩んだのでしょうか。