ベロシティをコース定数で理解する

ベロシティをコース定数で理解する記事がとても良かったのでメモ。

【参考】
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ

Dai Fujihara | mabl（メイブル）ノーコードテスト自動化SaaSさんはTwitterを使っています 「こんな定数あるのか。山の高さや行程ふまえての数値はわかりやすいなー / アジャイルな見積もりを理解する「コース定数」という概念 https://t.co/O5HeylyzvJ」 / Twitter

Miho??NagaseさんはTwitterを使っています 「身近なベロシティのたとえで図らずも山行について学べてしまった / “アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ” https://t.co/QMsU1aw12a」 / Twitter

プロジェクトのリスクはコストの増減で管理する: プログラマの思索

【1】アジャイル開発を日本のSIの現場でやる時に、5本の指に入るくらい壁があるのが、ベロシティやプラニングポーカーによる見積もりだろう。
日本のWF型開発案件は、PJ計画時にスケジュール、コストを可能な限り再現性のある絶対数値で見積もらなければならない。
一度決まった見積もりは計画と実績の予実管理のための指標となり、独り歩きして、その見積もりから離れられなくなる。

一方、アジャイル開発では、相対的な数値で見積もりする。
しかも適当な数値ではなく、フィボナッチ数を使って相対的な比較をもって見積もりする。
それをスプリントごとに計測して、実際の実績値を計測し、チームの生産性をベロシティを算出する。
ただし、ベロシティはあくまでも相対比較の数値なので、他チームの生産性と比較することは無意味だ。

WF型開発でもアジャイル開発でも、定量的なデータ管理は必須要件だ。
しかし、その扱いが全く異なる。
つまり、WF型開発は絶対的な数量、アジャイル開発は相対的な数量で算出する。

【2】以前、プロジェクトのリスクはコストの増減で管理する: プログラマの思索の記事で、リスクもコストという数値で定量化して測定すべきなのだ、という気づきがあった。
定量化した数値があるからこそ、洗い出した複数のリスクを比較して、意思決定できる。
そもそも、リスクというからには、リスクを回避したり、リスクを低減したり、リスクを解消するには、それなりの費用がかかるはず。
だから、リスクという、今は潜在的で分かっていない対象を費用という数値で定量化することで、見える化し、意思決定の根拠にするわけだ。

ソフトウェア開発の費用は、スーパーで売っている生鮮食料品、家電量販店で売られている電気製品とは違って、定価や希望小売価格を決めづらい。
なぜなら、価格の妥当性の根拠をとても説明しにくいのだ。
実際、ITに詳しくないユーザ企業の経営者から見ると、こんなボロカスで20年以上前の古いシステムの保守費用がなぜ数千万円、数億円もかかるのか、疑問に思いながらも、ベンダロックインされているためにベンダの言いなりになっているだろう。

その費用や価格を絶対的な数値ではなく、アジャイル開発では、相対的な比較で数量を見積もる点が上手。
相対比較であれば、その判断の根拠も簡単だ。
また、相対比較に必要な数値を算出する作業工数も少なくできる。

一方、WF型開発の見積もりは、プロマネが非常な労力をかけて案を出し、数多くの有識者のレビューを受けて初めて確定するから、見積もりを出すまでの工数が非常に膨大にかかりすぎ。
その割には、その見積もりは不安定であって、要件が少しでも変わってしまえば、その見積もりはすぐに無駄になる。
また1から作り直さなければ、正確な見積もりは定まらない。
なぜなら、要件の要素が一つでも変われば、その影響は要件同士の整合性、後工程へのスケジュール、新たな担当者のスキルなどの数多くの変数を考慮して、正確に見積もる必要があるからだ。
それくらい、WF型開発の見積り金額は、金額の妥当性の根拠を問われるから。

そういうことを考えると、アジャイル開発はソフトウェア開発特有の難しさを上手く飲み込んで対応しようとしているように思う。