プロダクトバックログとは
プロジェクトを始める際に、そのプロジェクトがいつ終わるのか？という疑問が生じる。
100%の約束をすることはスクラムでも困難であるが、ある程度の見通しを立てることは可能である。
見通しを立てないまま、スクラムなら何とかなるだろうと思って進めてしまうと、後から取返しのつかないことになることもあり、実際に三か月ほどかかる想定だったプロジェクトが一年かかってしまったという例もある。
そして、その見通しを立てるために、プロジェクトの先がわかる計画が必要になってきて、それがプロダクトバックログである。
プロダクトバックログは、実現したいことがすべて書かれている表である。開発チームはここに書かれている項目だけを実現していく。そこにはリリースに不可欠な項目や、できれば実現してほしいというものも書かれている。
ユーザーストーリー
ユーザーストーリーとは、ユーザー・顧客視点での「フィーチャ」記述を指す。フィーチャとはソフトウェアを使う側の視点で記述され、xxx 画面等の機能ではなく「欲しい商品が注文できること」といった使い手にとっての価値を指す。
特に決まった記述形式は無いが、例として以下に示す。
＜ユーザー＞が、＜機能・性能＞にする。なぜなら＜ビジネス価値＞のためだ。
受け入れ条件
受け入れ基準は、、実装された機能がビジネス要求を満たしているかをチェックするためのものです。
- 確認者が、思い込みでOKにしないようにする。確認環境さえ整っていればサルでも確認ができる。
- 実装する人が、受け入れ基準を見てそれを最終ゴールだと思って実装できる。
このレベルの受け入れ基準が実現したいユーザーストーリーとセットで書かれていることで、実装するエンジニアは迷いなく実装に入れ、実装後の手戻りを防ぐことができる。
ストーリーを見ただけではわからない「曖昧な部分」を指摘し、より具体化することができる。
「曖昧な部分があるけど、これはなんとなくこういうことだろう」と実装者が自身の理解をいれないと実装に入れない受け入れ条件は良くない。
ストーリーポイント
ストーリーポイントとは、課題の大きさを表す数値である。
時間見積もりではない理由は、時間見積もりをしてしまうと人によって大きな差が生じるからである。人によって技術力が違うので、一つのストーリーに対して、実装するのにかかる時間が異なってしまう。
また、時間見積もりは属人化を作る原因となる。時間見積もりを正確なものにするためには、「必ず見積もった本人がその課題を担当する」「チーム全員のスキルレベルが限りなく近い状態のチームを作る」という条件が必要になってくる。
前者は、課題の属人化を招いてしまい、後者はほぼ不可能である。
利用できる数値は、フィボナッチ数列で、「1, 2, 3, 5, 8, 13, 21, 40」で、相対見積もりである。
これは、ある基準となる課題にポイントを付けて、その課題と比較して、今の課題が何ポイントか？を導きだす方法である。
ストーリーポイントは、時間見積もりよりも人によってずれにくいというだけで、正確な数値ではないため、ストーリーポイントを過信してはいけない。
ある程度のリリース予測を図ることができるだけである。
プランニングポーカー
ポイントで見積もる際に利用される手法である。
全員が一か所に集まり、ポイントの書かれたカードを持ち一斉に出し合う手法である。
ポイントが大きくずれた場合は一番大きな数値を出した人と一番小さな数値を出した人の意見をそれぞれ聞いて、全員で認識を合わせた後に再度見積もりを行う。
課題一つに対してあまり時間をかけてはいけない
プロダクトバックログの管理
プロジェクトは、プロダクトバックログに書いた項目を順番に終わらせていく。スプリントが始まった後も、状況に応じて追加・修正を行っていく。しかし、あとからどんどん追加されてしまうと見通しが立たなくなってしまう。
最初に重要な項目が漏れないように、スクラムチーム全員で書き出していく。様々な視点で洗い出すことで、致命的な漏れを防ぐ。
その後、優先順位を決めて、優先順位順に並べる。
プロダクトバックログは一度作成したら、終わりではなく、随時アップデートをする必要がある。
重要なのは、致命的な項目を漏らさないことで、正確な項目をすべて洗い出すことに時間をかけてはいけない。
コメント