スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ナノパーセント日をもちいた見積り


プロジェクトを見積もるとき、
ゼロパーセントではないが、かぎりなくゼロに近いプロジェクトの終了日のことを、
ナノパーセント日」と呼ぶ。

トム・デマルコ『ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解』日経BP社、2001年


 この1節を読んで、実際に調査をしてみた。次の図を見てほしい。
所要時間(発生確率)
 この図は、『ゆとりの法則』で紹介されているものを似た曲線を描くように数値化
して作成したものです。
プロジェクトの完了日を予測したもので、徐々に確率が高くなり、最終的にゼロに
なる状況を示したものです。
その確率が最初に現れる日を「ナノパーセント日」というわけです。
 まず初めに実際にナノパーセント日を経験則で実際に見積もるわけですが、
以下の条件として見積りを行いました。
・仕様変更による影響は考えない
・実装+ホワイトボックステスト(ユニットテスト)+デバッグまでを見積もる
・実装は中級のプログラマを想定する。
・適度なタスクに分解し、それぞれを日数(1日にできる作業は5時間程度)で見積もる

 この条件で算出した日数を「ナノパーセント見積り」と私は言っています。
実際にはこの日数ではプロジェクトは完了しないわけで、実際のプロジェクト完了日との
関係をいくつものプロジェクトで調べてみると不思議な現象が分かった。
それは、どのプロジェクトも
「ナノパーセント見積り」×1.7=「プロジェクトの完了日」
となるのです。(若干の誤差はあります)
「ナノパーセント見積り」を私が行ったからなのかと思い、別の人(中級レベルのプログラマ)にも
試してもらうと、やはり同じ結果で約1.7倍になり個人差がありませんでした。
残念ながら他社にお願いができなかったので、会社によって違うかもしれません。
恐らく、同じ会社であれば外的影響(仕様変更の量、プログラミング以外の業務など)が
似ているからかもしれません。

最初に紹介した図を累積表示に変えた次の図を見てほしい。
所要時間(発生確率累積)
 私が作成した図によると確率が50%になるのは2倍の位置だが、1.7倍は確率30%である。
実際はもう少しカーブの頂点が左に来るのかもしれない。
見積りの確率としては、不確実性コーンというのがあるが、またの機会にお話ししたい。
スポンサーサイト

テーマ : プログラミング
ジャンル : コンピュータ

見積手法


 Cohnは[Coc04]フィボナッチ数を使ってタスクの大まかな見積もりを作る方法を提案している。タスクには1,2,3,5,8,13,21,34,55,89…といったサイズがある。今まで正確な見積もりをしてきた実績のあるチームなら、21までのフィボナッチ数と40,60,80,100の4つの数を使って大きさを見積もる。

Johanna Rothman(でびあんぐる)『Manage It! 現場開発者のための達人式プロジェクトマネジメント』オーム社、2008年、第5章



 見積事態が正確ではなく、あくまで予想なので、このフィボナッチ数を使うのは非常に良いアイディアだと思います。
即ち7と思うのだったら5か8どちらがいいか考え8にするといった具合です。


 このフィボナッチ数を利用した面白い見積ゲームがある。
その名も「計画ポーカー
計画ポーカー

 これは、複数人で見積を行い、同時にフィボナッチ数のカードを出し合いサイズを決定するゲームです。
ここで注意するのが、平均を取ったりしないことです。
全員が不満のない数字になればよいのであって、全員が合意する必要がないことです。
計画ポーカーは見積が難しい場合に有効な手段ではないでしょうか。

テーマ : プログラミング
ジャンル : コンピュータ

性格

プログラマに向いている性格とは、どのようなものなのでしょうか?
 プログラミングにおいて必要とされる性格上の特徴のうちでも、もっともたやすく見わけがつくのは、多少ともきれい好きだ、とうことである。

 プログラミングにとって不可欠なもう一つの性格要因は、せめて少しばかりの謙虚さを持ち合わせていることである。

ジェラルド・M・ワインバーグ(木村 泉)『プログラミングの心理学-または、ハイテクノロジーの人間学25周年記念版』毎日コミュニケーションズ、2005年、第8章

きれい好き
これはソースコードのきれいさに結び付くものだと思います。
雑であるのは致命的です。

謙虚さ
プログラミングの世界は日々新しい技術がうまれ、技術進歩の速い分野です。
その技術を一人で全てマスターするのは不可能でしょう。
謙虚な気持ちで教わる素直な気持ちが大切だと思います。

テーマ : プログラミング
ジャンル : コンピュータ

ものつくりのセンス

 同じ物を違うプログラマに作らせたら、ほぼ100%ソースコードは違ってくる。
何故なのでしょうか?

 それはソースコードが芸術作品であるからだと、私は思っています。

 絵画を例にしてみると、上手い人もいれば、下手な人もいる。
下手な人同士でも違う絵を書くし、上手い人同士もそうです。

 『ハッカーと画家』で良いデザインについて次のように語られています。
良いデザインは単純である。
良いデザインは永遠である。
良いデザインは正しい問題を解決する。
良いデザインは想像力を喚起する。
良いデザインはしばしばちょっと滑稽だ。
良いデザインをするのは難しい。
良いデザインは簡単に見える。
良いデザインは対称性を使う。
良いデザインは自然に似る。
良いデザインは再デザインだ。
良いデザインは模倣する。
良いデザインはしばしば奇妙だ。
良いデザインは集団で生起する。
良いデザインはしばしば大胆だ。

Paul Graham(川合 史郎)『ハッカーと画家 コンピュータ時代の創造者たち』オーム社、2005年、第9章


 コーディングも芸術作品を作っていると意識すると、また違ったものになるのではないでしょうか。

テーマ : プログラミング
ジャンル : コンピュータ

言葉の魔力

 前回の記事でリファクタリングについて話しました。
不吉な兆候の一つで「重複したコード」という項目があり、
プログラマであれば、誰もが「」だと思っているはずです。

 この「悪」に対して使える言葉があります。
DRY [Don't Repeat Yourself] 繰り返しを避けること
レビューしているときに「それってドライ!」というような使い方をします。

 DRY原則を破るということは、同じ知識を2ヶ所以上に記述することです。
この場合、片方を変更するのであれば、もう片方も変更しなければならないのです。
さもなければ異星人のコンピュータのようにプログラムは矛盾につまづくことになるのです。
これはあなたが憶えていられるかどうかという問題なのではありません。
これはあなたが忘れてしまった時の問題なのです。
...
我々はこれが達人プログラマーの道具箱の中にある道具のうちで最も重要なものの一つであると考えています。

アンドリュー・ハント(村上 雅章)『達人プログラマー-システム開発の職人から名匠への道-』ピアソン・エデュケーション、2000年、第2章


 言葉が使い慣れてくると、実際にコーディングしながらも、「これってドライかな?」などと独り言が始まります。
「重複したコード」ではなしえないスキルアップです。

テーマ : プログラミング
ジャンル : コンピュータ

プロフィール

夢追

Author:夢追
芸術プログラミングの世界へようこそ

検索フォーム
最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
フリースペース
RSSリンクの表示
ブロとも申請フォーム

この人とブロともになる

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。