nDiki : ポートフォリオプランニング

ポートフォリオプランニング (portfolio planning)

プロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業。

参考

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

記事

2018年07月27日プロジェクトでみんなをバスに乗せるために書いておく項目リスト

2017年2月21日 (火)

第16回エッセンシャルスクラムを読む会

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の16回目。今日は第16章ポートフォリオプランニング。

これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。

ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。

本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。

今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。ライフサイクル収益には利益以外にも社員満足度・顧客満足度・従業員満足度(離職率と採用コスト・回復コスト)なども考えれれる」といったことを CSPO 研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。

本書によるとポートフォリオバックログに入れる際は

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。

とのこと。

ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。

と言い切ってます。迷ったら不採用という考えについて Joel on Software の採用面接ゲリラガイドを思い出しました。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]

[ 2月21日全て ]

2017年3月7日 (火)

第18回エッセンシャルスクラムを読む会

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の18回目。今日は第18章リリースプランニング (長期計画)。

今日は7人参加。

タイミング

リリースプランニングは一度限りのものではなく、スプリントごと行うアクティビティだ。

他のプランニング同様リリースプランニングも一度限りのものではないと明言されています。章の後半で説明される進捗の把握をしながら、スプリント毎に見直されていきます。

ポートフォリオプランニングでは「終わることのない作業」、エンビジョニング(プロダクトプランニング)では「一度やってそれで終わりではない」とそれぞれここまでの章で書かれています。全てのレベルにおいて継続が求められます。

ただスプリントプランニングをスプリントごとにやるとすると、どの程度時間を使うことになるのかが気になるところです。1週間スプリントの場合だと、さっと済ませるか何回かに1回にするのかが現実的なところでしょうか。

プロセス

各リリースには、明確に定義されたリリース可能な最小限のフィーチャー(MRF)がなければならない。(中略)顧客視点で、実用最小限の製品となっていることを確かめるのだ。

今の仕事は「フィーチャーごとにリリース」という方針でやっています。1スプリントで完成できるように例えばバックエンドという PBI にして先に完成させデプロイしておくというのをやったりしています。しかしバックエンドだけではここでいう MRF ではないですね。

いまチームではこのデプロイもリリースと呼んでいますが、エッセンシャルスクラム的に考えるとそれはリリースではないと考えた方が良いのかもしれません。

「各スプリントで価値を届ける」ことと「各スプリントでデプロイする」は同義でないと考え直した方が良いようです。

「いくつかのスプリントの成果物をひとまとめにしてリリースする」というプランニングの場合もあるのですから、毎スプリント必ずリリースするということに無理にこだわらなくてもということでしょうか。スプリントが終わった時点で常にリリース可能な状態になっていることが重要ということでしょうか。

リリース制約

気がつくと「スコープを固定」と無意識にしてしまいがち。ステークホルダーに期日を約束していないと、ずるずるとリリースを延期してしまいがち。

「スコープを固定」になる原因は、全体的なスコープがあまりにも大きすぎることであることが多い。

とあり、ここでもできるだけ小さくというのが推奨されています。MRF をいかに小さく定義しておけるかがポイント。18.4 節では「常にMRFを調整し続ける。」と書かれていて、MRF も適宜見直していくべきです。

期日を固定する方式がスクラムの原則にうまく当てはまるということなのでリリースプランニングの際にきちんと意識できるようにしたいです。

スプリントマッピング

主に複数チームで協調してスプリントを進めていくための話。ここは困ることが起きた場合にまた読み返したい部分です。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]

[ 3月7日全て ]

2017年10月20日 (金)

ポートフォリオプランニングノート #nNote

ポートフォリオバックログアイテム

プロダクト
プロダクトのインクリメント(1回分のリリース)
プロジェクト

など。以下プロダクト。

参加者

内部ステークホルダー
各プロダクトオーナー

インプット

プロダクトプランニング(エンビジョニング)されたプロダクト
- エピック(数カ月かかる複数回のリリースを含むユーザーストーリー)
- 技術的課題解決で粒度の小さいものは入れない。「プランニングコストが高くなる」「ポートフォリオプランニングまで待ちになる」となるので。
仕掛中のプロダクト

タイミング

定期的に行う。

アウトプット

ポートフォリオバックログ
- 承認されているがまだ始まっていないプロダクト
アクティブなプロダクト
- 承認されてすぐ開発に入るプロダクト・続行が承認されたプロダクト

プロセス

インフローの管理

プロダクトの開発を進めるか中止するか判断する。

コストをはるかに上回る価値を生み出せるか?

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。 — エッセンシャルスクラム

ポートフォリオバックログへの追加は年に1度ではなく、月に1回など。

小さめのリリースを頻繁に行うようなプロダクトのサイズにする。

スケジューリング (優先順位付け)

遅延コストに注意しながら、ライフサイクル収益(プロダクトの生存期間中に見込める利益の総計)の総量が最大になるように並べ替える。

遅延コストが大きいものを優先する。
サイズが大きいものを優先する。
遅延コストとサイズが異なる場合については(遅延コスト/サイズ)で比較する。

アウトフローの管理

WIP を制限する。全員の準備が整ったチームに割り当てる。

仕掛かり中のプロダクトの管理

 限界費用に注目して、継続・デリバリー・ピボット・打ち切りを判断する。

参考

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

2017年11月17日 (金)

push よりも pull

ポートフォリオプランニングについてディスカッションしている時に「各チームがバックログから pull して……」と言われて、あーポートフォリオバックログからプロダクトバックログへの流れも pull で考えた方がシンプルでいいなとあらためて思いました。

[ permalink ]

[ 11月17日全て ]

2018年2月16日 (金)

エッセンシャルスクラムを読む会: 第16章ポートフォリオプランニング

今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャルスクラムの「16章ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャルスクラムを読む会をやって以来なので久しぶりです。

前回のポートフォリオプランニングの章の回のノート

今回の自分のパートは以下。

16.5 アウトフローの戦略
16.5 仕掛品の戦略
16.6 終わりに

「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は

「作業者の手待ちではなく、作業の手待ちに注目せよ」
「WIPを制限する」
「チーム全員の準備が整うのを待つ」

がポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。

仕掛品の戦略は作業中のプロダクトについて

維持
デリバリー
ピボット
打ち切り

を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。

16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら

遅延コスト
小さめのリリースを頻繁に
WIP を制限する
限界費用

だとのこと。参考にします。

やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。

読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]

今日のさえずり: \Q \E し忘れるなんて、年を取ったものだな

2018年02月16日

09:39 \Q \E し忘れるなんて、年を取ったものだな。
15:15 今のチームでエッセンシャルスクラムを読む会をやった。ピンポイントで「16章ポートフォリオプランニング」が対象。学び。
17:12 映画らしい映画。 / “『バグダッド・カフェ』パーシー・アドロン監督インタビュー – NOW SHOWING” http://bit.ly/2BYlAAz
17:15 Naney の日記: デトロイト・自動車・フォード・朝鮮戦争・神父・人種差別・銃社会。まさにアメリカンな映画「グラン・トリノ」 http://bit.ly/2nZDVnf
17:21 belle恵比寿 PowerShot G9 X Mark II https://t.co/cpHdpcRyhE

[ permalink ]

[ 2月16日全て ]

2018年5月28日 (月)

WSJF (重み付けされた最短の作業から着手)という手法を使い始める

昨年11月から始めたポートフォリオプランニングでは、いったん各プロダクトについて

遅延コスト: 小・中・大・最大
期間: S・M・L・XL

とざっくりと見積もって優先順位決めをしていました。ライフサイクル収益最大化観点で「遅延コストが大きいもの」「期間が短いもの」優先として優先順位を決めていくことになるのですが、これだと両方異なる場合は単純に比較ができません。プランニングチームが慣れてきたので、そろそろ WSJF (Weighted Shortest Job First 重み付けされた最短の作業から着手)で考えていくことにしました。

「アジャイルソフトウェア要求」を参考に遅延コストと期間はフィボナッチ数による相対評価にすることにして、既存の見積もり記号にえいやと数値を割り当てて

 WSJF値 = 遅延コスト/期間

を計算できるようにしてみました。

記号とフィボナッチ数のマッピングが「えいや」という感じ。
遅延コストの3要素「ユーザー - ビジネス価値」「時間価値」「リスク削減/機会可能性価値」を理解しきっていなくてうまく分解できていない。

という状態なので学習しながらリファインメントしていく感じにします(遅延コストの3要素毎にそれぞれ相対評価していくのはちょっと大変そうではあります)。

プランニングチームメンバからは「そこに時間をかけても」という声も出ましたが「見積もりの話し合い過程での気付き」と「社内政治の排除(記事)」と得られるメリットが大きいので、うまく取り入れていきたいなと思ってます。

[ permalink ]

[ 5月28日全て ]

2018年6月7日 (木)

プロダクトの遅延コストの算出方法を考える

WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。

エッセンシャルスクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。

アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。

プロダクトについて

ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。

そして3つを足した

 [ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

を遅延コスト(CoD)とします。

正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。

とりあえずやってまた考えるという感じかな。

アジャイルソフトウェア要求

[ permalink ]

[ 6月7日全て ]

2018年6月26日 (火)

今日のさえずり: ポートフォリオプランニングが進捗会議っぽくなりつつある

2018年06月26日

07:00 SEIBU PowerShot G9 X Mark II https://t.co/enat27pPGP
09:49 2018年6月26日朝の渋谷。今日も暑くなりそう。 DSC-RX0 #RX0 https://t.co/XDNLdycuTQ
17:15 AWkitchen GARDEN 鎌倉。 #SEL1670Z https://t.co/LW7ZgOJthk
18:35 ふりかえるとポートフォリオプランニングが進捗会議っぽくなりつつあるな。反省。あとプロダクトプランニングが足りてない気がするので増やしたい。
25:08 干された布団最高だ。今日もいい一日だった。

[ permalink ]

[ 6月26日全て ]

2018年7月27日 (金)

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

タイトル
概要 (What)
目的(と背景) (Why)
ゴール (Goals) and/or 目標 (Objectives)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

プロダクト名
プロダクトビジョン
- 概要
- 目的(と背景)
- ゴール and/or 目標
- 成果物
- 完了条件
- スコープ(含むの・含まないもの)
- (opt) 依存するプロジェクト・制約条件
- (opt) リスク
- (opt) 予算
- (opt) メンバ
概要レベルのプロダクトバックログ
プロダクトロードマップ