タグ

projectに関するgaogaosanのブックマーク (6)

  • EXCELマクロでガントチャートを作ってみた - ITレシピ

    2007-2-18 Japanese/English スクリーンショット ストーリー EXCELガントチャート作るのはいいけど、イナズマ線を手で引くのはなぁ・・・・。 ってことで、ガントチャート(試作版)をEXCELで作成しました。 線はシェイプオブジェクトで引くようにしました。 感想&要望があったらコメントください。 11/25(日)追加 操作説明の動画を作成しました。こちらを参照ください。 http://mizhiro.mitelog.jp/taskline/taskline.htm ※動作確認 ○Excel2000 ○Excel2003 ○Excel2007 ダウンロード(作成したEXCELシートはコチラ。) 英語版(English Version)も作成しました(2008-07-14) New! tasklineV22.zip(10) 2008-07-1

  • 上流工程の問題解決 見積もり編【後編】

    見積もりの手法には大きく分けて「類推」「係数モデル」「ボトムアップ」 の3種類がある(表2)。係数モデルならFP法やCOCOMO/COCOMOIIなど,ボトムアップならWBS法と,それぞれよく使われる標準的な手法が確立されている。 見積もりの手法には大きく分けて「類推」「係数モデル」「ボトムアップ」の3種類がある(表2)。係数モデルならFP法やCOCOMO/COCOMOIIなど,ボトムアップならWBS法と,それぞれよく使われる標準的な手法が確立されている。 3種類の手法は,それぞれに向き不向きがあり,「開発工程や用意できる材料によって使い分ける」(三菱電機 白石氏)のが現実的だ。三菱電機 神戸製作所では「見積もりガイドライン」の中で,3段階に分けてどの工程でどの手法を使って見積もりを実施すべきかを定義している(図8)。 以下,種類ごとに各手法のメリットとデメリットを見ていこう。 類推法:初

    上流工程の問題解決 見積もり編【後編】
  • 上流工程の問題解決 見積もり編【前編】

    見積もりは手法こそ整備されてきたものの,精度を上げるのが難しくなってきた。現場担当者が疑問に思う七つの問題を取り上げる。 問題&解決 根拠なくして納得感は得られない 「こんな見積もりはのめない!」。味噌メーカー,マルコメの役員はあるシステム開発プロジェクトの会議の席上,決断を下した。販売/生産/財務など基幹システム再構築を発注していたベンダーとの契約を打ち切り,改めて他ベンダーを探すことになった。 プロジェクトは既に要件定義を終え,設計工程に入ろうとしていた。ここで最初に開発を発注していたベンダーが「最初の見積もりではできません」と,当初とはまるで違う再見積もりを通知してきたのである。 当初の見積もりと再見積もりの乖離幅は2倍以上。発注時に4社から相見積もりを取り,最も安価なベンダーに発注した経緯があるだけに,後になって2倍超ものコスト上積みなどとうてい受け入れがたいものだった。 現場の指

    上流工程の問題解決 見積もり編【前編】
  • MPUF (Microsoft Project Users Forum)

    Loading...

    gaogaosan
    gaogaosan 2006/09/25
    RFPテンプレート
  • 失敗プロジェクトを誘発するユーザー企業の姿勢 - @IT

    2006/9/6 「500人月以上の大規模プロジェクトでは5割近くで工期遅れが発生している」。日情報システム・ユーザー協会(JUAS)が9月5~6日に開催しているイベント「ITガバナンス 2006」で、JUASが4月に発表したユーザー企業の調査結果について、JUASの調査部会が解説した。同部会長の浜田達夫氏(JALインフォテック 代表取締役副社長)は「プロジェクト規模に応じて工期やコストの管理が難しくなっている」と指摘した。 調査は2005年11月から2006年1月にかけて、923社のIT部門と800社のエンドユーザー部門にアンケートを実施。ほかにユーザー企業42社と情報システム子会社20社にインタビュー調査を行った。 調査によると、500人月以上のプロジェクトでは46%の企業が「予定よりも工期が遅延する」と回答。100人~500人月未満では39%、100人月未満では21%で、プロジェク

  • Martin Fowler's Bliki in Japanese - ジャンケン見積り

    http://martinfowler.com/bliki/ThrownEstimate.html XPスタイルで計画を行っているのであれば、 見積りに関する開発者間の合意を素早くとる必要があるだろう。 こんなときは、ジャンケンで見積りだ。 ジャンケンで見積りを行えば、みんなの見積りが一致しているかどうかがすぐに分かる(一致してればそれを記入し、作業に入ろう)。 また、意見の不一致もすぐに分かる(一致してなければ、機能の詳細についてさらに議論を重ねる必要があるということだ)。 顧客が見積りの必要があるストーリーをまとめている。 以下は、それぞれのストーリーに対する基的な流れである。 顧客はストーリーの概要を開発者に手早く伝える。 開発者は顧客に質問し、ストーリーへの理解を明確にする。ここでは、どうやって実装するかといった技術的な議論はすべきではない。顧客の視点から見たスコープについて尋ね

  • 1