Readyの定義と完成の定義

みなさんこんにちは。@ryuzeeです。

Derek Huether氏のブログ記事「Ready and Done」が良い記事だったので適当意訳にて紹介します。なお、引用部分は原文と同様のCC-BY-NCライセンスとします。

スクラムでは完成の定義は必須であることは言うまでもないですが、実際にスプリントを行うに際してはそれだけでは不足していることが多いです。よくあるパターンはプロダクトバックログの準備があまくて、いざスプリントプランニングをしてみたら中身が全然曖昧だったとか、プロダクトバックログアイテムのサイズが大きすぎたとかいうケースで、こういう場合への対処としては、スプリントが始まる前にプロダクトバックログリファインメントを実施して、次のスプリントで実施するような順位の高いプロダクトバックログアイテムについてはより明確化しておくようにするのが定石です。このように作業前に事前に行っておくべきことをまとめたものがReadyの定義になります。

開発チームを率いていると、開発フェーズにおいてかなりのムダな行動を見かける。

チームが開発をはじめるときに、これから行う作業がReadyではなかったら、ビジネスからの要求が明確化されるのを待たなければいけなくなってしまう。チームが開発をはじめるときに、受け入れ基準がはっきりしていなければ、作業は続き、顧客の怒りをなだめなければいけなくなってしまう。

チームに必要なのは、「作業のReady」と「作業の完成」のはっきりとした定義だ。これらの定義はチームや会社によって変わってくるので、あなたたち自身が明確化する必要がある。さらに言えば、これは象牙の塔にこもって誰かが書くのではなく、チームでその定義を書かなければいけない。

同僚のBob Payneと私は、すべての顧客のところで、作業開始前にこれら双方の定義についての最低限の同意を取ることの必要性を強く訴えている。入り口と出口の基準を決めるときは、何かを抜かしてしまうリスクを減らすためにもチームの多くの人を巻き込む必要がある。

以下はReadyと完成の定義のサンプルだ。なお、我々はアナリストやテスターや開発者に対してコンサルティングを行なっていることに注意してほしい。あなたのチームや組織では、あなたはUXデザイナーやデータベース管理者やほかの人たちのコンサルティングをすることもあるだろう。だが、やりすぎてはいけない。まずは必要十分な最小限の範囲から始めていけばよい。