it-swarm-ja.com

アジャイルスクラム:完了の定義に入る詳細レベルを最小限に抑えるためのフレームワーク?

ユーザーストーリーの受け入れ基準は、ユーザーストーリーの不可欠な部分です。徹底的に行わないと、受け入れ基準は、開発タスクの不適切なシーケンスやチームによって提供された誤った見積もりなどの一連の問題を引き起こす可能性があります。同時に、これらの満足条件を定義するための練習は、時間がかかり、反復的です。

受け入れ基準を定義するために必要な詳細レベルを最小限に抑えるのに役立つフレームワークをどのように作成できますか?

インタラクションデザイン、アクセシビリティ、情報キャプチャなどの領域にパターンを確立することにより、このフレームワークのさまざまなコンポーネントを定義することを考えています。これは、実行する必要があることを伝える効率的な方法ですか?

これにより、開発チームとUXチームの間で共通の理解が生まれますか?

この問題に対処した経験のある人は誰ですか?

私の目的は、何らかの形で理解を共有し、ドキュメントを減らし、時間の使用を最適化し、物事を成し遂げることに集中することです!

5
Okavango

これは実際には、全体的な企業プロセスの問題ほどフレームワークの問題ではありません。組織が大きくなるほど、必要となるドキュメントと詳細が多くなります(これはアジャイルプロセスとは対照的ですが、私は割愛します...)

それは言った...

インタラクションデザイン、アクセシビリティ、情報キャプチャなどの領域でパターンを確立することにより、このフレームワークのさまざまなコンポーネントを定義することを考えています。

それは素晴らしいアイデアであり、一般的なものです。 「パターンライブラリ」は、UXチームにとって不可欠なツールです。個人的には、UXが生み出した、ROIが最も高いドキュメントの1つだと感じています。

ただし、これは受け入れ基準の幅をカバーしないことに注意してください。パターンライブラリは、一貫した相互作用と視覚的なデザイン(どちらも非常に重要)を処理するためのものですが、必ずしも受け入れ基準の唯一のビットとは限りません。

私の純粋に個人的な意見であり、研究に裏付けされていない(したがって、すべてを非常に詳細に検討する)のではなく、許容基準はアジャイルプロセスと同期して記述する必要があるということです。

言い換えると、受け入れ基準の作成はアジャイルプロセスの特定の手順ではなく、アジャイルプロセスが展開するときに発生することだけです。

シナリオ例:

  • ユーザーストーリーが書かれている
  • UXがスケッチを開始
  • UXが利害関係者(IT、ビジネス、プロジェクト管理など)と連携するにつれて、受け入れ基準が具体化し始めます。
  • スケッチプロセスが続くにつれて、ACも同様に改訂されます。
  • 開発は、次のスプリントで実装される機能をピックアップします。
  • 春の間、ACは必要に応じてさらに改訂されます。
  • スプリントの最後に、開発された製品がACに適合しているというコンセンサスに到達する必要があります。これが私にとって重要ですACが開発された製品に適合している

つまり、ACは最後までスケッチプロセスの一部です。彼らは解決策を指示せず、解決策もありません。彼らはパートナーであり、具体化されるソリューションと一緒に働きます。アジャイルプロセスが最後まで進み、スプリントの最後に何かが配信されるまで、これらの問題は解決されません。その時点で、ACは「統合」され、通常はQAチームに引き渡されます。

4
DA01