完了の定義テンプレート

完了の定義（DoD）テンプレートとは何ですか？

A 完了の定義（DoD）テンプレートは、ユーザーストーリーやタスクが "Finished" と見なされる前に満たすべき技術的および機能的基準を網羅したチェックリストです。"Acceptance Criteria"（各ストーリー固有のもの）とは異なり、DoDはすべての作業に適用される共通の基準です。テスト、ドキュメント、コンプライアンスがスピードを理由に省略されることがないようにすることで、"technical debt" を防ぎます。

"Quality" Audit: 3 Ways to Enforce "Shippable" Standards

DoDの有効性はチームの規律次第です。テンプレートを確定する前に、以下の専門的な3つの「ヘルスチェック」を適用してください：

1. "Undone Work" Audit

監査: ストーリーを "完了" に移動して、ドキュメントやインテグレーションテストを "次のスプリント" に残していませんか？ 対応策:品質の先送り を監査してください。プロフェッショナルな DoD には、回帰テスト と ドキュメント更新 を必須にする必要があります。システム全体に対して文書化およびテストされていない場合、それは "完了" ではなく単に "開発済み" に過ぎません。テンプレートには "新たな技術的負債を残さない" を要件として明記してください。

2. "Automated Truth" テスト

監査: あなたの DoD は「人の約束」（例：「コードを確認しました」）に頼っていますか？ 対策:自動真偽検証の監査を行ってください。可能な限り手動チェックは自動化されたものに置き換えましょう。「コードがレビューされた」ではなく、「プルリクエストが同僚 2 人に承認されている」を使用します。「ユニットテスト済み」ではなく、「ユニットテストのカバレッジ > 80%」を使用します。これにより主観性が排除され、「Done」状態が測定可能で議論の余地のないものになります。

3. グローバルとローカルの対立

監査: DoD が長すぎて、チームがスプリント目標を達成するためにその半分を無視していませんか？ 対処:現実性を監査してください。まずは "Minimum Viable DoD" から始め、チームが成熟するにつれて拡大してください。チームが毎スプリントごとに完全なセキュリティー監査を現実的に実行できない場合は、ストーリー レベルの DoD にそれを入れないでください。代わりに "リリースの定義" に移してください。これにより、日々の DoD が実行可能で守られるようになります。

戦略的枠組み: "完了" の 3 レベル

プロフェッショナルな組織では、完了の各段階を管理するために、3 つの異なるテンプレートを使うことが多いです:

• Level 1: ユーザーストーリー DoD (スプリント レベル)

  • Focus: コード品質、ピアレビュー、および特定の受け入れ基準を満たすこと。

  • Example: "ユニットテストが通過済み", "PO が承認済み", "機能テストが合格".

• Level 2: スプリント/フィーチャー DoD (インテグレーション レベル)

  • Focus: 機能がアプリの他の部分とどのように連携するか。

  • Example: "回帰バグなし", "パフォーマンス指標が安定", "ステージング環境が更新済み".

• Level 3: リリース DoD (市場レベル)

  • Focus: 法務、マーケティング、およびセキュリティーのコンプライアンス。

  • Example: "セキュリティー侵入テスト合格", "翻訳完了", "ユーザーマニュアル更新済み".

Definition of Done テンプレートの主要構成要素

効果的な DoD には、次の5つの主要カテゴリが必要です：

• 開発基準: コードにコメントが付けられ、リファクタリング済みで、main ブランチにチェックインされています。

• テスト & 品質: 単体テスト、統合テスト、手動のスモークテストが完了し、合格しています。

• 環境 & DevOps: コードがステージング環境にデプロイされ、ビルドパイプラインを通過しています。

• レビュー & 承認: ピアレビューが完了し、プロダクトオーナー (PO) が機能を承認しています。

• 非機能要件: 機能が速度、アクセシビリティー、セキュリティーの各ベンチマークを満たしています。