概要
Henrik Kniberg による 「Agile Product Ownership in a nutshell」がとても分かりやすくプロダクトオーナ視点からのアジャイル開発について説明している動画があったので、今回こちらをまとめてみました。
ぜひ興味ある方いればオリジナルの動画を視聴いただけますと幸いです。
Agile Product Ownership in a nutshell
PO(プロダクトオーナ) とステークホルダー
- PO(プロダクトオーナ) : プロダクトの詳細は知らないが、プロダクトを作っている理由を知っている。また、プロダクトに対する熱いビジョンを持っている
- ステークホルダー : 開発中のシステムを利用したり、サポートをしたり何らかの形で影響をうけることになる人たち
- ステークホルダーが求めることと PO のアイデアを表現したものがユーザストーリです。
- PO のビジョンはステークホルダーがシステムを気に入ってくれてることです。
開発者
- 実際には誰かがこのユーザストーリーをベースにシステムを作る必要がありますよね。
- これが小規模で部門を超えた人で構成される自己組織型開発チームです。
- 彼らは早いサイクルで頻繁にリリースします。
- ただ、早いサイクルでリリースするには開発チームのキャパシティを知る必要があります。
- キャパシティ計測 => スプリントで公開されたストーリ(ストーリーポイント)の数を数える
- 1スプリントでどれくらいチームとしてリリースできるかが分かれば、今度はそのリリースペースを維持できるように今まで手動でやっていたリグレッションテストは自動化できるよう自動テストと CI に多額の投資を行います。
さてさてここで問題が発生
- 1スプリントでリリースされるキャパシティには上限があります。
- しかし、そのキャパシティに収まる量のアイデアに制限されることなく、ステークホルダーはいろいろなものを要求してきます。
- また、リリースすればそれらを軸に新たなアイデアが生まれ多くのものを要求してきます。
- それらを全て開発チームが受けてしまうとどうなるでしょう。
- マルチタスク化やあらゆるよくないことが発生し、最終的にアウトプットが低下し品質が落ちます。
解決策は「Yesterday's Weather」
Yesterday's Weather とは、チームが次のスプリントで完了する可能性のあるストーリポイント数をすばやく計算するのに役立つスクラムパターンです。
- チームは過去3回のスプリントの平均ベロシティを、チームの規模に合わせて調整します。
- 次のスプリント計画中に、チームは次のスプリントのキャパシティの割合を決定します。
- 全員がフルタイムで働く5人のメンバーで配置されたチームで、次の1週間のスプリントで1人のチームメンバーが1日欠席する場合、チームのキャパシティは 96% になります。
- 最後に、チームのベロシティに次のスプリントのパーセントキャパシティを掛けて、次のスプリントの目標ポイントを決定します。
- 例えば、チームは同時に作業するユーザストーリーを5つした時に、彼らが1つのユーザストーリを終えると新しい1つのユーザストーリを受け入れます。(5つのユーザストーリという制限を超えないようにしながら)
- そしてこの時、「待ち」をプロダクトバックログといいます。
- 1スプリントにおけるユーザストーリのキャパシティは決まっているので、この「待ち」は必然と長くなります。
PO の仕事で重要なことは「No」と言うことと優先順位をつけること
え、じゃあ「待ち」が長くなるということは、要望してから長い「待ち」を経てリリースされるの？？それってアジャイルって言えるの？？ と思うかもしれません。
- 「待ち」が制御不能になることを防ぐ方法はあり、それは PO が「No」と言うことです。
- PO が全部を全部「Yes」といい続けたらバックログが増えていき「待ち」が発生し続けます。
- PO の仕事は「何をやらないか」を決めることにあると言えます。
- そしてその決定を合意させることですね。
- また、ここでプロダクトバックログにおける優先順位をつけることも仕事に当たります。
- そしてこれは、PO 一人でやるものではないということです。
- PO はチームや関係者とコミュニケーションを取り、協力して進めていきます。
優先順位の付け方
- PO が優先度をつけるときは、実装する機能の価値を意識する必要があります。
- この価値とユーザストーリの大きさを基に優先順位をつけていきます。
- ただ、PO はこのときユーザーストーリのサイズも価値も知る方法がありませんよね。
- ここで、開発チームや関係者とコミュニケーションを取っていき、ステークホルダーからは彼らが何を重視するのかを理解し、開発や作業の観点からユーザストーリのサイズについてどのように考えているかを理解します。
- ユーザストーリーに優先度をつけたたとして、これで良いのか。
- いいえ
- そんなことはなく、早くリリースするためにもユーザストーリを小さく分割する必要があるのです。
バックログミーティング
- これらユーザストーリの価値、サイズ、優先順位付け、分割 をするために「バックログミーティング」を行います。
- ステークホルダの数名、開発メンバーなどと一緒に検討していきます。
- ただ総じて PO に必要なことはコミュニケーションです。
- 開発チームにユーザストーリを提供するだけが仕事ではないということですね。
- 開発チーム、ステークホルダー、関係者全員がビジョンを理解している。
- 開発チームがステークホルダーと直接連絡していること。実際のユーザへ頻繁にリリースしているので、そのフィードバックまでのループが短いこと。そうすることで、開発チームは学び毎日のトレードオフを自分で決定できます。
1つ目のトレードオフ
ここでいうトレードオフの１つとしては、まず異なるタイプの価値の間でのトレードオフがあります。
プロジェクトの初期にある不確実性とリスクは敵です。
例えば、下記のようなリスクです。
- 社会的リスク
- 技術的なリスク
- コスト/スケジュール
なので、それらの不確実性を伴うリスクは減らしたいですよね。
そうすると、UI のプロトタイプや技術的なトライに焦点を当てて作業をします。
でもこれらってステークホルダーやお客さんにとっては直接的に嬉しくないです。ただ、リスクを軽減しているので、価値はあります。
なのでプロジェクトの初期は不確実性があるのですが、徐々に時間と共に経ていきお客様にとっての価値へと変わっていきます。
ここでいう価値というのは下記のような式で表せます。
そしてこれらの2つの価値の間のトレードオフを継続的に見つける必要があることをここではトレードオフと言っていました。
価値 = 知識としての価値 + お客さんにとっての価値
2つ目のトレードオフ
2つ目のトレードオフは、短期的思考と長期的思考です。
例えば、緊急のバグ修正を行うべきか、ユーザが喜ぶような新機能を開発すべきか、プラットフォームのバージョンアップをすべきかなど、長期的に見た時に重要なものと短期的に見た時に重要なものはいろいろあります。
それらを継続的にバランスを見ながらやる必要があります。
期待値調整
- プロダクトバックログには、上記のトレードオフの話にあったように改善のタスクや新機能の実装タスクなどが混ざります。
- ステークホルダーは、PO にきっと聞いてくるでしょう。
- あの新機能クリスマスまでにできない？？なんて
- ここでの PO の仕事はステークホルダーとの期待値調整です。(現実的な期待も含め)
- 嘘を言うのはダメです。
- PO の目的はできるだけ多くのアウトプットができるようにするではなく、望ましい結果にすることです。
- スプリントにおけるキャパシティは決まっています。
- それを守りつつ、可能な限り少ないアウトプットで結果にしていきます。
バーンアップチャート から考える期待値調整の示し方
波線が実際のベロシティを表し、緑色が楽観的な線。赤色が悲観的な線を表しています。
ベロシティも揺れ動くので特定の線に定まらないためです。
- 例えば、関係者が PO に「これら全ていつ完了するの？」と聞いてきた場合には、下記で話しましょう。
- 完了までのストーリポイントで線を引き、悲観的なラインと楽観的なラインの間がざっくり必要な時間となります。ここを正直にお伝えしましょう。
- 次に、関係者が PO に「~までにどこまで完成するの?」と聞いてきた場合には、下記で話しましょう。
- これは決まった納期に完了する範囲に関する質問です。
- 決まった時間に線を引き、その間に該当するものが完了する見込みのあるものです。
- 次に、関係者が PO に「~までにこれらの機能は完了しますか??」と聞いてきた場合には、下記で話しましょう。
- これは、決まった納期と決まった完了範囲に関する質問です。
- ×印を置き明らかに無理なことを言っていれば突き返しましょう「終わりません。」と
- ただ、ある時点においてここまでは終わるや、完了するのにこれくらい時間が必要です。は言えるはずで、この図から分かる真実だけを正直にお伝えするのがよいです。
継続的な改善や継続的な自動テスト修正をしていないとどうなる？
徐々に作業が遅くなり開発チームは残業をしないといけなくなります。
それを防ぐためにも、継続的な改善は必須ですね。
参考資料