« 個人タスク管理ツール かんばりすと | トップページ | Antを見直す »

2012/05/26

ストーリーポイントとファンクションポイント法の比較

ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。
ラフなメモ書き。

【元ネタ】
InfoQ: ストーリーポイントは複雑さや時間と関係があるか?

InfoQ: ストーリーポイントとは何か?必要ものなのか?

InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする

InfoQ: 価値とベロシティ、そしてバリューベロシティの比較

InfoQ: ストーリーポイントの間違った使い方。

今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。
ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。
ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。
あくまでも固有のプロジェクトでしか通用しない規模の単位。

元来、開発規模は、ファンクションポイント法で厳密に測定する手法は既に知られている。
また、オブジェクト指向分析では、ユースケースポイント法として読み直す。

下記では、各業界のシステム開発において、1人月で何FP作れるのか、例示されている。
システム開発の見積りのための実践ファンクションポイント法」によれば、15FP/人月がよく使われるらしい。

Sync-K : ファンクションポイントの換算値

だが、ファンクションポイント法の最大の弱点は、測定する工数がかなりかかること。
熟練した経験者でなければ、意味ある測定値を計算できないだろう。
もう一つの弱点は、開発規模をファンクションポイント法で測定して見積もったとしても、予定工数や予定される納期へ変換するには、COCOMOのような汎用的な経験値を使うか、実際のプロジェクトでリリース間際まで経なければ分からないこと。
COCOMOのような経験値を使って工数見積もりしたとしても、その見積りの正当性はかなり怪しい。
そもそも前提条件となるプロジェクトの状況(開発者の能力、チームの能力など)がCOCOMOのような経験値にぴったり当てはまるかどうか怪しいからだ。

それに対して、ストーリーポイントはメンバー全員で相対比較してとにかく早く見積もる。
そして、すぐにイテレーションを実施すれば実績工数が得られるから、Velocityを計算することができる。
つまり、Focus Factor=実際に作った規模/実績工数が計算できるので、
Velocity(見積もったVelocity)=予定稼働工数*Focus Factor
で計算できる。

すると、開発対象のシステムのストーリーポイントを機能単位に洗い出して合算した値から、Velocityで割れば開発期間を見積もることができる。
しかも、実施した1イテレーションでまず見積もれる。
この見積の数値は、COCOMOよりも説得力があると思う。
何故なら、実際にチームが短期間とはいえ1イテレーションで経験した工数を含んでいるから、少なくともその時点のチームの能力を表しているからだ。
そして、イテレーションをこなすたびにVelocityを測定していけば、チームの能力に見合った見積りを測定することができるだろう。

アジャイル開発の利点は機能単位の小刻みな小規模リリースだけではなく、チームの現在の能力に見合った見積りを提示できる点にもある。
顧客に、現在のチームの能力ではこれぐらいの期間でこれぐらいの機能(規模)を提供できます、とイテレーションのたびに説明できるのは、ウォーターフォール型開発よりもとても有利だ。

特に「アジャイルな見積りと計画づくり」で提示されたScrumによるストーリーポイント見積りは、見積りが計画づくりの重要な作業であることを認めた上で、見積りの手法やその注意点を細かく説明している点がとても優れている。

アジャイル開発の見積りで面白いのは、実績工数よりもVelocityを追跡することに注力することだ。
予定していたVelocityと実績のVelocityを各イテレーションで計測しながら、次のイテレーションの見積りに使う。
実績工数にこだわると、いかに時間をかけずに仕事するか、に開発者の意識が寄ってしまって、手抜き作業が起きる可能性もあるからだろう。
また、実績工数は規模や難易度によって大きく変わるから、あまり当てにならない。
Velocityの計測を追跡することによって、チームの能力をいつも気にかけるようになり、XPの言う「持続可能な開発ペース」を保持するのにも役立つ。

ストーリーポイントやVelocityはアジャイル開発特有の概念であり、その概念の意味はとても奥深い。
Redmineによるチケット駆動開発を通じて、WF型開発でよく使われるFP法やEVMとは全く違うこともよく分かった。
こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。

|

« 個人タスク管理ツール かんばりすと | トップページ | Antを見直す »

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 個人タスク管理ツール かんばりすと | トップページ | Antを見直す »