Definition of Done
Definition of Done と Definition of Ready は密接に関連しています。あるいはその逆と言えるかもしれません。鶏と卵のような関係です。
全体像
アジャイルの主要なアーティファクトの 1 つは、製品レベルとスプリントレベルの両方でのバックログの考え方です。
製品バックログは本質的にプロジェクトの To-Do リスト、つまり要件リポジトリです。
詳細レベルに関係なく、プロジェクトのスコープ内とみなされるすべての項目は製品バックログにあり、単に優先順位が付けられるのではなく、順序付けられます - つまり、上位のものは 5 番目の位置のものより重要であり、それは 23 番目の位置のものより重要です。順序はプログラムマネージャー / プロダクトマネージャーによって決定され、通常はビジネス価値によって駆動されます - 顧客開発チームと相談して決定します。
プロジェクトのスコープについて分かっていることは、ディスカバリが変化につながるという期待のもと、ユーザーストーリーの形で書き留められ文書化されます。製品バックログは生きたリポジトリであり、プログラムマネージャー / プロジェクトマネージャーが所有します。
製品バックログはスプリントバックログのソースです。製品バックログがプロジェクト / エンゲージメントの要件リポジトリを表すのに対し、スプリントバックログは次のスプリントに合意されたスコープであり、GitLab 実装チームと顧客開発チームのデリバリーコミットメントを表します。GitLab 実装チームは真空中で動作するわけではなく、顧客開発チームと優先順位を密に調整します。
合意されコミットされた後、スプリントバックログは通常、GitLab 実装チームと顧客開発チームがそのコミットメントに対してデリバリーできることを保証するために変更されません。
実装チームと開発チームは、スプリントバックログを上から下へ（最も重要なものから最も重要でないものへ）作業を進め、作業が尽きた場合は、現在のスプリントに追加の作業を引き込むために通常、製品バックログのトップ項目を見ます。
現在のスプリント中に項目が完了しなかった場合、それらは a) 次のスプリントでの実装が検討されるか、b) 次のスプリントプランニングミーティングで次のスプリントに再検討されるために製品バックログに戻されます。
新たに発見された要件は、将来のスプリントに検討されるためにユーザーストーリーの形で製品バックログに追加されます。
Definition of Ready (DoR) vs. Definition of Done (DoD)
スプリントは、優先度の高い項目をスプリントバックログから取り出し、製品インクリメントに変換するタイムボックス化された開発サイクルです。ただし、現在のスプリントに項目を成功裏に引き込むためには、定義されたユーザーストーリーが「ready」であることが重要です - 未完成または未リファインのユーザーストーリーをスプリントに引き込むと、実装サイクル中に問題が発生し、これは「ゴミを入れればゴミが出る」という古い原則に従います。開発者が十分に詳細化または定義されていないユーザーストーリーから作業を行うと、高品質のコードを生成する可能性は低くなります。
「ready」なバックログ項目は、明確で、実現可能で、テスト可能である必要があります:
- ユーザーストーリーは、すべてのチームメンバー（GitLab 実装チームと顧客開発チーム）がそれが何を意味するかについて共通の理解を持っている場合、明確 です。共同でユーザーストーリーを作成し、優先度の高いものに受け入れ基準を追加することが明確さを促進します
- 機能が期待通りに動作するかどうかを判断する効果的な方法がある場合、項目は テスト可能 です。受け入れ基準により、各ストーリーがテストできることが保証されます
- Definition of Done に従って 1 つのスプリントで完了できる場合、ユーザーストーリーは 実現可能 です。これが達成不可能な場合、さらに細分化する必要があります
簡単に言えば、Definition of Ready は、特定のユーザーストーリーが見積もりまたはスプリントへの組み込みを検討される前に満たさなければならない基準を定義します。READY とマークされていないストーリーは、作業を開始する前に明確化が必要なため、スプリントで対象とするべきではありません。
Definition of Ready がユーザーストーリーレベルの特性に焦点を当てているのに対し、Definition of Done はスプリントまたはリリースレベルに焦点を当てています。
本質的に、DoD はスプリントまたはリリースの受け入れ基準を表します。製品インクリメントが「done」と見なされるために、実装チームと開発チームがカバーする必要があるものを明示します。
Definition of Done は、各ユーザーストーリーに対して何を完了する必要があるかについての、GitLab 実装チーム、顧客開発チーム、プログラムマネージャー / プロジェクトマネージャー間の合意です - そして、一貫した品質提供を保証するために、顧客エンゲージメント全体で標準化されることがよくあります。
Definition of Done で一般的に取り上げられる事項は次のとおりです:
- 動作環境と、ユーザーストーリーが動作することが期待される統合レベル?
- どのレベルのドキュメントが必要か?
- 品質期待値は何か?
- セキュリティ期待値は何か?
- スケーラビリティ期待値?
本質的に、Definition of Done は、プログラムマネージャー / プロジェクトマネージャーがスプリントの最後に製品インクリメントを受け入れるために使用する合意された受け入れ基準です。一貫したステータスレポートにとっても重要です。
DoD はスプリントとリリースで異なる場合があることに注意してください。つまり、中間スプリントは、市場へのリリースを計画している最後の数スプリントよりも厳密でない DoD を持つ場合があります。これは、初期スプリントが成果物の初期バージョンを生成し、後のスプリントがそれらの成果物を強化するエンゲージメント中に重要です。
Definition of Ready (DoR) のサンプル
- ユーザーストーリーが明確である
- ユーザーストーリーがテスト可能である
- ユーザーストーリーが実現可能である
- ユーザーストーリーが定義されている
- ユーザーストーリーの受け入れ基準が定義されている
- ユーザーストーリーの依存関係が特定されている
- 開発チームによってユーザーストーリーがサイジングされている
- スクラムチームがユーザーエクスペリエンスのアーティファクトを受け入れている
- 必要に応じてパフォーマンス基準が特定されている
- 必要に応じてスケーラビリティ基準が特定されている
- 必要に応じてセキュリティ基準が特定されている
- ユーザーストーリーを受け入れる人が特定されている
- チームがユーザーストーリーをデモすることが何を意味するかについての良いアイデアを持っている
Definition of Done (DoD) のサンプル
- コードが作成された（コード内のすべての「to do」項目が完了）
- コードがコメントされ、チェックインされ、正常に実行された
- ピアレビュー（またはペアプログラミングで作成）され、開発標準を満たしている
- エラーなくビルドされる
- 単体テストが書かれパスしている - 適切に
- 顧客開発チームによる受け入れテストにパスし、要件を満たすとして承認された
- ビルド / デプロイ / 構成の変更がスプリント間で実装 / 文書化 / 通信された
- 関連するドキュメント / 図が作成および / または更新された
- タスクの残り時間がゼロに設定され、タスクがクローズされた
Definition of Ready と Definition of Done のその他の使用
DoR と DoD の本来の意図は、プロジェクトのステークホルダー、プログラムマネージャー / プロジェクトマネージャー、GitLab 実装チーム、および顧客開発チーム間の内部合意を表す簡潔なドキュメントを作成することでした。
しかし、より多くの開発作業がアウトソースまたは下請けされるようになり、DoR と DoD は、何を行う必要があるかについての正確な期待値を明示する契約合意やステートメント・オブ・ワークでますます使用されています - これは、パートナーコンサルタントとの期待値設定に特に有用です。
これらは、期待値を定義し、すべての関係者の説明責任を保つため、プロジェクトスコープの交渉に有用なツールです。DoR は、実装チームと開発チームによって消費される準備ができた、よく書かれたユーザーストーリーを生成するのに顧客を支援し、DoD は、特定のユーザーストーリーの機能だけでなく、すべてのプロジェクト要件に従って動作する製品インクリメントを生成するのにチームを支援します。
