「自分が考えるデスマーチ」記事へのコメント

本当のデスマーチは

[TomonoriWatanabe (22504)]

> 「与えられた期間が、常識的な期間の半分以下である」
> 「エンジニアが通常必要な半分以下である」
> 「予算やその他のリソースが必要分に対して半分である」
> 「機能や性能などの要求が倍以上である」
> という4項目がデスマーチの定義とのことだ。

これらは、お偉い方々の目線かと思われます。
あくまで、現場での目線は・・・

１．期間が定かではない（度重なる遅延で麻痺）
２．何人のエンジニアが関わっているのか分からない
　　（度重なる増員で何処の島までが自分のプロジェクトか不明）
３．予算そのものが幾らなのか分からない（そもそも開発者には知らされていない）
４．そもそもの要求が何だったのか分からない（度重なる仕変のため、もともと存在したのかさえも？）

だと思うのですが・・・、如何でしょうか。

Re:本当のデスマーチは

[Anonymous Coward]

1.期間の見積が人月モデル
2.人員の見積が人月モデル
3.予算の見積が人月モデル
4.機能や性能等の見積を営業が行っている

Re:本当のデスマーチは

[Anonymous Coward]

1. 工数の見積りは人月ベース
2. 人月の見積りはLOC(Lines Of Codes)ベース
3. LOCの見積りは直勘ベース
4. 顧客の希望納期にあわせて投入人員を増加
5. 最終的に顧客の希望予算にあわせて見積りを圧縮・海外へアウトソース
6. こうしてできた見積りを営業がさらにお勉強して顧客に約束
7. 実際には要求が曖昧過ぎてアウトソースする前に仕様がなかなか固まらない
8. 仕様が固まらないが、仕様フェーズのスケジュールが大幅に押しているので見切り発車
9. こう変えて、やっぱりこっちの方がいい、やっぱり元に戻して、という顧客の感想レベルの仕様レビュー
10. 気が付けばテストフェーズの期間が計画の2分の１
11. 曖昧な仕様のせいで結合テスト時にアウトソースしていたプログラムとの結合で重大な問題が見付かる
12. アウトソース先に直してもらうより、現場で開発したプログラムでバグ吸収しようと汚い手段で四苦八苦
13. ようやく動くようになって見付かる大量のバグ
14. 結合に手間取り総合テストの期間が当初計画の5分の1に
15. 総合テストで見付かる受入難い性能問題・メモリリーク
16. 気が付けば来週納期

Re:やっべ

[Anonymous Coward]

ぜんぶ当てはまるプロジェクトしか参加したことねぇ・・・・

# 仕様書は出荷verのソース見て書けと教わりました。
# モジュール仕様書？ソースの要約のことですよね？

Re:本当のデスマーチは

[Anonymous Coward]

ウォーターフォールの開発そのものですね。
ウォーターフォール=デスマーチといってもいいのではないでしょうか？
変化に対して柔軟な開発手法が必要な時代になったということではないでしょうか？

Re:本当のデスマーチは

[Anonymous Coward]

ご冗談でしょう？
基礎から勉強しなおしてください。

Re:本当のデスマーチは

[Anonymous Coward]

はぁ、基礎？
waterfall 2006に参加して頭を冷やしてください
...http://www.mogusa.com/waterfall2006/