スクラムチームの作業契約として、完了の定義は、製品の増分がすべてのスプリントで出荷可能で使用できるようにするというスクラムチームのコミットメントです。 これは基本的に、チームが完了した内容がリリース可能であることを検証するために使用されるチェックリストです。
少なくとも、完了リストの定義には、次の 3 つの重点分野の考慮事項が含まれます。
- 環境: チームは少なくとも QA 環境 (またはライブ環境または運用環境を反映する環境) で作業を完了しましたか?
- テスト: 実行して合格するには、どのようなテストが必要ですか? これは標準によって異なる場合があり、ユニット、機能、探索、統合、回帰、使いやすさなどが含まれる場合があります。 自動化すればするほど、スプリントの増分が真にリリース可能であることを保証するために、製品を適切にカバーしているという確信が高まります。
- ドキュメンテーション: 作業が完了したと見なされるために必要な適切な種類のドキュメンテーションは何ですか?
これらすべてをカバーするリストを作成するのは気が遠くなるように聞こえるかもしれません。 ただし、使用方法を理解し、いくつかの例を見ると、すべて完全に理にかなっています。 要するに、 チームがプロダクトバックログ 項目が完了したと言ったときに、チームは責任の範囲が満たされたと主張し、価値がある場合は作業をリリースできるようにする必要があります。
アジャイルの価値観と原則
完了の定義の価値と、それが開発プロセスをどのように改善するかについて話すとき、 アジャイルマニフェストの12の原則をスクラムフレームワークよりも深く見ることができます。 次の 3 つの原則を、チームで完了の定義を開発して実装する貴重な理由と考えてください。
- 動作するソフトウェアは、進歩の主要な尺度です。
- ビジネスマンと開発者は、プロジェクト全体を通して毎日協力する必要があります。
- 卓越した技術と優れたデザインへの継続的な注意は、俊敏性を高めます。
作業の完了を検証するための箇条書きのリストは、各スプリントの最後に機能する出荷可能な製品を提供する具体的な進捗状況を確保することに焦点を当てます。 また、完了の定義の項目は、顧客に提供するために取り組んでいるものの全範囲を明確にすることで、ビジネスチームと開発チームのコラボレーションを強化します。 共有された所有権と期待の理解があります。
まとめると、出荷可能な製品に含まれるものを改良することで、一貫性と品質が向上するため、技術的な卓越性も向上します。 検証は、作業項目のピア レビューやエンド ユーザー ドキュメントの更新など、いくつかのシナリオで重要です。 これらのことを行うことで、各成果物の重要なコンポーネントを見落とさないことが確認されます。 これらのことを遅らせると、解放可能な増分が なくなります 。
完了の定義を使用する場合
完了の定義は、作業のあらゆる側面に情報を提供するため、一日中、毎日参照できるようにする必要があります。
製品バックログの調整アクティビティ中に、完了の定義を参照すると、複数の視点から各作業項目を表示できます。 これらの視点には、テストと文書化が含まれ、その結果、改善のための作業の会話と明確化が行われます。
たとえば、見積もりの議論中に Done の定義を前面と中央に配置すると、チームは製品バックログ項目を見積もるときに必要なすべての種類の作業を検討するのに役立ちます。 計算時に出荷可能な各アイテムを評価するために必要なすべてのテストを忘れないでください。
スプリント計画 は、リストで参照するもう 1 つの重要な時期です。 チームが各項目について話し合い、タスクを作成するとき、タスク リストには、チームの完了の定義のチェックリスト項目が直接反映されている必要があります。 スプリントの最後に出荷可能な機能を持つことは、それだけで起こるわけではありません。 テストは自分で作成して合格することはありません。 ウィキも自ら更新しません。 これらの項目には慎重な注意が必要です。 スプリントで計画された項目の完了は、適切なスプリント計画から始まります。
最後に、スプリント自体の間に、個々の作業項目が完了に向かっているときに、リストは、出荷可能な作業の重要なアクションが忘れられていないことを確認するための非常に貴重なツールです。
完了の初期定義を作成する方法
まず、製品バックログの配信を構成する包括的なアクティビティを特定します。 次に、それらのアクティビティを表すアイテムをリストに追加します。 完了の定義は、作業の境界を形作るツールですが、網羅的なリストである必要はありません。 技術標準とテスト戦略を見て、インスピレーションを得ることができます。
少なくとも、作業環境(通常は少なくともQA)、合格する必要のあるテストの種類、および作業の完了を検討するために必要なドキュメントを考慮してください。 具体的には、考慮事項には次のアクティビティが含まれます。
- 設計: 設計のレビューとドキュメント、およびアーキテクチャと統合のレビューを完了します。
- 単体テスト: コードの各コンポーネントが目的の出力を提供することを確認します。
- 機能テスト: 各作業項目またはコンポーネントが指定どおりに動作することを確認します。
- 統合テスト:個々のコンポーネントが、それらが動作するより大きな全体と連携して機能することを確認します。
- 回帰テスト: 変更や新機能を検証しても、既存の機能が損なわれることはありません。
- ピアレビュー:作業を完了しなかったチームメンバーを含めて、正確さと合意された基準との整合性を確認します。
- ドキュメント: このための項目を追加することは、多くのチームがビルドおよびテスト中に見落としているため、不可欠です。 また、アジャイルマニフェストに記載されている「包括的なドキュメントよりも機能するソフトウェア」の価値についても検討する必要があります。 文書化に反対する人は誰もいません。ただし、これには価値があるはずです。 有用なドキュメントには、何かがどのように機能するか、トレーニング資料、および設計と機能の決定の背後にある理論的根拠に関する詳細が含まれます。
完了の効果的な定義を作成するためのヒント
- スクラムチームが作成、所有、実装するチーム合意と考えてください。 すべてのメンバーがリストのすべての項目を理解し、サポートしていることを確認してください。
- それを書き出し、チームが使用できるように常に表示できるようにすることで、リスト上のアイテムへの共通の配置を強化し、印刷、投稿、共有を通じて簡単にアクセスできます。
- このリストは、 スプリントの振り返りを通じて変更できる「生きた」アーティファクトです。 スプリント活動に足りないものが見つかった場合は、それをリストに追加することについて話し合います。 開発チームの能力が拡大するにつれて、完了の定義も拡大する必要があります。
- チームがリストを作成して実装するために全力疾走するまで待たないでください。 理想的には、最初のスプリントの開始前に完了の定義を設定する必要があります。 これは、各製品バックログ項目の作業に影響を与える作業と関連するアクティビティの理解に影響を与えるためです。 ただし、作業が出荷可能として検証されることをサポートしているため、作業が既に進行中であっても、使用するのに遅すぎることはありません。
完了の定義は良いですか?
スクラムチームは、完了の定義に苦労するかもしれません。 作業にとっての重要性は非常に重要であり、これらのヒントと提案に従うことで、完了の定義を絞り込むことができます。
スクラムやアジャイルトランスフォーメーションについて質問がある場合は、Platinum Edgeが必要なサポートとリソースを提供します。 私たちのサービスを探索 し、私たちがどのように助けることができるかを見てください。
