Open7
アジャイル開発であるとよいドキュメントについて
ピン留めされたアイテム
（や）概要
- アジャイル開発であるとよいドキュメントについて個人的に評価していく
- 立ち上げ/途中参加の２つの視点で評価する
目次
ピン留めされたアイテム
（や）まとめる予定
- ポータルサイト
- スキルマップ
- ネットワーク図
- Technical Design Document
- User Story Mapping
- APIドキュメント
- JavsDoc/TSDoc
（や）インセプションデッキ
個人評価
- 立ち上げ時: ★★★★★
- 途中参加時: ★★★★★
ドキュメント内容
以下の内容で構成されている
- 我々はなぜここにいるのか
- エレベーターピッチ
- パッケージデザイン
- やらないことリスト
- ご近所さんを探せ
- 技術的な解決策の概要
- 夜も眠れなくなる問題
- 俺たちのAチーム
- 期間を見極める
- トレードオフスライダー
- 初回リリースに必要なもの
メモ
- 立ち上げ/途中参加時のどちらでも必須のドキュメントです。
- PO/エンジニア間の意思統一が出来るので便利です。
- どういう意識でプロジェクトを進めていくかが分かるので便利です。
- アジャイル開発での標準フォーマットのため、どのプロジェクトでも読み方は書き方が分かるのでオススメです。
（や）Working Agreement
個人評価
- 立ち上げ時: ★★★☆☆
- 途中参加時: ★★★★☆
ドキュメント内容
- チーム内の暗黙的な決め事を明文化してまとめます
- チーム内で働き方の合意を取ります
メモ
- チームでの働く上でのルールがまとまっているので、途中参加時に役に立ちます。
- コミュニケーションのルールなど決めておくとよいです。
- 会議などのルールは個人的にはかなり厳密化して記載しました。アジェンダや事前資料展開の必須化や議事録を取る人を予め決めるなどは盛り込んで、効率的な会議運営をするようにチームで心がけました。
（や）Architecture Decision Record
個人評価
- 立ち上げ時: ★★☆☆☆
- 途中参加時: ★★★★★
ドキュメント内容
- アーキテクチャ上の意思決定を記録します
- フォーマットは以下の通り
- タイトル
- ステータス
- コンテキスト
- 決定事項
- 予想される結果/実際の結果
メモ
- アーキテクチャがどのように決定したかが記録に残るので、途中参加時に同じ議論をせずにすむので便利です。
- 何故、その選択をしなかったかが残ってるケースが少ないので残すようにしましょう
（や）完了の定義
個人評価
- 立ち上げ時: ★★★★☆
- 途中参加時: ★★★★☆
ドキュメント内容
- 設計・検証・製造・テストなどチケットの分類ごとにチケットの基準となる完了条件を定義する
メモ
- チケット個別に常に書くパターンだったり、Wikiの1ページにまとまるパターンだったり色々あります。
- 定量化出来ている指標だと良いです。
（や）システム構成図
個人評価
- 立ち上げ時: ★★★☆☆(システムの規模によりけり)
- 途中参加時: ★★★☆☆(システムの規模によりけり)
ドキュメント内容
- システム構成を図としてまとめます
- AWSなどのクラウド環境の場合、使用しているサービスなども記載します
メモ
- システムの規模によりけりで小規模の場合は不要です。
- また、WEBページとAPIサーバーなどの単純構成だとそこまで必要ではありません。
- WEB/API/DB以外のサーバーやサービスがあるプロジェクトについては残しておくと良いでしょう。