質問: ユーザーストーリーではなく、アジャイルでuxの「非ストーリー」をどのように記述しますか マネージャーから、これから開始するプロジェクトの1つ以上のuxストーリーを作成するように依頼されました。 uxストーリーでは、ユーザーストーリーについては言及していません(つまり、会計士として、請求書を支払うことができるように小切手を書きたいと思っています)。また、ux tasksについても言及していません(例:リサーチ、ワイヤーフレーム、使いやすさ、ビジュアルデザインなど)。他のストーリーが実際に依存している「非ストーリー」(開発研究や技術的負債のようなものをキャプチャするため)について聞いたことがありますが、uxストーリーがこのカテゴリに当てはまるかどうか疑問に思いますか?uxストーリーをアジャイルプロセスの一部として文書化している人はいますか?もしそうなら、コンポーネントを提供し、例を挙げて説明できますか?
回答: スパイク、バケツ、非ストーリーなどと呼ばれる、アジャイルでこのように作成されたさまざまな例外をたくさん見ました。これは実行可能です。基本的には時間の割り当てにすぎません。見苦しいのは、多くのタスクを実行するのにかかる時間を考慮して膨大な数のストーリーポイントを割り当てた場合です。その後、スプリントのかなりの部分が進行中のものになります。一度にすべてを実行する-バーンダウンのポイントを本当に打ち負かします。この方法でやりたい場合は、ストーリーポイントとして追跡しないでください。その背後で、アジャイルユーザーストーリーに美しく統合されたuxとuiも目にしました。そのためには、設計プロセスを小さなパーツに分割する必要があります。以下のログインプロセスの例を試してみます。架空のインターフェースについてはすぐにやっているので、完璧ではないかもしれません。詳細ではなく、アイデアを取り入れてください。 ユーザーがインターフェースを操作するさまざまな方法を理解できるように、ログインプロセスの忠実度の低いワークフローを希望します。 (タスクには、ラピッドプロトタイピングセッション、廊下のテストなどが含まれます)。 開発者がログインページでこれらの要素をフォーマットする方法を理解できるように、テキスト入力のスタイルガイドに標準を追加してください。 開発者がログインページでこれらの要素をフォーマットする方法を理解できるように、ボタン入力のスタイルガイドに標準を追加してください。 エラーメッセージのスタイルガイドに標準を追加してください... ログインメッセージ用にコピーを決定してください。 忠実度の高いプロトタイプのユーザビリティテストを実行したいと思います。 等々。これらはかなり細かいですが、私は知っていますが、私の経験では、これは本当に報われました。これは、チームの他のメンバーと利害関係者がこのアプリケーションに何を入れているかを確認するのに役立ちます。これは、チームがスプリントで提供した価値を示すときに非常に意味があります。この種のチーム統合は、アジャイル。編集:言及するのを忘れていました。このように分解することで、チームが前進するために提供する必要がある部分を選択するのにも役立ちます。これにより、短期間で不合理な量の作業を行うように求められる状況を回避できます。開発者が「uiの担当者がまだ終わっていないので、行き詰まっている」と言った回数を数えることはできません。彼らはジャークではありません。彼らはあなたに完全なuiを完成させるように求め、彼らは何かを始める前にすべてを待っています-彼らは自分たちが何をしているかを理解するのに十分なデザインを理解していません。このアプローチは、チームの他のメンバーと同じ条件で作業するのに役立ちます。