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