機能とユーザーストーリーに関してアプリケーションの側面をどのように扱いますか？

バックログを作成するとき、エラー処理やフィードバックなどのアプリケーションの側面など、非常に多くのユーザーストーリーに適用されるいくつかの要件があります。これらをどのように含めるのですか（各ユーザーストーリーで#includeディレクティブを使用せずに）？エラープレゼンテーションを機能として扱い、「システムが例外をキャッチし、情報をユーザーに表示する」など、この機能のユーザーストーリーを用意する必要がありますか？

ユーザーフィードバックの処理はユーザーエクスペリエンスにとって重要ですが、アプリケーションのさまざまな部分にさまざまな方法で適用されます。

次の2つの例を見てください。

1つのストーリーは、致命的なエラーが発生する直接的なユーザーインタラクションに焦点を当てる場合があります。モーダルダイアログを使用して、ユーザーにエラーを通知し、回復が不可能であることを通知します。これについての話は次のようになります。「ユーザーとして、データフォームの無効なエントリについて通知を受けて、戻ってこのエラーをすぐに修正できるようにしたい」。このユーザーストーリーは、これが致命的なブロックエラーであり、ユーザーがすぐに修正する必要があることを示しています。

では第二話ユーザーがフォームに必須データを入力し忘れました。ストーリーは次のようになります。「ユーザーとして、必要なフィールドが何であるかがわかるように、エントリの欠落しているフィールドを強調表示したい。」

この微妙な通知は大きく異なり、最初のストーリーと組み合わせて1つの一般的なエラー処理ストーリーにすることはできません。ただし、どちらも内部例外から発生する可能性があります。

ストーリーの「内容」を伝えることが重要であることを忘れないでください。たとえば、特定の状況で対処する必要があるエラーシナリオなどです。エラーの方法（つまり、例外がどこかでスローされている）は、ビジネス上の価値がないため、製品の所有者とはほとんど関係ありません。技術的な観点からは、健全なアーキテクチャを持つことは、私が製品に期待することです。

最後に、あなたは、に焦点を当てることにより、柔軟性と拡張性を獲得するビジネス価値としているだけでなく区切りと小さなユーザーストーリー。

解決策は懸念事項を適切に分離することだと思います。エラー処理、ロギング、フィードバックなどは、1つのコードでグローバルに処理する必要があります。このグローバルな動作とは異なる要件のみを、ユーザーストーリーの一部として、または上記のユーザーストーリーの実装に関する議論の中で注記する必要があります。

したがって、プロジェクト管理の側からは、「ユーザーとして、エラーを管理者に報告できるような方法で見たい」というユーザーストーリーが1つあるはずです。またはそのようなもの。そして、このユーザーストーリーは、すべてのユースケースにグローバルルールとして適用される必要があります。

1つのアイデア（SCRUMから抜粋）：ユーザーストーリーごとに確認する必要があるものは、いわゆる「完了の定義」に含まれています。

通常、「完了の定義」には、次のような技術的なものが含まれます。

• すべてのテストは緑です
• コードは適度にクリーン
• コードは回帰を引き起こさない

ただし、ユーザーに表示されるものを含めることもできます。

• 1秒以上かかるユーザー操作がない、または
• すべてのGUIコントロールはキーボードだけで使用できます

チームは、ユーザーストーリーが完了したと宣言する前に、「完了の定義」を確認する必要があります。

1つのオプションは、この「完了の定義」に適切なエラー処理を含めることです。ただし、他の回答が指摘するように、引用する例（エラー処理とフィードバック）は、「どこでも」適用される要件の実際にはおそらくあまり良い例ではありません。

適切なエラー処理とフィードバックは通常コンテキストに依存するため、必要な場所に対して個別に定義する必要があります。したがって、この場合、マルトの回答で説明されているように、エラー処理を個別のユーザーストーリーとして定式化する方がよい場合があります。