5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

大規模プロジェクトは未だに糞ばかりなのか

1 :仕様書無しさん:04/10/13 20:51:03
最近、某大規模(数千人月以上)プロジェクトに参加することになったんだけどさー、
各イテレーションの納期はRAD並なのに、
・ドキュメントちゃんとかけー
・レビューちゃんとしろー
・マネージメントちゃんとしろー
って、うるさいのなんのって。
おまけに、インターネットに接続してはいけませんだぁ?ふざけるな。

平均残業100時間っておかしいだろ

2 :仕様書無しさん:04/10/13 20:52:53
つつしんで 2get

3 :仕様書無しさん:04/10/13 20:53:51
http://higaitaisaku.web.infoseek.co.jp/cgi-bin/cbbs.cgi?mode=all&namber=46130&type=0&space=0&no=0

4 :仕様書無しさん:04/10/13 20:58:40
>>1
残業100時間って普通じゃないかな。
聞いた話だと、プロジェクトの内容を掲示板に書き込んだ馬鹿が
いて、インターネット禁止とかあるよ。
大規模プロジェクトが糞なんじゃなくて、大規模にすると
糞が紛れ込む。
そういうことですな。

5 :仕様書無しさん:04/10/13 21:00:47
>>1は糞と。

6 :仕様書無しさん:04/10/13 21:19:39
>4
帰ってから書き込むから禁止しても・・・
って、思ったけどお家には帰らせないんですね。

7 :仕様書無しさん:04/10/13 21:21:43
ちなみにどこのなんてプロジェクト?
そんなに大規模ならバレないでしょ
こっそり教えて

8 :仕様書無しさん:04/10/13 21:24:13
こんなところで言わないで、上の人に言ったらどうだい?

9 :1:04/10/13 21:26:20
ダメ。言えない。
今は200人くらいだけど、最終的に500人になる予定で、全体では2年のプロジェクトで、
今1/4あたりにいる、とだけ言っておこう。

10 :仕様書無しさん:04/10/13 21:26:59
>>8
他のプロジェクトの糞ぶりも知りたいんだよぉぉぉ

11 :仕様書無しさん:04/10/13 21:27:02
>・ドキュメントちゃんとかけー
>・レビューちゃんとしろー
>・マネージメントちゃんとしろー
大規模プロジェクトなら常識だろ。

>平均残業100時間っておかしいだろ
これも、なかば常識っぽいぞ。w

12 :仕様書無しさん:04/10/13 21:30:41
> 最近、某大規模(数千人月以上)プロジェクトに参加することになったんだけどさー、
> 各イテレーションの納期はRAD並なのに、
> ・ドキュメントちゃんとかけー
> ・レビューちゃんとしろー
> ・マネージメントちゃんとしろー
> って、うるさいのなんのって。
> おまけに、インターネットに接続してはいけませんだぁ?ふざけるな。
>
> 平均残業100時間っておかしいだろ

普通。むしろ恵まれてる。仕様書かかなかったり、レビューしなかったりの方が
俺には信じられん。デスマになったら、やってられんけどナー。

13 :1:04/10/13 21:31:59
今は各チームが小さくて(10〜20人)、けっこう選りすぐりの人材もいるんだが、
これから有象無象が入ってくると、デスマーチになるのは火を見るよりもあきらかorz

14 :1:04/10/13 21:35:47
人に嫌がられる後付情報。
作業用PCには、一切ソフト・ツールインストール不可。テキストはメモ帳で書く。
Unixで作業もして、選考チームはソースも書いてるのに、バージョン管理ツールが
インストールされていない。もちろん、インストール不可。
Perlはインストールされているが、それでスクリプトを書くのも不可。
シェルスクリプトで書けってさ。bashもzshもcshもないのにだぜ。

15 :1:04/10/13 21:36:28
アフォかーーーーーーーーーーーーーーー

16 :仕様書無しさん:04/10/13 21:36:59
あ、sccsとrcsはあるよ。あるけどさ・・・

17 :仕様書無しさん:04/10/13 21:39:35
そのぐらいの規模になると、詳細化の当たりで人が増えるのは普通。
何回かやった事有るが、基本設計やチーム間のレビュー、仕様書等が
確りしていれば途中で人が増えても問題は無い。
もし問題が起こるようなら、前から参加していた君の仕事に問題が・・・・

18 :仕様書無しさん:04/10/13 21:39:55
大規模でプログラム組む時は、C言語初心者にも判る。
てか、ちゃんとしてる大規模プロジェクトはバグ対応事に
プログラム変更仕様書+各レビュー議事録+テスト仕様書(論理+結合)
が当たり前。
バグ対応で鬱になりますぜ。
しかも他人のだとなぁ・・・・

19 :仕様書無しさん:04/10/13 21:40:00
>シェルスクリプトで書けってさ。bashもzshもcshもないのにだぜ。

普通、最低限bashはあると思うのだが。どういうUnixでつか?

20 :仕様書無しさん:04/10/13 21:42:24
うちのプロジェクトと似てるな。bashが無いところも同じだw

21 :仕様書無しさん:04/10/13 21:44:29
>>18
大規模でプログラム組む時は、C言語初心者にも判る。
↑消し忘れ・・・


22 :1:04/10/13 21:44:55
UnitTestでcppunit使いたいって言ったら却下されますた。
いや、公じゃなくて、内部で、個人で使いたいって言っても却下されますた。
すべてのビルトインコマンド以外使用不可だってさ orz

23 :1:04/10/13 21:47:05
でさー、バージョン管理どうするんですかって質問したら、いま*VSS*使った仕組みを
どこかが考えてるんだって。
つか、Unixで開発してるんだけど・・・

24 :マリーアントワネット:04/10/13 21:54:15
>>14
Perlが駄目ならawkで書けばいいじゃない

25 :仕様書無しさん:04/10/13 22:02:05
>>24
awkも駄目って言われそうだな

26 :仕様書無しさん:04/10/13 22:07:47
>>23
バージョン管理は「ディレクトリに全部コピー」でOK

27 :仕様書無しさん:04/10/13 22:19:13
>>1 = 山崎13

28 :仕様書無しさん:04/10/14 02:31:20
俺、規模的にも期間的にも似たようなプロジェクトに基本設計時に参加してた。
いちおうリーダーとして、詳細設計〜実装ではチームリーダーをやる予定だった。

…が、基本設計終了を待たずして辞めました。
・規模が大きいプロジェクトは、ただ単に「規模が大きい」だけ
・多くの場合は、分割統治に失敗している
・プロジェクトの人間が、トップ層も含めて愚痴と批判ばかり口にしている
・将来の2年間で自分がやることが見えた段階で、自分の成長がすさまじく鈍化すると考えた

運営や設計の具体点を挙げればきりがないけど、概ね上記の理由で辞めました。
今は自分の自由が効きまくる会社で、好き勝手にアジャイルにやらせてもらってる。

>>1よ、思うところがあるならすっぱりと切り替えたほうがいいぞ。
2年って、ことのほか色んなことができる。

29 :1:04/10/14 23:21:22
今日もお疲れ様、俺。
普通に作って1週間はかかりそうなもの(ざっと、クラス10個、公開I/F50個くらいかな)を、来週末までに作れとのこと。
ただし、次のものも用意せよだと。

・プログラム設計書(自然言語)
・フローチャート(!)
・関数仕様書
・クラス図
・シーケンス図
・テスト仕様書
・マニュアル(作成対象が、他チームが使うライブラリのため)

俺様、超残業モード突入の兆し

30 :仕様書無しさん:04/10/14 23:32:14
でさ、テストのやり方が秀逸なんだわ、これが(もちろん皮肉)。
まず、コードを印刷して、分岐やブロックごとに番号を振ってく。
1. a = 1;
  b = 2;
  if (c == 3) {
2.   d = 4;
  }
3. e = 5;
てな具合。
で、テスト仕様書に、実行ルートを書いていって、分岐網羅でカバレッジ100%の
テストができたかどうか「目で確認(レビュー)」しろだと。

死ね

31 :仕様書無しさん:04/10/14 23:41:26
>>30
デバッカー使わないの?


32 :仕様書無しさん:04/10/14 23:56:07
ドキュメント書く時間がメインになりそうだなそれ

33 :仕様書無しさん:04/10/15 00:00:49
>30
そんなんが最後まで続くわけない。
デスマ確定。ナームー

34 :仕様書無しさん:04/10/15 00:02:08
といか、プログラム単体なら
印刷して実行ルートを手書きでいいじゃないか・・・
そこは交渉しようぜ。


35 :仕様書無しさん:04/10/15 00:14:04
おそらく>>1が強く主張したであろう「テストツール買いましょう」という声に、
上の人間は何と言ったのだろうか。
とても興味がある。

36 :仕様書無しさん:04/10/15 01:14:12

「何それ?高そうだからだめ。」

37 :仕様書無しさん:04/10/15 01:49:29
>>30
目立で机上デバッグ(DT)と呼ばれている奴だ。まあ>>1は目立ではないと思うがな。
俺だったら関数仕様書とマニュアル(内部向けだろ?)は一緒にしてdoxygenで生成するけど。
後は、フローチャートとテスト仕様書を一緒にしてしまう裏技とか。詳しく書かなきゃいかんけど。
今俺がやっているのはその方法。後は、提出・レビューする際に巧みに話術で切り抜ける。
提出物にバグ管理表を、消化曲線付でつけておくとGood。

すでにテンプレとか成果物の点数が決まっていたらご愁傷様。
「2日ぐらい遅れます!」とか言って伏線を張っておき、2日分テストに充てる。

38 :1:04/10/15 07:15:44
>>31
チッチッチ。甘いね〜、僕チン。
デバッガー使ってテスト?リグレッションテストはどうするの?

てなわけで、今日も元気に仕事に出かける俺。
今日は交渉メインだな。頑張れ、俺

39 :1:04/10/15 07:16:33
>>37
doxygenも使えないんだわさ orz

40 :1:04/10/15 07:21:02
>>35
cppunitはフリーだから駄目ってことで即座に却下。
purifyは一応稟議を通してみますってことになってるんだが、望み薄。
いってきまー

41 :1:04/10/15 07:24:49
でも俺はcppunit使ってコーディングするけどね。
もうTDDじゃないとやってらんないし。
こっそりインストールして、毎日帰る前にcppunitとテストコードをアーカイブして
暗号化して保存しとく。で、元ファイルは全部消しとく。
就業時間中に見つかったら開き直る。

それが原因でクビ切られても、別にいいや〜。こっちから願い下げだ

42 :仕様書無しさん:04/10/15 08:45:58
>>37
うはは、日立は今もそんなことやってるんだ。
ご愁傷様です。

43 :1:04/10/15 22:01:15
えーと、玉砕したし、他の人の書き込みも無いので、これにて・・・

44 :仕様書無しさん:04/10/16 18:33:09
はっきり言って、「業に居れば業に従え」てことわざが有る。
嫌なら止めた方がいい。
それほどの規模のプロジェクトなら長い経験がある人たちがやっているのだろう。
その点、無駄に思えても間違いが無い事が多い。その点を学習できる機会でもある。
漏れの知ってるデスマは小〜中規模に多いと思っている。
数百名が係る規模は、デスマっぽく思える点もあるが、意外としっかり完成している。

45 :仕様書無しさん:04/10/16 18:39:12
>・フローチャート(!)

まだマシですね。おれが昔参加したC言語プログラムで上司が
変数のメモリーマップを書けとか言った(そいつアセンブラしかできない)
とき、真剣にどついたろかと思った。自動変数とかスタックの状況で
アドレスが一定しないんですけどーって説明したけど理解できないんだ。

46 :仕様書無しさん:04/10/16 18:41:16
>doxygenも使えないんだわさ

doxygen?はぁ?なにそれ?
とマジで聞いてくるメンバーのほうが多いと思うよ。
CVSの存在も知らない人も多いし。
バージョン管理はそのときの全ディレクトリをLHAで固めるだけ(w

47 :仕様書無しさん:04/10/16 18:42:46
>日立は今もそんなことやってるんだ

笑ってるけど、その日立のレベルにすら達していないプロジェクトも多い(w

48 :仕様書無しさん:04/10/16 18:51:30
>44
そうかなあ。
>29の(普通に作って一週間は間違いだと思うけど)
この量を来週末までにやれって時点で狂ってると思うが。

っつうか残業百時間が普通って感覚をいい加減にやめてほしい。
「普通」がそれじゃ、不測の事態があったときにどうしようもない。
なんでSEとかプログラマの無能は叩かれるのに
計画責任者の無能は叩かれないのかなあ……

49 :仕様書無しさん:04/10/16 19:00:35
>>48
ちょっと待て、その規模で失敗したら、普通工場長なり局長なりの首が飛ぶぞ。
なんか世間の見方間違ってないか?
度のレベルの責任者なんだYO!

50 :仕様書無しさん:04/10/16 19:01:45
いまどきバージョン管理ツールも使わないでどうやって大規模開発するんでつか?

51 :仕様書無しさん:04/10/16 19:03:29
局長っての変だな、本部長なり、取締役クラスが飛ぶよ。マジで。

52 :仕様書無しさん:04/10/17 02:12:17
残業をさせること自体、責任者の失敗なのだがそれもわからないのかね?

53 :仕様書無しさん:04/10/17 11:47:37
教科書男発見!

54 :仕様書無しさん:04/10/17 12:44:49
俺の生活の為の残業を責任者の失敗と言うのは許せん!!!!

55 :仕様書無しさん:04/10/17 12:49:10
完全にネタスレw

56 :仕様書無しさん:04/10/17 13:18:19
>>37
DTじゃなくてDDだろ。

57 :仕様書無しさん:04/10/17 16:06:18
>いまどきバージョン管理ツールも使わないでどうやって大規模開発するんでつか?

気合いと根性(笑)

笑えないけどな、当事者は

58 :1:04/10/17 18:23:46
お、書き込みが。

>>44
> それほどの規模のプロジェクトなら長い経験がある人たちがやっているのだろう。

長い経験がある人たちも居るよ。管理してるつもりのじじぃたちがね。

> その点、無駄に思えても間違いが無い事が多い。その点を学習できる機会でもある。
> 漏れの知ってるデスマは小〜中規模に多いと思っている。
> 数百名が係る規模は、デスマっぽく思える点もあるが、意外としっかり完成している。

数千人月以上の大規模プロジェクトはこれが三つ目だけど、今回のが一番ひどい。
前二つもたしかに完成したが、それは多くの屍の上に完成したものだった。
「俺先月400行ったよ」
とか自慢してるバカとかいたし、350前後で死んでる奴がかなりいた。(総作業時間の話ね)

まぁ、月100時間がフツーとかいう低脳どもがデフォの世界みたいなんで、
大規模プロジェクトはどこもこんな感じなのかもねw

59 :1:04/10/17 18:29:18
一個前の大規模プロジェクトでは、22:00から打ち合わせなんて日常茶飯事だったし、
ひどいときには28:00開始予定とかもあったw
んで、そこまで待ってたら、前の打ち合わせが延びて、30:00の段階で今日は中止します、だと。

60 :1:04/10/17 18:45:35
ちなみに、xUnitについて、金曜日に一時間ほど上の人間2人相手にレクチャーしたんだけど、
却下された理由が「バグ密度とバグ収束曲線が信頼できないものになるから」だった。
コーディング完の段階で、xUnitの範囲でバグが修正されていることがおきに召さないようだ。

氏ね

61 :仕様書無しさん:04/10/17 18:52:48
その「バグ密度とバグ収束曲線」のおかげで、バグ捏造とバグ隠匿の繰り返しだったよ。orz

62 :1:04/10/17 18:56:49
作業してるサーバ、ftpのポートが開いてるんだよなぁ。試しに使ってみたら使えたw
んで、あれとこれとそれをインストールしますた。
./configure, makeでmakeできない糞コンパイラだったけどなー

63 :1:04/10/17 18:57:25
>>61
お疲れ様でした。
俺もそうなるよ orz

64 :仕様書無しさん:04/10/17 19:47:01
>>ひどいときには28:00開始予定とかもあったw

この時間感覚、どっかで・・・・


65 :仕様書無しさん:04/10/17 20:58:41
> 28:00開始予定
俺が昔いたプロジェクトではありそうな悪寒…

66 :仕様書無しさん:04/10/18 00:38:06
俺が昔いたプロジェクトでも、26:00開始とかあったな。金曜深夜だったけど。
まあ、23:00くらいまで仕事して、何もせずにただ待つだけで金もらえてウマーだったけど。

あれはどこ仕切りのプロジェクトだったのかなあ?一個上は日立仕切りだったけど。

67 :仕様書無しさん:04/10/21 13:49:00
一体、>>1は何がしたいんだろう・・・・

68 :1:04/10/24 19:04:37
明日爆弾落として(もちろん比喩ね)、やめてやります。

69 :仕様書無しさん:04/10/25 14:20:22
うまくいってる大規模プロジェクトのリーダーは客がなかなか離さないだろうから
過去のプロジェクトで責任取らされ降ろされたような人達が「経験者」ってことで据えられる・・・・

そりゃうまくいくものもいかなくなるよねぇorz




70 :仕様書無しさん:04/12/29 14:27:13
>>44
>>はっきり言って、「業に居れば業に従え」てことわざが有る。

誰も突っ込まないけど、
『郷に入れば、郷に従え』 ではなかろうか。



71 :仕様書無しさん:04/12/29 15:25:19
上がチョッと駄目って言ったくらいで引き下がるからこういう事になるんだよ。
結局説明が足りんのよ。

72 :仕様書無しさん:04/12/29 20:54:33
上が糞なら、下に居てもしゃーないだろ。

17 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)