Private content!This content has been marked as private by the uploader.
明日から使える実践的な見積もり手法
Private content!This content has been marked as private by the uploader.
コーディング ファスト＆スロー: 開発者と自信過剰の心理 | POSTD
今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって（非常に幸せな事業主の方々に向けて）ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました（少なくともそう信じていました）。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが大
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とその対策について※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。 「自分が開発すればこのくらいでできる」問題上司「この間言ってたプロジェクトの見積もりできた？」 マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」 デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」 プログラマ「PHP未経験なんだけど大丈夫かなあ…」 .... 略 .... 上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」 マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたん
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
時間の見積もりをどうするか？ －「仕事が忙しい！」の9割は思い込みだった【2】
完璧にスケジューリングしたつもりなのに、なぜいつも時間が足りなくなるのか。それは時間リスクの見積もりが甘いからです。 仕事の計画を立てるとき、万が一に備えて手は打ってあると胸を張る人は少なくありません。しかし、その多くは危機（ハザード）管理であって、リスク管理でないことに気づいていない。 ハザードとは、災害や事故といった事態のことであり、危機管理ではハザード発生時のリカバリーに主眼が置かれます。一方、リスクはハザードと違い、日常の中で予定どおりに進まない可能性があるものすべてを指します。たとえば「仕事中に突然、顧客が来訪する」というイベントは、けっして災害や事故ではありませんが、日常的で不確実という点では立派なリスクです。時間のリスク管理とは、こうしたイベントを事前に把握してマネジメントすることをいいます。 普通に仕事をしていれば、さまざまな時間リスクに出合います。「いざ外で仕事をしようと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
