はじめに

◆この記事は何？
アジャイル開発やスクラムで活用される「完成の定義」についてサンプルや作成のコツを紹介する記事です。

◆対象は？
エンジニア

◆この記事のねらい
「完成の定義」を活用して後戻りを少なくする

先に結論

「完成の定義」とは、開発が完了したかを判断する基準
「完成の定義」はチームによって更新され続ける
「完成の定義」があれば、共通認識ができて、後戻りを減らせる

「完成の定義」とは

「完成の定義」は開発完了の判断基準です。
開発完了のチェックリストともいえます。

書籍『SCRUM BOOT CAMP THE BOOK』では、「品質基準」とも言及されています

完成の定義は、品質基準と言い換えることもできます。

開発を始める前にチームで合意します。

「完成の定義」をつくる理由

「完成の定義」をつくると、チームで共通認識が得られます。

アジャイル開発では、スプリント終了時に完成し正常動作する必要があります。
そのため、プロダクトオーナーと開発チームは「完成」の基準を共有する必要があります。

その結果、「完成の定義」があることで、後戻りを減らすことができます。

「完成の定義」のサンプル

書籍『MORE EFFECTIVE AGILE』で紹介されている「完成の定義」の例です。

コードレビューを通過している
静的コード解析を通過している
ユニットテストがエラーなしで完了している
ユニットテストによるステートメントカバレッジが70%である
システムテストと結合テストが完了している
自動化した非機能テストがエラーなしで完了している
ビルド時にエラーや警告が出ていない
パブリックAPIが全て文書化されている

機能だけでなく、テスト、非機能、ドキュメントなどにも言及されます。

このようなチェックリストがないと、「非機能要件未達で再作業」といった後戻りが増える可能性があります。

「完成の定義」をつくるコツ

「完成の定義」は、チームごとに独自に作成されます。

「完成の定義」を作成する際に次のことを気をつけます。

更新し続ける前提にする
量が多いときは分ける
- 量が多すぎると参照しなくなるため
活動ではなくエビデンスを示す
- 例：「コードレビューが完了」ではなく「コードがレビューを通過」
- より客観性が向上するため

そのときの開発チームにとってより良い共通認識をつくり続けていきます。

おわりに

この記事では、「完成の定義」について紹介しました。

アジャイル開発・スクラムに限らずに活用できる概念です。

「完成の定義」を活用して、後戻りを減らし、働きやすくなれば幸いです。

参考

書籍『MORE EFFECTIVE AGILE』

書籍『SCRUM BOOT CAMP THE BOOK』