ストーリーポイントとファンクションポイント法の比較
ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。
ラフなメモ書き。
【元ネタ】
InfoQ: ストーリーポイントは複雑さや時間と関係があるか?
InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする
InfoQ: 価値とベロシティ、そしてバリューベロシティの比較
今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。
ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。
ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。
あくまでも固有のプロジェクトでしか通用しない規模の単位。
元来、開発規模は、ファンクションポイント法で厳密に測定する手法は既に知られている。
また、オブジェクト指向分析では、ユースケースポイント法として読み直す。
下記では、各業界のシステム開発において、1人月で何FP作れるのか、例示されている。
「システム開発の見積りのための実践ファンクションポイント法」によれば、15FP/人月がよく使われるらしい。
だが、ファンクションポイント法の最大の弱点は、測定する工数がかなりかかること。
熟練した経験者でなければ、意味ある測定値を計算できないだろう。
もう一つの弱点は、開発規模をファンクションポイント法で測定して見積もったとしても、予定工数や予定される納期へ変換するには、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とは全く違うこともよく分かった。
こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント