「完了の定義」はチームの実力を表わすバロメーターである

ソース画像を表示

プロダクトマネジメントにおいて、初めて「完了の定義」を導入する際のポイントは3つある。

① 完了条件が明確であること。
② 開発者全員が知っていること。
③ 途中で変更しないこと。

順番に説明していこう。

① 完了条件が明確であること
「完了した」か、「完了していない」か、そのどちらかしかない。

  • イエスか、ノーか
  • ○か×か
  • 合格か不合格か

「90%完了」は完了していないことと同じだ。
完了に向けての進捗率は関係ない。完了条件を100%満たしていなければ、すべて未完成である。

「完了の定義」は曖昧であってはならない。「ほぼ完了」とか「たぶん完了」ではダメだ。
完了基準のひとつひとつに、明快なチェックリストが作れるかどうかが一つの目安だ。
チーム全員にとって、客観的に判断できる基準であること。

② 開発者全員が知っていること
完了条件は、開発者全員が知っていなくてはならない。
開発者は、全員で協業してプロダクトインクリメントを作る。
同じプロダクトなんだから、メンバー全員が同じ認識で作り込んでいかないと、仕上がりにムラが出る。

「完了の定義」はチームのルールだ。開発メンバー全員が、どこまでできたらコードベースにチェックインできるかわかっていて、徹底できないと、一貫性のあるプロダクトにならない。

「完了の定義」はプロダクト単位で共通だ。
複数チームで開発しているなら「完了の定義」は全チームで共有する。

③ 途中で変更しないこと
「完了の定義」は、開発メンバーが目指す「共通ゴール」である。
何をどこまで作れば「完了」するかわかるから、作業規模を見積もれる。
完了条件が固定だから、スプリント計画会議で、これから実装するバックログのタスクが洗い出せるのである。

更に「完了の定義」があることで安心して作業に専念できる。
何をどこまで作れば「完了」かわかるから、顧客に出すまで不安なこともない。どこまで作り込めば満点取れるかわかるから安心である。

完了条件(完了の定義)が途中で変更されると、やり直さないといけないし、作業規模も見直さなくてはならないから、ややこしくなる。

また、スプリント終盤で完了条件を下げるチームをたまに見かけるが、これは絶対にしてはいけない。
ハードルを低くすることで「完了」に持って行くと、プロダクトオーナーとあらかじめ合意した品質基準(受入基準)が満たせなくなる。
ごまかしの完成品は、当然受け入れられない。

そもそも「完了の定義」は開発チームが自ら決めたコミットメントだ。
プロフェッショナルとして、品質を作り込もう。チームで決めた「完了の定義」を全うしよう。

繰り返しになるが、プロダクトマネジメントで、初めて「完了の定義」を設ける際、以下の3つのポイントを守ろう。

  • 誰の目にも明らかである
  • 全員が理解していて守れる
  • スプリント途中で変えない

「完了の定義」は、チームの成熟度によって拡張していく。
日々の作業を通して、チームのコミュニケーションとコラボレーションは浸透していく。
スプリント毎にふりかえりを実施し、継続的に改善していくことで、チームのベロシティー(総合力)もあがっていく。
TDDやBDDの開発プラクティスを推進し、冗長なテストを自動化することで、開発チームの実装能力がモリモリついてくる。

チームの成熟度に伴い、更に高い「完了の定義」を目指そう。

同じ完成条件であれば、スピーディーに実装できるようになる。
顧客・市場リリースまでにかかる期間を短縮できれば、スプリント毎にリリースできるようになる。最終的に、スプリント中に頻繁にリリースできるようになる。

「完了の定義」はチームの実力を示すバロメーターである。

完了の定義がカンタンにわかる3つのポイント

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

新品価格
¥2,592から
(2018/5/24 19:04時点)

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中