一歩先を行くUXデザイナー

UXデザイナーは通常、開発者がSprint X + 1で実装するSprint Xのストーリーを持っています（UXデザイナーと開発者/テスターは1つのチームに所属しています）。これは理にかなっていると思います。スクリーンモックアップと明確な仕様がなければ、スプリントプランニング中に作業を実際に見積もることができないからです。

ただし、スクラムでは、ユーザーに価値を提供するユーザーストーリーのみが想定されています。私たちの場合、UXデザインストーリーはそのような価値を提供しません（バックロググルーミングアクティビティに似ています）。また、通常、スクラムのコーチは、スプリントの開始前に完全な仕様を持つことを推奨しません。

それで、私たちのアプローチには欠点がありますか？うまくいくように思えますが、スクラムの原則にいくらか反しています。

ただし、スクラムでは、ユーザーに価値を提供するユーザーストーリーのみが想定されています。

値は、出荷可能なコードの行だけで測定されるわけではありません。

あなたは、うまく設計されたUIを持つことは何の価値ももたらさないことを暗示しているようです。もちろんそうです。明らかにエンドユーザーには価値がありますが、開発チームにも価値があります。これは完全に有効な利害関係者です。仕事をするためのツールや資料がない場合、エンドユーザーに価値を提供することはできません。

スクラムの教義にこだわらないでください。スクラムはあなたをより効率的にするためのものです。UIを実装する前に1スプリントでUXストーリーを実行することで、より優れたソフトウェアを提供できる場合は、実行してください。

主な欠点は次のとおりです。

1. あなたはパイプラインです：デザイナーが遅れると、開発者は仕事をせずに放置されます。開発者が遅れると、最終的に設計者は複数の反復を事前に行います。安定した状況ではありません- 持続可能ではありません。

2. デザイナーは事前に作業を行っており、開発される可能性のあるストーリーとそうでない可能性のあるストーリーのコストを負担しています。めったに起こらないとしても、あなたはまだお金を捨てています。

3. UXデザイナーは、開発者が関与することなく、事前に決定を下しています。有用な洞察を失い、設計がまったく間違っているか非現実的であるというリスクを高めています。UXデザインは「抽象的な」演習ではないため、これは非常に一般的です。アプリケーションの特性（技術的に実行可能/推奨されるものを含む）から作成する必要があります。

4. 開発者を除外または無効にすることは、プロジェクトを実行するための持続可能な方法ではありません。

5. デザイナーは価値を提供していません。これは、不可能ではないにしても、作業の優先順位を正しく設定することが難しいことを意味します。通常、開発者の作業は、さまざまな懸念、価値、次のスプリントでの実現可能性、労力を使用して優先順位が付けられます。多くのタイムストーリーは、それらを「適合」させるため、または有益な議論のためにネゴシエートおよび変更されます。このいずれかがUIを変更する場合（および単なる実装の詳細でない場合は、それを行うことができます）、あなたは何をしますか物語で？もう再生できません。

6. デザイナーにとって1つの反復に収まるストーリーは、開発者にとっては1つの反復に収まると想定しています。この想定が正しいようにストーリーを分割するにはどうすればよいでしょうか。

私は2つの理由でそれが好きです：

1. それはあなたのために働くようです; 成功して議論するのは難しいです！
2. UXチームがストーリーを取り上げて、会話を早期に開始します -会話はストーリーのポイントのようなものです

スクラムの基本的な要件は、スクラムチームがリリース可能な製品を作成するために必要なすべてのスキルを持っていることです。あなたが説明する状況では、これは起きていません。

UXチームはリリース可能な製品を生産しておらず、スクラムチームは必要なスキルをすべて備えていないため、機能の垂直スライスを生産できません。これらは機能不全です。

Sklivvzは、上記の機能障害が引き起こす可能性のある問題について優れた記事を書いています。要約すると、私はあなたがスクラムを練習しているとは思わない。

しかし、それはまったく悪いことではありません。すべての人に価値をもたらす働き方を発見し、それで満足しているなら、それを続けてください。私の唯一のアドバイスは、頻繁に検査して適応することです。

ただし、スクラムを使用してソフトウェアを配信することが目的の場合は、特定された機能障害に対処する必要があることに注意してください。

ここには2つの問題があります。1つはユーザー中心の設計に関する問題、もう1つはスプリントの配置に関する問題です。

最初：ユーザーストーリーは、バックログだけでなく、ユーザーのニーズに合わせて調整する必要があります。UXストーリーには、ユーザーにとって明確な価値が必要です。これには完全な仕様と、次のような短い説明は必要ありません。

「ユーザーは、複数のページに分割するのではなく、単一のページでアカウントアクティビティに簡単にアクセスできます」

さまざまな実装に柔軟に対応できますが、ユーザーにとっての価値についてはまだ明確です（アカウントアクティビティへのより簡単なアクセス）。

2番目：スプリントの位置合わせ。UXは、開発者がSpring X + 1で実装するスプリントXの機能を設計します。実際には、これは多くのショップで発生し、スプリントX + 2またはX + 3での実装に似ている場合があります。緊密で経験豊富なチームで、このセットアップは機能します。新しいチームや、チームの他のメンバーのスキルセット、好み、習慣、ワークスタイル、傾向に精通していない新しいメンバーがいる場合は、困難になります。6か月未満で共同作業をしている場合、これは問題になる可能性があります。

一歩下がって、再評価してください。良い面としては、UXデザイナーと開発者が並んで働いていることです。これは恩恵です。ストーリーがユーザーにとって明確な価値を持っていることを確認することから始めます。

私が見る可能性のある問題の1つは、スクラムでは、スプリントN + 1のスコープが通常、開始直前に決定されることです。それでは、どのストーリーがスコープに入るかを知る前に、どのようにしてスプリントNのスプリントN + 1ストーリーのUXを行うことができますか。スプリントNの開始時にスプリントN + 1のスコープを修正する場合、柔軟性が失われます。

ただし、スクラムでは、ユーザーに価値を提供するユーザーストーリーのみが想定されています。私たちの場合、UXデザインストーリーはそのような価値を提供しません（バックロググルーミングアクティビティに似ています）。

私の見方では、彼らはユーザーに多くの価値を提供しています。問題は、ユーザーは会社の最終ユーザーではなく、スプリントX + 1の機能を実装する開発チームであることです。

プロセスの宗教にとらわれており、スクラム/アジャイルが誤用され、ユーザーが誤ってラベル付けされているのを私は見ています。スクラムは普遍的なツールではなく、目的を達成するための手段です。

あなたのグループはあなたのユーザーが誰であるかを誤ったラベルで示し、間違った聴衆のために計画していると思います。

UXグループは、古典的な方法でスクラムを使用し、ユーザーの価値と魔法のエンドユーザーからの入力への俊敏な適応を行っています。ユーザーがいるものです。既存の設計を機能させるためにメカニックを埋めているだけで、アジャイルは必要なく、スクラムが管理追跡の役割を果たしているため、グループはスクラムを誤用しています。

これがあなたにとって間違っていると感じる理由です。あなたはサービスグル​​ープに属し、すでにアジャイル/スクラムパートを行ったUXの人々から作業が進められるため、実際にはスクラムを必要としないか、実際にスクラムの恩恵を受けません。

そこには本当に悪いことは何もありません、あなたが言われたものとは異なるプロセスだけが整っています。