フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
ユースケースポイント法の変形見積もり - kosaruのはてな？
みたいなものを考えてみました。 基本、ユースケースポイント法なんですけど、ユースケースポイント法のアクターの係数を画面の機能数、ユースケースの係数を、画面に付随するCRUDの数や、発行する帳票、伝票の数や計算処理の数などでカウントしていってみてます。 基本的に、画面の機能数を（簡単=1 普通=2 複雑=3）、サブ画面を1とカウントします。ここがアクターの重みづけに相当します。 これ以下が、ユースケースの重みづけに相当します。 照会画面は基本1で、サブ画面毎に+1します。 異動画面にて新規・更新・削除の機能があれば機能数は3になります。その他、計算機能（税額自動計算機能等）があれば、その機能毎に（簡単=1 普通=3 複雑=5）します。 帳票画面では、出力できる帳票の数が機能数になり、発行画面では、発行できる伝票や証明書の数が機能数になります。 検索画面は基本1機能ですが、一覧表示画面等が含ま
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
