完了の定義をわかりやすく説明する: アジャイルチームの必需品

これにはいくつかの理由が考えられます。その目的を完全に理解していない、受け入れ基準と混同している、または単に実装するのに十分な時間がないなどです。このブログ投稿では、「完了」の定義をわかりやすく説明し、それが何なのか、そしてなぜチームが成功するためにそれが必要なのかを説明します。DoDの世界に飛び込み、その潜在的な利点を発見してください。

簡単に言えば、完了の定義は、作業項目が「完了した」とみなされるために満たさなければならない基準のリストであり、「ほぼ完了」または「おそらく完了したと思われる」という曖昧さを排除します。完了の定義の詳細は作業の性質によって異なりますが、通常同様の種類の作業項目では多かれ少なかれ標準化されています。たとえば、ソフトウェア開発チームは、コーディングを伴うすべての作業が次の「完了の定義」に従う必要があると決定する場合があります。

1) コードが本番環境にある

2) 単体テストのカバレッジが 95% 以上である

3) 手動テストが完了している

4) プロダクトオーナーが承認している

または、たとえば、チームが単体テストのカバレッジに対してまったく異なるアプローチを採用している場合、チームの完了の定義は、単体テストよりもチームにとって重要な作業の他の側面に焦点を当てることになります。ここには万能の解決策はありません。

「完了の定義」は、一方では漏れがないことを確認するのに役立ち、他方では、部分的に完了した作業項目を終了するのを防ぐチェックリストであると考えてください。

チームが「完了」の定義を使用しない場合、完了した作業項目の構成要素について暗黙の仮定が生じることがよくあります。ある人はコードを書くだけで十分だと考えるかもしれませんし、別の人はすべてのテストが完了した後にのみタスクが完了したと考えるかもしれません（ただし、必ずしも本番環境にプッシュされるわけではありません）、そして第三者は、本番環境に入って初めてタスクが完了したとみなすかもしれません。こうした矛盾は議論されないことが多く、チーム内でのトラブルや対立につながります。完了の定義は、「完了」の意味について全員が同意するのに役立ちます。

私は、政治、宗教、哲学、アジャイル フレームワークなどのトピックについて議論するのが好きです。特に、さまざまな視点を探求して新しい洞察を発見できる刺激的な会話パートナーを見つけたときはそうです。ただし、「テストの自動化をこのユーザー ストーリーの範囲の一部として考慮すべきか、イエスかノーか？」のような議論には特にそれが毎日発生する場合耐えられません。

「完了の定義」を使用すると、チームはこの決定を一度に行うことができ、デフォルトで範囲に含まれるものと含まれないものを事前に定義することで、時間と労力を節約できます。そうすることでチーム内の雰囲気が良くなるのは言うまでもありません。

一部のチームは、作業範囲について事前に積極的に話し合っていません。これは、作業を見積もっていない場合、または製品計画プロセスに問題がある場合に発生する可能性があります。その結果、「この Jira チケットをすでに閉じる」時期が来たかどうかについて激しい議論を繰り広げることになる可能性があります。

作業の大部分が完了すると、次の新しく輝くアイテムに移りたくなり、中途半端なアイテムが残ることがよくあります。 「完了」の定義では、作業項目が完了して終了したと見なされる明確な基準が設定されているため、これを行うことはできません。

作業を見積もるときは、単なる小さな問題の修正であっても、他のチームへの更新情報の伝達、顧客向けのプレスリリースの発行、ドキュメントの更新など、タスクの全範囲を理解することが重要です。表面的にはわずか 2 時間の作業しか必要としないように見えても、実際には氷山の一角にすぎない可能性があります。

完了の定義は、作業項目のあらゆる側面を積極的に検討することを促し、その結果、そのサイズのより正確な推定値を提供します。アジャイルでは、詳細なプロジェクト計画や作業分解構造を構築することは推奨しませんが、場合によっては、特定のプロジェクトに何週間の予算を立てるかを把握する必要があることがあります。 「完了」の定義がなければ、見積りは一貫性がなく信頼性が低いものになる可能性があります。

一部の作業項目は標準的ではなく、別のアプローチが必要になる場合がありますが、「完了」の定義がすべての固有の状況をカバーできるわけではありません。ただし、「完了の定義」を設定すると、タスクの完了に何が関係するかを積極的に検討し、作業を開始する前にそれを「完了」と宣言するという貴重な習慣がチーム内に植え付けられます。

完了の定義でカバーされていない作業項目の側面がある場合でも、チームは事前にそれらを特定し、時間と作業負荷をより適切に計画する可能性が高くなります。この先見性は、進捗を妨げる可能性のある予期せぬ遅延やその他の「サプライズ」を回避するのに役立ちます。

最後になりますが、価値を確実に提供するには、完了の定義が非常に重要です。チームが完了する各作業項目は、顧客価値、ビジネス価値、またはその両方をもたらす必要があります。そうしないと、それに費やした時間が無駄になってしまいます。

ソフトウェアチームの例を考えてみましょう。単に記述してリポジトリに保存するだけのコードは価値を提供しません。検証およびテストが完了してもリポジトリに残っているコードであっても、価値を提供することはできません。ただし、そのコードが運用環境に導入され、顧客がメリットを享受できる機能が追加または変更されたとき、そのときに価値が提供されます。

完了の定義により、チームは各作業項目を最後まで確認し、確実に価値提供のポイントに到達することができます。理想的には、チームはこの価値の測定方法も知っている必要がありますが、この側面を完了の定義に含めるかどうかはチーム次第です。


結論として、「完了の定義」はアジャイル チームに多くのメリットをもたらす貴重なツールです。これは、作業範囲に関してチーム メンバーの調整を図り、誤解を減らし、予期せぬ事態を防ぐのに役立ちます。明確な「完了の定義」を実装することで、チームは計画と見積もりの​​精度を向上させ、顧客とビジネスに確実に価値を提供することができます。

完了の定義は、積極的な考え方を促進し、チームが作業項目のあらゆる側面を検討し、価値の提供を最後までやり遂げることを奨励します。最終的には、明確に定義された「完了の定義」を採用して遵守することで、チームの協力を強化し、プロセスを合理化し、アジャイル変革の全体的な成功に貢献することができます。