📏

Azure DevOpsを使ったアジャイルの実践：見積もり編

2024/05/26に公開

Azure DevOpsをアジャイル開発で活用する方法を紹介するシリーズ（にしたい）、今回はアジャイルにおける見積もりの方法とAzure DevOpsの拡張機能Estimateを使ったプランニングポーカーによる見積もりの仕方について書きます。

PBIを見積もり

アジャイルで開発を進める場合、これから開発したいものをProduct Backlog Item (PBI)として登録し、プロダクトバックログを構成します。バックログに積んだPBIはすぐに開発着手できるわけでもなく、仕様概要の記載、受入れ条件の定義、PBIのサイズの見積をするなどのリファインメントを行い、準備完了の定義を満たす必要があります。

Azure DevOpsでのPBIのサイズの見積の値は、Effortフィールドに設定します。

そもそも正確な見積もりと計画は難しい

不確実性
↑\
| \
|  \
|   \
|    \
|     \
|      \
|       \
|        \
------------------
    時間の経過

この図は不確実性コーンといって、プロジェクトの進行に伴い不確実性が徐々に減少し、予測の精度が向上することを視覚的に表現しています。初期段階では、プロジェクトの詳細が不確実であるため、不確実性が高いですが、時間が経過し、プロジェクトが進行するにつれて、不確実性が減少し、予測がより正確になります。

プロジェクトの初期段階では不確実性が高く、判断するための情報が十分に揃っていない状態で正確な見積もりをしようとがんばっても、精度の低い見積もりになってしまうリスクがあります。
プロジェクトが進んで開発実績ができると、ナレッジや経験の蓄積により、不確実性は最初に比べると下がるため、最初よりは多少ましな見積もりができるようになります。
とはいえ、まったく見積もりをしないとそれはそれで計画ができないので、見積もり自体はする必要があります。

ストーリーポイントによる見積もり

ストーリーポイントは、PBIの作業量を見積もるための単位であり、絶対的な時間ではなく相対的な作業量を評価します。ストーリーポイントは、PBIの複雑さ、リスク、作業量などを総合的に評価して、数値で表現します。
ストーリーポイントが高ければ高いほど、そのPBIは不確実性が高く、作業量も大きくなるリスクが高いことを意味します。

工数見積もりvsポイント見積もり

ちょっと前に「工数じゃないと見積もりが難しい」という声があり、一旦「1人日＝〇pt」みたいな基準でPBIを見積もったこともありましたが、案の定いろいろと困って結局計画が煩雑になってポイント見積もりに戻しました。工数ベースの見積もりで発生した問題は以下の通りです。

ベロシティの精度が下がる

一番困ったのがこれです。工数ベースの見積もりの場合、突発的な問い合わせや会議依頼等の差し込みによって作業時間が容易に変動するため、実際どれぐらいの作業量をそのPBIに費やしたかの追跡が困難になってベロシティを出しにくいという問題がありました。

ベロシティは「開発の速度」を表し、そのチームがどの程度の作業量を1つのスプリントでこなせるかを表します。つまり、PBIの開発外に掛かった時間や作業量がベロシティに混入すると、純粋な開発の生産性をトラックすることが困難になります。

そのスプリントで完了したPBIのポイントを合算したものがベロシティとなり、次回のスプリントプランニング時にはダッシュボードでトラックしているベロシティを参照して、「今のペロシティこんな感じだから、今回のスプリントもこれぐらいできるよね」という風にプランニング時のインプットにしていました。

現実の開発生産性から離れたベロシティをインプットにしてプランニングしてしまうと、現実的にできる以上の作業量をスプリントで抱えてしまって、プランニングで選定したPBIを完了できないリスクも高まるため、開発者にとってもPOにとってもあまりよくないなと思いました。

見積もりの精度の低さと相対見積もりの困難さ

上記に記載したように、工数ベースの見積もりでは「純粋なPBI完了のために必要とした作業量」が完了後に評価しにくいという問題があります。これにより、過去に完了したPBIを基準に今後着手するPBIを見積もるときに基準として使用しにくくなり、また、見積もりの精度を向上させられそうにありませんでした。

見積もりに掛けるコストの高さ

PBI見積もり時に、「このPBIをやるときにどれぐらいの想定外の差し込みがあって結果使える時間はその時のスプリントでは合計〇hになるからそれから考えるとこのPBIに必要な工数はry)」シンプルに難しすぎるし、ただでさえスプリントという短い期間で開発とかテストとかいろいろやることもいっぱいあるのに、見積もりに掛かるコストが高くてつらい

そしてコストをかけた割には精度が高い見積もりができるかというと。。。orz

という感じで結構痛い目を見たので、ポイントベースによる見積もりに戻すことにしました。
結果、見積もりに掛けるコストを抑えながらも、リスクの少ない計画をすることができました。

Azure DevOpsの拡張機能Estimateを使用したプラニングポーカー

Azure DevOpsでは、オンラインでチームでプランニングポーカーによる見積もりができるEstimateという拡張機能があります。

Estimateによるオンライン見積もりセッションの作成

Backlogsで見積もりをしたいPBIを選択して・・・を押下し、Estimate work item(s)を選択します。

セッションの作成ダイアログが開くので、見積もりセッションの名前を選択し、ModeをOnlineにすします。Cardsでは見積もりに使用するポイントが記載されたカード群を選びます。

個人的には、以下のような理由からフィボナッチ数列のカードが使いやすくて好きです

ポイント間の間隔が適度に離れてて見積もりがしやすい
2と3の差とか5と6の差とか、ポイントの間隔が近すぎると作業量の違いを識別しにくい。。。
20以以降の数値が急激に増えるので大きなPBIを識別しやすい
内容が不明確で見積もりが困難であることを示す?が入ってるのもいい

↓これがフィボナッチ

正直一番直感的にサイズを見積もりやすいのはXS-XLのTシャツサイズですが、

残念ながらこれで見積もりをしてもPBIのポイントを表すEffortフィールドに値が入らず、消化ポイントの合計値をベロシティに設定して今後のPBIの着手時期を予測するForecastの機能が使えなくなるので、私はこれは使いません。。。

プランニングポーカーの進め方

1. チェックイン

見積もりセッションの作成ができたら、プランニングポーカーを開始します。
作成した見積もりセッションのURLをチームに共有/もしくはBoards > Estimateから対象の見積もりセッションに入ってもらいます。

2. PBIの内容を確認

プロダクトオーナー (PO)またはファシリテーターが各PBIの内容と目的を簡単に説明します。開発者は、この時点でPBIに対して質問があればPOやその他のメンバーやアドバイザーに質問をします。

以下の点に注目して確認するとよいかと思います

PBIのビジネス価値：なぜこの機能が必要なのか、ユーザーにどのような価値を提供するのか
PBIの要件に関して、不明点がないか
Acceptance Criteriaの明確さ：なにをクリアすればPBIが完了できると明確に理解できているか
作業イメージ：PBIを取り組む際に必要な作業のイメージは他のメンバーと同じか
技術的な複雑さの有無：実装にあたって技術的に難しい部分があるか。誰もそのPBIを達成するための実装イメージが持てない/実装に当たって新しい技術やツールの習得が必要な場合は、別途技術検証のためのArchitecture Spikeを作成し、そのSpikeが完了するまでPBIの見積もりを見送る。
依存関係の有無：他のPBIや外部システムとの依存関係があるかどうか。依存関係がある場合、その影響を見積もりに反映する。依存関係が明確にできてない場合、明確になるまで見積もりを見送る。
スプリントの中で収まりそうか：収まらない場合、サイズが大きすぎるのでPBIの分割を検討する。PBI分割の際は、下記のようにAcceptance Criteriaを基準に分割すると分割しやすい。

3. 見積もりの実施

開発者は、見積もりができる程度にPBIの内容を確認したら、Your voteの箇所でカードを選択して自分がこれぐらいだと思うストーリーポイントの数値を同時に選択します。
参加者が見積もりを行ったら、Revealを押下して全員が同時に見積もりを公開します。
全員が見積もりを公開して、見積もりの結果が異なる場合は、その理由を議論します。
議論が終わったら、再度見積もりを行い、全員が同時に見積もりを公開します。
見積もりが異なる場合は、3-4を繰り返して全員が同じ見積もりをするまで続けます。全員が見積もりに合意したら、Actionsで合意した見積もりのポイントのカードを選択し、見積もり完了です。

PBIの見積もりは、PBIを実施する開発者が行う（PBIに対する理解を深めるために見積もりセッションにPOやチーム外のアドバイザーに参加してもらうのはOKだけども、見積もりには参加しない）
カードを選ぶ前に「これは3！」とか言わない。（意思決定の際に提示されたポイントが他のメンバーの見積もりに影響を及ぼし、それ以降のPBIの見積もりに影響を与えるため）
多数決ではなく合意で選ぶ（「みんなが選んだから〇pt」はPBIのサイズを表さないため、見積もりの根拠を明確にした上でポイントを見積もる。同様に「つよいエンジニアがそう言ったから〇pt」もPBIの実際のサイズを表さない）

おわりに

「予測というのは難しい。とりわけ、未来については。」

ニールス・ボーア　「アジャイルな見積もりと計画づくり」より

序盤の不確実性コーンの話と、不確実性が高い中で頑張って工数ベースの見積もりをして上手くいかなかったエピソードから、PBIのサイズを正確に見積もりすることがかなり難しいということが示せたかなと思います。
「2. PBIの内容を確認」では、サイズが大きすぎるPBI、技術的な複雑さが高く実装イメージが持てないPBIや依存関係が明確になっていないPBIは見積もりを見送る、と記載しましたが、理由はすべて「PBIの見積もるには不確実性が高く、今はPBIを見積もるのに最適な時ではない」からです。

リーンソフトウェア開発の原則には、Defer Commitment（決定を遅らせる） という原則がありますが、見積もりもその一環で、不確実性が高い時期にはまだ時が来ていないので見積もりを遅らせることが重要です。よき時に立てた計画がよき計画になるということですね。

計画したPBIが上手くいかなかった場合は、よきときにPBIの見積やプランニングを行えなかった可能性があるので、見積もりと計画のタイミングを振り返ることも重要です（PBIが上手くいかないのは計画がだめだったとは一概には言えず、さまざまな要因があるので注意が必要ですが）。

また、初期に行った見積もりや計画は不確実性が高い中で行っているので、最初のうちは見積もりの精度が低いことを理解しておくことも重要です。スプリントを重ねるごとに、プロジェクトの進行に伴い不確実性が減少し、予測の精度が向上するので、見積もりの精度も向上していくことが期待できます。

スクラムの価値基準には勇気、確約、尊敬、集中、公開というものがありますが^[1]、見積もりや計画を行う際にも、勇気を持って不確実性の高い中で見積もりを行い、尊敬を持って他のメンバーの意見を尊重し、コミットメントを持って見積もりを行い、オープンネスを持って見積もりの結果を公開し、集中して見積もりを行うことが重要です。
また、見積もりや計画が誤っていた場合はそれを早期に公開し、計画を変更する勇気を持つことも必要です。

Reference

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
https://www.amazon.co.jp/アジャイルな見積りと計画づくり-価値あるソフトウェアを育てる概念と技法-Mike-Cohn/dp/4839924023
アジャイルとスクラムによる開発手法: Azure DevOpsによるプロフェショナルスクラムの実践
https://amzn.asia/d/aIC6DnM

脚注

スクラムガイド2017 スクラムの価値基準 ↩︎