アジャイル開発におけるプロジェクトの進め方
アジャイル開発において、色々悪い意味で誤解をしている方々が沢山いるので、
アジャイル開発をした事が無い方々の指針になればと思い書いております。
その1については下記を参照の事
アジャイル開発時におけるプロジェクトの進め方（その1）
その2については下記を参照の事
アジャイル開発時におけるプロジェクトの進め方（その2）
その3については下記を参照の事
アジャイル開発時におけるプロジェクトの進め方（その3）
プロダクトバックログのメンテナンス
一番はじめの頃のプロダクトバックログは、大まかな機能や実装したい内容が書かれていると思います。
初めの頃は、先を見通そうとしても、見通せないので、ストーリーの粒度は大きなものになると思います。
しかしながら、プロジェクトが進んでいくにつれて、仕様が明確になってくるものが都度あります。
プロダクトオーナーは、その都度、プロダクトバックログのメンテナンスを行い、内容をより詳細化し、優先度をつけ直す必要があります。
例をあげます。
一番最初は、以下のようなストーリーがあったとします。
- ユーザーのログインをする為に、ユーザー登録を行いたい
プロジェクトが進行し、詳細なユーザーというものについても顧客とすり合わせができました。
その際オープンIDでのログインユーザーも認めるため、ユーザーは自分たちのアプリ側で管理するものと、外部のオープンIDでログインするユーザーがいる事が判明しました。
そうすると、プロダクトバックログは、以下のように分割されていきます。
- ユーザーのログインをする為に、ユーザー登録を行いたい
- 自サイトで登録するユーザーの管理を行いたい。
- オープンIDで登録するユーザーの管理を行いたい。
当然オープンIDについて、何処のものを使うか等、さらに顧客と詳細が詰められれば、
今後さらにプロダクトバックログは分割されるでしょう。
プロダクトオーナーの中には、以下のような勘違いをしている方々が多いです。
「一度作ったプロダクトバックログは普遍であり、メンテナンスはしないです。」
そんな事はありえません。
機能の詳細がわかり、ユーザーストーリーの一部として落とし込めるようになったものは、随時落とし込んでいき、再度プロダクトバックログとして全体の優先順位を考慮するのです。
逆に、機能の詳細が随時わかってきているにも関わらず、プロダクトバックログのメンテナンスをしないプロダクトオーナーがいるのであれば、それはもはや自分の仕事を何処かに放り投げている状態です。
仕様について誰が抑えるべきか
回答からいいます。
プロダクトオーナーが全ての仕様を知っている状態でなければいけません。
これは新規の開発案件にしろ、既存の改修案件にしろです。
そもそも、プロダクトオーナーは、製品に対しての最終責任者で、それをビジネスとしてどう価値あるものとして提供するかの最終的な意思決定を行う人間です。
この人間が、製品の詳細がどうなっているかわからないなんて事は、ありえないのです。
しかしながら、現実的な問題として、製品の規模が大きい場合、プロダクトオーナー一人で仕様を把握出来るかと言われると、不可能なパターンもあります。
この場合は、プロダクトオーナーが、仕様調査が必要である事をチームメンバーに説明し、
スプリント0として、ある程度のクリティカルな仕様を洗い出し、調査する必要があるでしょう。
逆に一番やってはいけないのは、プロダクトオーナーが以下のような認識でいる場合です。
「仕様はわからないから、実装担当にまかせるよ。」
もはや、プロダクトオーナーとして役に立っていません。
製品の仕様をバラバラに確認し始めると、当然仕様として、不整合が起こった場合の調整すらもチームメンバーの担当機能単位で話し合う必要があります。
そんなバカげたことがまかり通るはずが無いのです。
もう一つの方法が、人数的に余裕があれば、チームを2つに分割し、プロダクトオーナーを二人にして、機能単位で、チームを別々に動かす方法です。
これであれば、使用調整は、プロダクトオーナー同士で行うので、チーム単位での実作業の優先順位等は、それが反映されている物として実装が行えます。
必ず意識する必要があるのが、プロダクトオーナーが仕様を抑える必要がないから、
直近の作業予定しか確認しないアジャイル開発ではないのです。
プロダクトオーナーが製品に対して責任を持つのであれば、その製品の利用方法についてもプロダクトオーナーは理解して、それをチーム内のメンバーに伝える事は当たり前の事であり、プロダクトバックログとならぶ最重要となるプロダクトオーナーの仕事なのです。
ここを勘違いしていると、そもそも物が出来上がってこなくなり、チーム内でも何がどうなってるのかわけがわからない状態になります。