konabe/start-01-requirement

要件定義とワーク分割について

1. Gitの準備

• mainブランチの先頭にスイッチ
  • git checkout main
  • git pull

2. 何を開発するのかを収集

• 人間にどんな要件の内容を開発するかを尋ねる。
  • この際に不明点があれば最大３回繰り返し深堀すること
• 開発の内容からタイトル({feature-title})を確定する。
• フィーチャーブランチfeature/{feature-title}を作成
• Explore エージェントを使って /docs/features/ のディレクトリ状態を調査し、最大値をインクリメントした{index}を採番する
  • 採番ルールは 001, 002 のように単純なインクリメントで、3桁でゼロ埋め
  • PR 提出直前に /docs/features/ 内で同一の {index} が存在しないか再スキャンし、競合があれば再採番する
• /docs/features/{index}-{feature-title}/requirement.md を作成し、要件を記載する。

3. タスク分割提案

• /docs/features/{index}-{feature-title}/requirement.md の内容をもとにタスクを分割する
• レビューのしやすさを目的になるべく小さいタスクに分割したい
  • リリース可能な単位の分割であり、タスク間には依存関係がないように分割する。
  • スクラム開発でいうPBIのように、ユーザーストーリーの視点で分割する。
  • フロントエンド/バックエンド等のシステム単位の分割だと動作確認ができないので禁止する。
• 一度タスク分割の方針と分割案を提示し、人間に確認を求める
  • タスクが分割された単位をワーク({work})と呼ぶこととする。

4. タスク分割

• /docs/features/{index}-{feature-title}/requirement.mdの内容をもとに、/docs/features/{index}-{feature-title}/{index}-{index-of-work}-{work}/work.md にそれぞれファイルを配置する
• /docs/features/{index}-{feature-title}/checklist.md を作成し、各workの進捗が記録できるようにする。
  • 設計、設計レビュー、実装、受け入れ　で進捗を記録

5. work.mdに記載する内容

• 要件定義にとどめ、AWS設計、ソフトウェア設計、実装については触れないこと
• 受入テストケースも列挙すること

6. PRの発行

• mainブランチに対してPRを発行する。

ルール

• requirement.md は要件の情報のみに留め、具体的な設計までは記載しないこと。
  • 工程の前後でトレースするために使用する。

requirement.md のひな型

# {要件名} - 要件定義

## 概要

## 目的

## 機能スコープ

### 実装する機能

### 実装しない機能（将来の実装対象）

## 設計申し送りメモ

- メモ1...
- メモ2...