Readyの定義と完成の定義
みなさんこんにちは。@ryuzeeです。
Derek Huether氏のブログ記事「Ready and Done」が良い記事だったので適当意訳にて紹介します。 なお、引用部分は原文と同様のCC-BY-NCライセンスとします。
スクラムでは完成の定義は必須であることは言うまでもないですが、実際にスプリントを行うに際してはそれだけでは不足していることが多いです。 よくあるパターンはバックログの準備があまくて、いざスプリントプランニングをしてみたら中身が全然曖昧だったとか、バックログ項目のサイズが大きすぎたとかいうケースで、こういう場合への対処としては、スプリントが始まる前にバックログリファインメントを実施して、次のスプリントで実施するような順位の高い項目についてはより明確化しておくようにするのが定石です。 このように作業前に事前に行っておくべきことをまとめたものがReadyの定義になります。
開発チームを率いていると、開発フェーズにおいてかなりのムダな行動を見かける。
チームが開発をはじめるときに、これから行う作業がReadyではなかったら、ビジネスからの要求が明確化されるのを待たなければいけなくなってしまう。 チームが開発をはじめるときに、受け入れ基準がはっきりしていなければ、作業は続き、顧客の怒りをなだめなければいけなくなってしまう。
チームに必要なのは、「作業のReady」と「作業の完成」のはっきりとした定義だ。 これらの定義はチームや会社によって変わってくるので、あなたたち自身が明確化する必要がある。 さらに言えば、これは象牙の塔にこもって誰かが書くのではなく、チームでその定義を書かなければいけない。
同僚のBob Payneと私は、すべての顧客のところで、作業開始前にこれら双方の定義についての最低限の同意を取ることの必要性を強く訴えている。 入り口と出口の基準を決めるときは、何かを抜かしてしまうリスクを減らすためにもチームの多くの人を巻き込む必要がある。
以下はReadyと完成の定義のサンプルだ。 なお、我々はアナリストやテスターや開発者に対してコンサルティングを行なっていることに注意してほしい。 あなたのチームや組織では、あなたはUXデザイナーやデータベース管理者やほかの人たちのコンサルティングをすることもあるだろう。 だが、やりすぎてはいけない。 まずは必要十分な最小限の範囲から始めていけばよい。
Readyの定義の例
アナリスト
ユーザーストーリーが十分に書かれており、要求とマッピングされていること
テスター
受け入れ基準が用意されている
開発者
ユーザーストーリーが見積もられており、スプリントの中で他の進行の妨げになるような依存性がないこと
完成の定義の例
アナリスト
動作するシステムがレビューされ、ユーザーストーリーが自動テストや手動のインスペクションによって受け入れられること
テスター
テストケースが通っていること。全ての重大なバグが修正されていて、それ以外のバグは識別されトラッキングされていること
開発者
テスト環境へデプロイされていて、コードレビューが終わっていること
あなたのチームではReadyの定義と完成の定義の一部として何が必要だろうか？定義はあるだろうか？
なお、PMI-ACPの試験を受ける人は、チームが完成の定義を作成する責任があるということを覚えておくとよいだろう。
それでは。
