＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

デスマーチの回避策は？

1
投票結果総投票数：72
見積り 24票 33.33%
作業範囲 4票 5.56%
ﾚﾋﾞｭｰ 3票 4.17%
ｺﾐﾆｭｹｰｼｮﾝ 9票 12.50%
ﾌﾟﾛｸﾞﾗﾑを作ったことがある所員が開発を取り纏める 32票 44.44%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。
投稿者投稿内容
Hindows
会議室デビュー日: 2005/11/18
投稿数: 2
投稿日時: 2005-11-18 13:09
デスマーチに陥らないために
あなた、またはあなたのチームでどのような回避策をとっていますか？
有効だった。無効だったなどの感想を添えてくれるとためになります。

[ メッセージ編集済み 編集者: Hindows 編集日時 2005-11-18 13:24 ]
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2005-11-19 00:08
私自身はデスマーチプロジェクトに開発者として携わった経験がないのでよくわかりませんが

テクニカルアドバイザ（ノウハウの少ない新規技術を使うプロジェクトで、その技術を社内で一番理解しているということで駆り出された、平たく言うと「歩くマニュアル」扱い（笑）; プロジェクトの責任は負わない）として関与したことはあります。
そこで得た教訓としては以下の三つがあります。

  1. 人を増やすな。
    増員したメンバには教育コストがかかる。それを開発者に捻出させるな。
  2. 管理者は現場の惨状に目を向けろ。
    そしてその責任が自分にもあることを体感せよ。
    顧客にいい顔をするだけの人物はプロジェクトには不要。
  3. 過去のデスマーチ回避実績を開発者に期待するな。
    もし回避できたことがあったとしても、それは開発者の最高速度によるものと考えろ。
    それを平均速度や最低速度と見なし、より高いパフォーマンスを期待するのは愚の骨頂である。

他にも「実装を 27:00〜27:25、テストを 27:25〜27:30 に完了などという実行不可能なスケジュールを立てるな」などありますが、当たり前なので割愛します。

より整理され詳細に書かれた山崎敏氏によるサイト（Software Design 誌に掲載された記事の原稿）が公開されていますので、こちらもご覧になるとよろしいと思います。

やまざき＠BinaryTechnology（「コードデザイン最前線」が当該記事）
http://www.01-tec.com/

[ メッセージ編集済み 編集者: Gio 編集日時 2005-11-19 00:13 ]
ライスチケット
会議室デビュー日: 2005/08/11
投稿数: 5
投稿日時: 2005-11-19 00:40
「所員」ですってよ・・・

(´д)(´д｀)(д｀)ﾋｿﾋｿ
セミプロ
会議室デビュー日: 2005/12/21
投稿数: 3
投稿日時: 2005-12-21 13:47
ホウレンソウを徹底する。
これに尽きると思います。
要するにコミュニケーションですね。
あゆみん
会議室デビュー日: 2006/01/06
投稿数: 2
お住まい・勤務地: 東京都
投稿日時: 2006-01-06 02:45
リスク管理ですかね。
みんな頭ではわかっていても、キチンと実践するのは難しいものです。
1

スキルアップ／キャリアアップ（JOB@IT）