とまと あんらいぷ…

エンジニアの活動記録とかつぶやきとか

GitHub

カテゴリ:プロジェクト管理 の記事一覧

進捗管理と終了予測

参画してるプロマネの判断力が異常でワロタ

たった14日で進捗が30%程遅れることになったのだが
包み隠さずきちっと報告してたら「コンフリクト対策」ということで
スケジュールをイジイジしてもらった。

本人さんは「数値遊びw」とか言っているが
あっというまに地ならし完了。
全員の進捗率が100%に戻った。

まだまだ若輩者だが自分の進捗のヤバさってのは分かってきたつもり。
PMをきちんと信頼して
正しい進捗を報告するとことで、
こうも綺麗に対策できるものなんだなぁ。
(被害をうけた先輩には今度うまい棒でも買おう)
資源(SE)があるかぎり、有効活用する手腕がものすごかった。

プロジェクトの進捗責任を負った時、
一番イヤなことは「虚偽」の報告をされること。
一気に破綻への道へ向かう。

だから、正しい報告を今後も心がけていこう。

と、ここで「数値のお遊び」なんだが
進捗率と完了予測の計算方法を( ..)φメモメモ。

◆進捗率
 Σ(作業の進ちょく率×作業の予定工数)÷ 計画した総工数

◆完了予測
 必要としている日数 =(計測日付までに予定した工数÷計測日付までに作業した工数(実績))×総日数

◆完了スケジュール差異
 必要としている日数-総日数

ですな。

解りやすく例に書くと

・全体で20日かかる見込みで計画したプロジェクト
・納期は10日後
・A君、B君の2人で作業している
・現在5日目
・A君の「個人報告」進捗率は80%でかなり進み気味
・B君の「個人報告」進捗率は10%で遅れ気味(ヤバイねw)

という具合。


まずは全体の進捗率の計算
A君、B君、共に予定工数は10日ずつ
5日目なので、計画通りに進んでいれば
ひとり5日ずつ作業をしてるから
総工数の半分なので、10日分進んでなけければいけない。

計算に当てはめると
 Σ(作業の進ちょく率×作業の予定工数)/計画した総工数

   A君:80%×10日=8日
   B君:10%×10日=1日
   ⇒9日 ÷ 20日 = 0.45%

全体進捗率は45%
一見、ちょっと遅れてるなぁ ぐらい。


完了予測は、現時点のペースで進ちょくした場合に、何日で計画を終了できるかを予測
(予定日数÷現在時点のペースとして計算)する。

A君:予定は5日分 実績8日分 = 3日進んでる
B君:予定は5日分 実績1日分 = 4日遅れてる

合計の予定は10日 実績は9 で全体で1日遅れている

10日(測定日の予定実績) ÷ 9日(測定日時点での実績) × 20日(全体予定) = 22.2日

このままいけば22.2日必要ってことになる。
ちょっとやばいなー。

という訳で
各個人の進捗トレンドを割り出してみると・・・

A君:5÷8×10=6.25
B君:5÷1×10=50

B君のスペックが相当やばいってことが分かる。
そりゃー、5日作業して1日しか進んでないんだもの。
5日分するのに25日かかるってことでしょ。
10日分するのには50日だ・・・自分で書いてて怖いw

腐っとる現場では良く、
B君が残業&休日出勤で頑張れ!
A君はサクっと抜けて次の現場へ!ってことがあったりする。

で、このまま割り振りをちっとも変えずにほったらかしにしておくと
実際には30日おくれましたー!wwwワロスwww
ってことになりかねないです。

全体で1日遅れてます!はヤバイんだよ。マジで。
人数が増えれば増えるほどね。

納期は20日目
これはほとんどの場合揺ぎ無いので
B君はこのまま頑張っても10日目までには2日分しかできないわけで・・・

逆にA君のスペックだと
予定した10日で16日分(10/6.25)できる。

てわけで
A君の作業を16日分に
B君の作業を2日に振り分け直す

この時点で

A君:5÷8×16分 =100%
B君:5÷1×2分  =100%

地ならし完了

しかし2日あぶれてるwww
急遽ヘルプで2日分誰か助っ人を呼ぶか、
A君に残業してもらって2日分補填するか。

A君なら残り5日で2日分増は現実的だからね。
眠いだろうけど。

どっちにしても最初に導き出した22.2日必要な事には変わりないのね(笑)
ヤバさがマシになるだけで。

とまぁ、こんな感じで
進捗と実績とスペックを数値化して
コネコネするとプロジェクトの全体が把握できますよー。
ってな感じなのかな?

といってもあくまでも「正しい進捗報告」があってこそ成り立つ計算方法
難しいわwww

デスマーチが起きる理由 - 3つの指標

デスマーチが起きる理由 - 3つの指標

とりあえずまぁ。
読めと。ね。

アジャイルでいこう

ちーとばかり、古い記事なんだけどね。

ソフトウェアの新たな開発手法、「アジャイル開発」って?

下請けと元請けの立場で契約しちゃうと
たとえウォーターフォール開発といえども
当然のように仕様変更が降ってくるわけで・・・

会社の立場が弱いと 契約はウォーターフォールなのに
開発はなんちゃってアジャイルっていう
一番ダメパターンが横行しているわけなんですよ。
特に大阪

もちろん、元請けもエンドユーザーからの要求を受けて
下請けに振ってるんだろうけどさ。

Googleが気の狂ったような技術を自慢げに誇張するもんだから
お客さんがプログラムを魔法と勘違いしちゃってるんだよな。
「ね?簡単でしょ?」みたいな事をさらっと要求してくるんだな。

頼むよwww金と時間をくれ!
と社内の中心で叫びたくなるよまったく。

それはともかく、
一括で仕事を振るなら、ウォーターフォールなのかアジャイルなのか
しっかり契約しないと
優秀になるかもしれない開発者が死ぬんだよ。

プロパーからすると
駒のように使う方法を勉強してるから
ウォーターフォールで契約して、後で仕様変更を小出しにしてやれば
社内で工数が跳ね上がらないからラッキーなんだけど
受ける側と発注側の攻防をさ、考えて・・・

こんな政治的な葛藤も含めてやっていかんとダメなんだなー。

いずれにしても、政治形態から考えるとアジャイルは向かないし
開発目線で行くと攻防が発生するとウォーターフォールはやってれん。

なんかいい感じの開発モデルはないもんだろうか。

要件定義の勘どころ

あまりにも更新してないと錆びれてしまうので、とりあえず更新。

要件定義に含める内容
・このシステムの目的(価値)は?
・どのような責務を持つ人に使われるのか?
・どのような外部システムとかかわるのか?
・システムはどのような使われ方をするのか? 
・システムとの接点は?
・その時の入出力情報は?
・システムに必要な機能は?
・その機能が使用するデータは?

これぐらいいれとけってさ。
CodeZine

引継ぎは、ミスれば死ぬ

「Dalmore君、来週でまでに○○プロジェクトの引継ぎをしておいてくれ。」

なんて言われたら、きっとデスマーチの始まり。

引き継ぐ人も、引き継がれる人も
継続開発の「とっかかり」
みたいなのがあれば何とかなるはず!(なんとかして!)

でも、引継ぎなんて日々徒然とは起こらないので、うまくいかないときが多い。
せめてこれだけはあればいいんじゃないかな。


①担当するプログラム一覧

⇒既存ドキュメントのマップ

②各プログラムの相関図とか概要とか(全体像が分かりたい)

③業務的(マニアック)な知識が必要であればそれも

④ソース修正からコンパイルの仕方、生成物(exe等)にたどり着くまでの手順(画面もほしいな)

・ビルドの詳細な手順(スクリプトとかあればなお可)

⑤お作法(どのライブラリを使ってるとか、細かいとこだと、コンパイルオプションがこれだとか)

文字列という概念がない言語を急にまかされたり・・・・無理!ほんとに無理。

⑥開発に必要なソフトウェア一覧とそのインストール方法

⑦各種連絡先

⑧過去のメールのアーカイブ


最低限これだけは揃えてあげたいし、揃えてほしい。

テーマ:雑記 - ジャンル:ブログ

FC2Ad