良い完了の定義を作る方法

スクラムチームの作業合意として、完了の定義は、製品のインクリメントがすべてのスプリントで出荷可能かつ使用可能にするというスクラムチームのコミットメントです。これは基本的に、チームが、完了したものがリリース可能であることを検証するために使うチェックリストです。

少なくとも、完了の定義リストには、次の３つの領域の考慮事項が含まれます。

環境：チームが、少なくともＱＡ環境 (またはライブ環境あるいは運用環境を反映する環境）で作業を完了したか
テスト：実行して合格するには、どのようなテストが必要かテストは各チームのスタンダードによって異なる場合があり、ユニットテスト、機能テスト、探索的テスト、統合テスト、リグレッションテスト、ユーザビリティテストなどが含まれる場合があります。自動化が進めば進むほど、スプリントのインクリメントが真にリリース可能であることを確実にするための、十分な製品カバレッジがあるという自信が高まります。
ドキュメンテーション：作業が完了したと見なすために必要な、適切な種類のドキュメンテーションは何か

これらすべてをカバーするリストを作成するのは気が遠くなるように思えるかもしれません。ただし、使用方法を理解し、いくつか例を見ると、すべて完全に理にかなっています。要するに、チームがプロダクトバックログアイテムを「完了した」と言うとき、チームが自分たちの責任の範囲が満たされたと主張し、その作業に価値がある場合はそれをリリースできるようにしたい、ということです。

アジャイルの価値と原則

完了の定義の価値と、それがどのように開発プロセスを改善するかについて話すとき、スクラムのフレームワークよりも、『アジャイルマニフェスト』の12原則の方に深く目を向けてもいいでしょう。次の３つの原則を、チームで完了の定義を発展させ、実行する大切な理由だと考えてください。

動くソフトウェアは、進捗を測る主要な尺度である。
ビジネス側と開発者は、プロジェクト全体を通して毎日連携する必要がある。
卓越した技術と優れた設計に継続的に注意を払うことは、アジリティを高める。

作業の完了を検証するための箇条書きリストがあることで、各スプリントの最後に、機能する出荷可能な製品を提供するための具体的な進捗状況を確認することができます。また、完了の定義内の項目は、顧客に提供するために取り組んでいるものの全範囲を明確にすることで、ビジネスチームと開発チームのコラボレーションを強化します。そこには共有されたオーナーシップと、期待されていることへの理解があります。

まとめると、出荷可能な製品に含まれるものを改良することで、一貫性と品質が向上するため、技術的な卓越性も向上します。検証は、作業項目のピアレビューやエンドユーザードキュメントの更新など、いくつかの場面において重要です。これらを行うことで、各成果物の重要なコンポーネントを見落とさずにいられます。遅らせると、リリース可能なインクリメントが なくなります 。

完了の定義はいつ使うのか

完了の定義は、作業のあらゆる側面に役立つため、一日中、毎日参照できるようにしておく必要があります。

プロダクトバックログの調整作業中に完了の定義を参照すると、複数の視点から各作業項目を見ることができます。これらの視点には、テストとドキュメンテーションが含まれ、その結果、改善のための話し合いと作業の明確化が可能になります。

たとえば、見積りについての話し合い中に、完了の定義を出しておくことで、チームはプロダクトバックログ項目を見積るときに必要な、すべての種類の作業を検討することができます。計算の際には、出荷可能な品目を評価するために必要な、すべてのテストを忘れないでください。

スプリント計画も、リストを参照するもう１つの重要な時間です。チームが各項目について話し合い、タスクを作るとき、タスクリストには、チームの完了の定義のチェックリスト項目がそのまま反映されている必要があります。スプリントの終わりに出荷可能な機能を備えているという状態は、自動で発生するわけではありません。試験は、自動で文字が書かれ勝手に合格してくれるわけではありません。ウィキペディアも勝手に更新されるわけではありません。同じように、リストを書くには慎重な注意が必要です。スプリントで計画された項目の完了は、きちんとしたスプリント計画から始まります。

最後に、スプリントの最中、個々の作業項目が完了に向かっているとき、リストは、出荷可能な作業に対する重要なアクションが忘れられていないことを確認するための非常に貴重なツールです。

最初の「完了の定義」を作る方法

まず、プロダクトバックログを構成する包括的なアクティビティを特定することから始めましょう。次に、それらのアクティビティを表すアイテムをリストに追加します。完了の定義は、作業の境界を形作るツールですが、網羅的なリストである必要はありません。技術基準やテスト戦略を参考にすることができます。

最低限、作業環境（通常は少なくともＱＡ）、合格しなければならないテストの種類、作業が完了したとみなすために必要なドキュメンテーションを考慮します。具体的には、考慮事項には次のアクティビティが含まれます。

設計：設計の見直しとドキュメンテーション、およびアーキテクチャと統合の見直しを完了する。
ユニットテスト：コードの各コンポーネントが望ましい出力をしていることを確実にする。
機能テスト：各作業項目またはコンポーネントが指定通りに機能するかどうかを判定する。
統合テスト：個々のコンポーネントが、それらが動作する全体と連動して動作することを確認する。
リグレッションテスト：変更や新機能が既存の機能を破壊しないことを検証する。
ピアレビュー：作業を完了しなかったチームメンバーも含めて、作業の正確さと合意された基準との整合性を見直す。
ドキュメンテーション：このための項目を追加することは非常に重要で、多くのチームが構築やテストの際に見落としています。また、『アジャイルマニフェスト』に記載されている「包括的な文書よりも動くソフトウェア」の価値についても考える必要があります。ドキュメンテーションに反対する人は誰もいません。ただし、それには価値があるべきです。有用なドキュメンテーションには、何がどのように機能するか、トレーニング資料、および設計と機能の決定の背後にある理論的根拠の詳細が記されています。

効果的な「完了の定義」を作成するためのヒント

完了の定義は、スクラムチームが作成し、責任を持ち、実行する、チームの合意と考えてください。すべてのメンバーが、リストのすべての項目を理解し、同意していることを確認してください。
それを書き出し、チームが使用できるように常に表示できるようにすることで、リスト上のアイテムへの共通の配置を強化し、印刷、投稿、共有を通じて簡単にアクセスできます。
このリストは、スプリントレトロスペクティブを通じて改変できる「生きた」アーティファクトです。スプリント活動に足りないものが見つかった場合は、それをリストに追加することについて話し合います。開発チームの能力が拡大するにつれて、完了の定義も拡大する必要があります。
チームがリストを作成して実行することを、スプリントが始まるまで待たないでください。理想的には、最初のスプリントの開始前に完了の定義を設定しておくことです。これは、各プロダクトバックログ項目の作業に影響を与える作業と、関連するアクティビティの理解に影響を与えるためです。ただし、完了の定義は、製品が出荷可能であるかどうかを検証するのに役立つため、作業が既に進行中だったとしても、使い始めるのに遅すぎることはありません。

あなたの「完了の定義」は良くできていますか？

スクラムチームは、完了の定義の作成に苦労するかもしれません。作業をするにあたり非常に重要であり、私たちのアドバイスを参考にして頂くことで、「完了の定義」を整理することができます。

スクラムやアジャイル移行について分からないことがありましたら、プラチナムエッジが必要なサポートとリソースをご提供します。私たちがご提供するサービスをご覧頂き、どのようなお手伝いができるかをご確認ください。

[monarch_share center=”true”]