ユーザーストーリーのReadyの定義

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

Definition of Readyが参考になる記事だったので抜粋・意訳にてご紹介します。

アジャイルな開発では（そうでなくてもですが）完成の定義は非常に重要です。人によって仕事が完了していることの理解が異なっていると、「本人は終わったつもりだったが他から見ると終っていない」とか「本人は終わっていないつもりだったが、他からみるととっくに終わっている」という状態になりやすくなります。前者は品質上の問題を抱えることが多く、後者は時間をムダにします。さらに言えば、そもそも着手するのに十分な状態でなければいけません。以下では着手するのに十分であることを確認するためにReadyの定義をしています。簡単に言えばユーザーストーリーを実装開始してよいかどうかを判断するためのチェックリストです。

開発チームはユーザーストーリーの実装をしてステークホルダーにレビューして良いかどうかを決定するために完成の定義（DoD）の考えを使う。完成の定義はユーザーストーリーの実装結果を見せる前に技術的な基準を満たしているかどうかをチェックする用心棒か門番のようなものだ。

完成の定義は強力なツールで、その明確な価値は、レビュー前にユーザーストーリーの実装結果の品質を保証するという点で明らかだ。そしてまた暗黙的な価値についても、同じように重要だ。完成の定義は開発チームとプロダクトオーナーの間での約束を形成する。この約束はストーリーが品質の基準点に達していることを保証するだけでなく、信頼の絆を形成する。プロダクトオーナーは、完成の定義を利用することで、開発チームが品質基準にあったものを提供してくれることを信頼できる、ということを理解している。そしてアジャイルな開発においては、信頼は成功のための鍵である。

受け入れ基準も同じようにプロダクトオーナーとステークホルダーやビジネスサイドとの間を結びつける。受け入れ基準はプロダクトオーナーがストーリーがステークホルダーの要求にあっているかを確認するのに役立つ。受け入れ基準はステークホルダーとともに定義するリストで、これによってステークホルダー側との信頼を形成する。ステークホルダーは、ストーリーの受け入れ基準を知らせているので、プロダクトオーナーが本当に必要としているものを提供してくれることを理解している。

完成の定義と受け入れ基準を組み合わせることでチームの成功に大いに役立つ。しかしこれらいずれもユーザーストーリーそのものがうまく書かれて定義されていて、受け入れ基準が実現性の無い魔法のような、あいまいな要求を全て欲しがるリストではないことが必要だ。

プロダクトオーナーは完成の定義と似たReadyの定義（DoR）と呼ばれるものを利用することができる。これを利用する理由は完成の定義を利用する理由と同じだ。これはスクラムチームが、プロダクトオーナーがReadyの定義を理解することを支援したり、ストーリーに関してより理解しやすいようにプロダクトオーナーが定義を行うことを支援するのに役立つ。

スプリントに収まるのに十分に小さい大きさであること
正確に見積りをするのに十分なくらいの詳細な情報を含んでいること
「完了」を明確に判別できるだけの十分な受け入れ基準を作っていること

プロダクトオーナーはただ空気からアイデアを引っ張りだすだけではなく、ユーザーストーリーを書き、バックログに落とす（僕らはそれを望んでいる）プロダクトオーナーはチームに対してチームが見積り、作業できるようにユーザーストーリーを書く責任がある。チームは自分たちの仕事をすすめ価値を届けるためにプロダクトオーナーの代わりに山のように仕事をしなければならない状況を望まない。このような状況下においてプロダクトオーナーやチームは「Readyの定義」が有効だと分かるだろう。「ユーザーストーリーをあなたたちに渡す前に、私のほうでできることは全て終わらせておきます」とチームに対して言うためのプロダクトオーナーが持つ約束なのだ。

「Readyの定義」のいくつかのサンプルを以下にあげよう

ユーザーストーリーがアクターと問題と価値を含んでいること
ユーザーストーリーがスプリントに収まるサイズであること
ユーザーストーリーが適切にドキュメント化されていること（ワイヤーフレームは必要？画面遷移図は必要？）
価値が明らかであること。もしそうでないなら、明確に記述すること
ユーザーストーリーが合理的な満足条件を持っていること
ユーザーストーリーは問題にフォーカスしており、ソリューションにフォーカスしていないこと

上にあげたサンプルを使うことで、我々は「ユーザーが精算する前に他の製品を見せる」という、AVのオンラインストアにおいてステークホルダーからの無造作な要求から始まっているユーザーストーリーをReadyの定義を使うことで以下のように書き換えることができる。

「顧客として、私がテレビやHi-fiやその他の製品を買う際に、同時に私が買いたいと思いそうな製品を見ることができる。それによって私は私が必要としている全てのものを同時に手に入れることができる。」

受け入れ基準：

「顧客に、その顧客が選んでいる製品を購入した他の顧客が一緒にショッピングカートに追加して購入した製品を見せ、購入した製品と同時に利用されるであろう製品を表示する。例えばTVを選択した場合は、ケーブルやテレビスタンドやブルーレイのプレイヤーを表示する。最終的にショッピングカートに追加した製品の購入割合やレーティングを表示する。」

これはアクターや問題や顧客にとっての価値を示している。ビジネスにおける価値は売上を増やすだろうという点で言わずもがなだ。ユーザーストーリーは合理的な受け入れ基準によって適切にドキュメント化されており、かつ開発者に対して技術的にどうやって完了させるかについては記述していない。

私はリリース計画ミーティングが好きだ。このミーティングはチームの完成の定義を点検することを含んでおり、それはチームメンバーがスプリント開始前にプロダクトオーナーやステークホルダーと相談して行いたい変更があるかどうかを確認することによって行われる。このタイミングがReadyの定義を行う理想的なタイミングだ。スクラムチームとプロダクトオーナーとの間での合意を形成することによって得られる明確な価値に加えて、Readyの定義は完成の定義や受け入れ基準と同じように信頼を形成するのに役に立つ。もしスプリントがうまくいかなかったら、ふりかえりにおいて完成の定義とReadyの定義を見なおせば良い。ユーザーストーリーはスプリントバックログの中に入れられる前にもっと多くの作業が必要だったのではないか？ Readyの定義は失敗の本質的な原因を探る際には完成の定義と同じようにものさしを提供する。

Readyの定義をプロセスに追加してみよう。特にユーザーストーリーを見積もるのが困難だったり作業にとりかかるのが困難だったりする問題を抱えている場合は有効だろう。信頼の構築や本当に価値をもつユーザーストーリーの作成という点ですぐに効果が現れるだろう。

それでは。