はじめに
◆この記事は何？
アジャイル開発やスクラムで活用される「完成の定義」についてサンプルや作成のコツを紹介する記事です。
◆対象は？
エンジニア
◆この記事のねらい
「完成の定義」を活用して後戻りを少なくする
先に結論
- 「完成の定義」とは、開発が完了したかを判断する基準
- 「完成の定義」はチームによって更新され続ける
- 「完成の定義」があれば、共通認識ができて、後戻りを減らせる
「完成の定義」とは
「完成の定義」は開発完了の判断基準です。
開発完了のチェックリストともいえます。
書籍『SCRUM BOOT CAMP THE BOOK』では、「品質基準」とも言及されています
完成の定義は、品質基準と言い換えることもできます。
開発を始める前にチームで合意します。
「完成の定義」をつくる理由
「完成の定義」をつくると、チームで共通認識が得られます。
アジャイル開発では、スプリント終了時に完成し正常動作する必要があります。
そのため、プロダクトオーナーと開発チームは「完成」の基準を共有する必要があります。
その結果、「完成の定義」があることで、後戻りを減らすことができます。
「完成の定義」のサンプル
書籍『MORE EFFECTIVE AGILE』で紹介されている「完成の定義」の例です。
コードレビューを通過している
静的コード解析を通過している
ユニットテストがエラーなしで完了している
ユニットテストによるステートメントカバレッジが70%である
システムテストと結合テストが完了している
自動化した非機能テストがエラーなしで完了している
ビルド時にエラーや警告が出ていない
パブリックAPIが全て文書化されている
機能だけでなく、テスト、非機能、ドキュメントなどにも言及されます。
このようなチェックリストがないと、「非機能要件未達で再作業」といった後戻りが増える可能性があります。
「完成の定義」をつくるコツ
「完成の定義」は、チームごとに独自に作成されます。
「完成の定義」を作成する際に次のことを気をつけます。
- 更新し続ける前提にする
- 量が多いときは分ける
- 量が多すぎると参照しなくなるため
- 活動ではなくエビデンスを示す
- 例：「コードレビューが完了」ではなく「コードがレビューを通過」
- より客観性が向上するため
そのときの開発チームにとってより良い共通認識をつくり続けていきます。
おわりに
この記事では、「完成の定義」について紹介しました。
アジャイル開発・スクラムに限らずに活用できる概念です。
「完成の定義」を活用して、後戻りを減らし、働きやすくなれば幸いです。