export-backlog

reports/の内容をもとに、Epic・Sub-Epic・Issueを作成するスキルの説明

入力: reports/ディレクトリ(フォルダ)に入っている、すべてのドキュメント。product・architectのどちらのパイプライン(処理の流れ)で作られたものでも使えます。

出力: 次の3つです。

reports/backlog/backlog-plan.md: 人が読むための計画書
backlog-manifest.json: プログラムが読み込むためのデータ
実際に作られるGitLab/GitHubのIssue(課題)群

コマンドと主なオプション

/architect:export-backlog [--provider=gitlab|github] [--project=<path>] [--dry-run] [--yes] [--lang=en|ja]

オプション	意味
`--provider`	使うトラッカー。省略時はリポジトリのリモートURLから自動判定する
`--project`	対象プロジェクト。GitLabは`group/subgroup/project`、GitHubは`owner/repo`
`--dry-run`	Issueを1件も作らず、計画書(`backlog-plan.md`)だけを出力する
`--yes`	計画書の承認を省略してそのまま作成に進む
`--lang`	Issue本文やレポートの出力言語

初回は--dry-runを付けて計画書だけを確認し、内容に納得してから付けずに実行するのが安全です。

マッピングモデル

Epic・Sub-Epic・Issueという、はっきりした3段階の階層に当てはめて整理します。

Epic(大きな作業)— 「何を」「なぜ」やるか: 基本的に1つだけ作ります。プロダクト全体を、なぜ・何のために立ち上げるのかを書きます。
Sub-Epic(中くらいの作業)— 「何を」やるか、KR(達成度を測る具体的な数値目標): 機能のまとまりや担当領域ごとに分けます。SLOやNFRに基づいた、数値で測れるKRを書きます。数値がまだ決まっていない場合は、「TBD(未定)」とはっきり書いておきます。
Issue(実際に手を動かす一番小さい作業)— 「どうやって」やるか: 実際に作業できる、一番小さい単位まで分割します。1つの機能・1つのAPIのエンドポイント(通信の窓口)・1つのデータ構造(スキーマ)の変更、というように1つずつに分けます。受け入れ基準(完成したと判断するための条件)を5個より多く書いたり、複数のまとまり(アグリゲート)を1つのIssueに混ぜたりしないようにします。

Issue分割の実例(Deal Managementの場合)

SE1.1: Deal Management (Core, Strong)
├── I1.1.1 案件を新規作成する
├── I1.1.2 自分の担当案件一覧を表示する
├── I1.1.3 案件詳細を開く
├── I1.1.4 案件の進捗ステータスを更新する ★critical path
├── I1.1.5 案件の次アクションを編集する
└── I1.1.6 案件にメモを追加する(Should)