escribir-hus

ユーザーストーリーを書く

目標

プロジェクトのドメイン（医療、フィンテック、小売など）を問わず、PRDを実行可能なユーザーストーリーに変換します。各ユーザーストーリーは、PRDに書かれていない内容を誰かが推測しなくても構築できる必要があります。

入力

• PRD（5つのセクションで構成。形式は一定ですが、ドメインは異なり、決めつけてはいけません）：
  1. 問題
  2. 目標
  3. スコープ（含む／含まない）
  4. 前提と未決事項
  5. 成功基準
• システムがすでに存在し、コンテキストが設定されている場合： docs/contexto/GLOSARIO.md と docs/contexto/CAPACIDADES.md。ユーザーストーリーでは用語集の用語を使い、システムがすでに備えている機能を重複させません。

PRDにセクションがない場合は、プロセスを変えずに対応します（たとえば、「問題」から目標を抽出するなど）。その旨を明記します。

ワークフロー

1. 何も書き始める前に、5つのセクションすべてを読む。 スコープが境界を定め、未決事項がまだ決定されていない内容を示します。
2. スコープに記載された明確な機能を特定する。 各機能を1つのユーザーストーリーにします。複数の機能を巨大なユーザーストーリーにまとめたり、1つのアクションのサブステップごとに人工的なユーザーストーリーを作って細分化しすぎたりしないでください。
3. 解決する前に、セクション間の矛盾を特定する。 スコープ、目標、成功基準の内容が一致しない場合、黙って判断してはいけません。矛盾を記録し、基準を満たすために必要な最小限のものだけを構築したうえで、ビジネス側の確認が必要であることを明記します。
4. 各ユーザーストーリーを assets/hu-template.md を使って作成する。 ストーリー（As a／I want／So that）と、少なくとも2つのGherkinシナリオ（正常系＋エッジケース1つ）を含めます。
5. 複数の機能にまたがるビジネスルール（たとえば、複数の機能に適用される成功基準）は、別のユーザーストーリーにするのではなく、該当する各ユーザーストーリーのエッジケースシナリオとして検証します。
6. PRDで確認されていないデータを、都合よく仮定してはいけません。 未決事項として記載し、ビジネス側に尋ねる質問を正確に示します。
7. 「含まない」と記載されたものは、明らかな改善に思えても追加しません。
8. 未決事項は、明確に該当するユーザーストーリーにのみ割り当てます。 既定で全てのユーザーストーリーにコピーしないでください。
9. ユーザーストーリーごとにMarkdownファイルを1つ作成し、プロジェクトのフォルダーに保存します。

品質ゲート

• PRDの5つのセクションを読んだ（スコープだけではない）
• 各ユーザーストーリーは、スコープ内の明確な機能に対応している。複数の機能をまとめたり、細分化しすぎたりしていない
• 各ユーザーストーリーに、少なくとも2つのGherkinシナリオ（正常系＋エッジケース）がある
• 仮定したデータが、すでに決定済みであるかのように記載されていない
• 「含まない」のリストにある内容が、機能として紛れ込んでいない
• 各未決事項に、仮定を装ったものではなく、ビジネス側への質問が正確に記載されている
• PRDのセクション間の矛盾が、黙って解決されずに記録されている
• システムのコンテキストが設定されている場合、用語集の用語を使い、機能を重複させていない
• ユーザーストーリーごとにMarkdownファイルを1つ作成し、プロジェクトのフォルダーに保存した

参考資料

• assets/hu-template.md — ユーザーストーリーのテンプレート。
• references/ejemplos-aplicados.md — 過去のプロジェクトで解決した事例（スコープの矛盾、未決事項、他のエージェントが提案したスコープ外の項目）。