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

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

ウォータフォールは死滅!これからはXPで決まり!

1 :仕様書無しさん:03/11/11 10:57
いまどき滝モデル使うプロジェクトは負け組み

2 :仕様書無しさん:03/11/11 10:59
エクストリームプログラミング(eXtreme Programming = XP)
http://objectclub.esm.co.jp/eXtremeProgramming/


3 :仕様書無しさん:03/11/11 11:09
また死滅スレか

4 ::03/11/11 11:10
XPって、受託開発以外には適用できないんだろうか?
たとえばゲームをXPで作るとして、どうやればいいもんなの?

5 :仕様書無しさん:03/11/11 11:19
キゴ猫でわかるXP
http://objectclub.esm.co.jp/eXtremeProgramming/angya/dorama/gikonekoXP_all.pdf

6 :仕様書無しさん:03/11/11 17:21
>1にあてはまるのはどれかな〜

1)XP=ペアプロ+ユニットテストだと思っている。
2)小規模な仕事しかやった事が無い。
3)XPを銀の弾丸だと思っている。
4)ウォーターフォールモデルを理解していない。
5)XPのMLをヲチしていない。
6)コードを書くのがマの仕事だと思っている。

7 :仕様書無しさん:03/11/11 19:48
>>4
万能薬(銀の弾丸)は無い。
ゲーム開発だと、XPでない他の方法論が必要だと思う。

8 :仕様書無しさん:03/11/11 20:03
ウォーターフォールモデルって今まで30年間ほど誤解され続けている。
って知っているかな?

9 :仕様書無しさん:03/11/11 20:05
>>8
おまえがな

10 :仕様書無しさん:03/11/11 20:46
伝説のアイテム「銀の弾丸」は見つかりませんでした。
でも代わりに、「銀のやっとこ」を入手しました。
定時に帰れて今の私は幸せです。

11 ::03/11/11 21:01
>>8
詳細きぼんぬ。

>>7
大規模には向かないとか大人数には向かないとか、
顧客が一人じゃなきゃいけないとか、開発室にいなきゃいけないとか、
そりゃ出来たら苦労しないって前提条件があるのがXPの醍醐味だよな。

Windowsのバージョンと間違えそうな名前もいいし、
もっとXPが普及して、アフォな顧客が「とりあえずXPで頼む」と言うようになったら、
「最適ペース(週40時間労働)」で帰れるし。これからはXPだな。

プラクティスも増えに増え続けて覚える気もしなくなるくらい充実してるし、
そのうちきっと「満足な予算」とか「綺麗な美女」とかも追加されるに違いないぞ!!


12 :仕様書無しさん:03/11/11 22:55
>>11
きっと、XとPの間に小文字のoが入ってるに違いない(w
http://www.geocities.co.jp/Technopolis/8931/index24.html

13 :8:03/11/11 22:56
>>11
http://www.ivis.co.jp/prof/07.html
とか
http://d.hatena.ne.jp/satoshis/20031017#p1
に出ている。
まあ同一人物(知ってる人は知ってる人物)の記述だが。

14 :仕様書無しさん:03/11/11 23:01
6項目を思いつく思いつく>>6>>6の6項目に全て当てはまりますね。
どうやら抵抗勢力はXPだけを目の敵にしてウォータフォールモデルとXP
以外は目に入らないようだw


15 ::03/11/11 23:34
最近では「プラクティスは必要に応じて取捨選択せよ」って言ってるのね。XoPだw

>>12
おもしれー。ワロタ。ありがd。

でも、漏れはXPブームのおかげで、何となく考えてた開発方法論を体系付けれた気がする。

>>13
こちらもありがd。
こうして照らし合わせると、手法問わず、
開発って、みんなおいしいとこどりをしたがって失敗していってるんだねえ。
ソフトウェア開発とは、つくづく共同幻想なりよ。

>>14
日本語をリファクタリングしたまえ。

16 :仕様書無しさん:03/11/12 00:11
後戻りができなければウォータフォールモデルとは
言わないよな?


17 :仕様書無しさん:03/11/12 00:26
自動テストとリファクタリングがあれば、
あとは、
まあ、
いいや。

18 :仕様書無しさん:03/11/12 00:54
後戻りを許さない奴を叩いてやりたい。

19 :仕様書無しさん:03/11/12 08:58
予算無いからおまえ一人で何とかしろといわれたらどうするンよ。

20 :仕様書無しさん:03/11/12 09:48
もちろん予算を優先する。
が、時間が余れば自分のできる範囲で予算がかからない後戻りを提案、実践してみる。


21 :仕様書無しさん:03/11/12 09:50
既存の過去の資産には後戻りを適用することは
まず考えず。

しかし、既存の資産を再利用しつつ新規に機能を追加するときは
Adaptorパターンなどを適用する。

22 ::03/11/12 13:34
いずれにせよ「後戻り」はするべきでは無いと思うんだが。

たとえば、開発フェーズで設計上の問題が発生してうまく続行出来ない事が判明した場合、
そのプロジェクトは「計画上の失敗」であり、それを成功にする事は原則的に不可能だ。

XPの小規模リリースがもたらすのは、この「失敗」の被害を最小限にする事であって、
過去のイテレーションの失敗を成功に変えたりする事は出来ない。
もちろん、「次の」イテレーションで再計画して成功させる事は出来るだろうが。

ウォーターフォールの最大の問題は、設計フェーズが正しく終わらないままに、
開発フェーズを開始してしまう事でないの?
ここに開発者優勢の「フィードバック」を入れて、その設計で開発する事が可能であるという
「お墨付き」を開発から貰う事で完結するようにすれば良いのでは無いかと。

# 日本式SE/PGの区別は、このあたりで「邪魔」になると思うんだけどどうか。


23 :仕様書無しさん:03/11/12 16:46
>>22
うーん、君は他のレスでも見かけるがちょっとずれているぞ。
WFの最大の問題は設計フェーズが正しく終わらないままに
開発フェーズを始めてしまうことではないぞ。

設計も開発も正しく終了するのだが、得られた物を誰も望んでいなかった
ということが問題なのだ。

24 :仕様書無しさん:03/11/12 16:51
ようするにやり直しに名前を付けてかっこよく言っただけだろ?

25 ::03/11/12 16:59
コテハンで書き込みまくった甲斐があった。ちょっと嬉しい。
よろしくお願いします。

>>23
> 得られた物を誰も望んでいなかった

それは「設計も開発も正しく終了した」事にはならないのでは?
要求定義から納品までの流れでもって、
「望んでいない物が出来てしまった」部分に、「正しくない」要素があると思うぞ。

>>24
語弊を覚悟で言えば、そう。かっこいい事がとにかく重要。


26 :仕様書無しさん:03/11/12 17:25
>>25
うーん、言葉の定義に入ってしまうとそうなんだが、
結局の所何を望んでいるのか?ということを、定義出来る人は
少ないって事なんだな。

確かに要求仕様書通り設計書通りにものは出来ている。
でも「なんか違うんだなー」(w
違うって事はわかる。 正解はわからないにしても。

WFモデルは望んでいる物を定義できることが前提なのが
問題と言っても良い。 逆に言えば定義できるなら、ちゃんと機能する。
罠はたくさんあるにしても。

27 :仕様書無しさん:03/11/12 17:37
>>23
>設計も開発も正しく終了するのだが、得られた物を誰も望んでいなかったということが問題なのだ。
それは大昔から言われていることだね。
「それは違うよ、望んだものと得られたものが違うというのは設計の前段階の要求定義が間違っているからだ」
などと言ってもあまり意味が無い。
その問題を分析しなければ、いつまでたっても「望んだものと得られたものが違う」という状況は改善されない。
問題の分析結果は以下。
「WaterFallは現フェーズの成果から前フェーズの成果の正否は判断不能である。例えフィードバックがあったとしても」
#逆は可能なのだが。

だからこそ、RAD、XP、UPなどの新たな方法論により、
要求と実装の論理的な距離を短くするという試み/実践がなされているわけ。

28 :仕様書無しさん:03/11/12 17:49
大規模の場合は、基本設計まではWFでしかできないだろ?
で、各機能分解できた段階からスパイラルしてパーツを構築。
結合フェーズからはまたWF。


29 :仕様書無しさん:03/11/12 17:51
XPって携帯電話の開発とか組み込み系向きだと思うよ。
テストツールなんて、DB絡む業務系だと今一有効性にかける。(DB込みのテストツールは知ってるけど。)

30 ::03/11/12 18:05
>>26-27
話の大筋が出来てきた。

本質的に、「要求定義が出来ないのに成果物をほしがる事」が問題で、
開発者という立場である我々は、顧客が要求定義をする手伝いをする訳だ。
その結果、顧客が要求していた事は思いのほか小さくて簡単なので、
顧客はあまりお金を払わずに問題を解決できました、と。

常に実装が不必要に膨らむ事が無いのが新しい方法論の行き着く先なら、
頑張れば頑張っただけ開発者の取り分が減るという労使の問題が解決できないよねえ。

# という方向に話を持っていきたいんだけど、だめっすか?


31 :仕様書無しさん:03/11/12 18:26
>>30
それは、根底の価値観が人月だからでは?
成果物に対する評価で対価が決まれば、効率よく作業をした人が評価されるっしょ。


32 ::03/11/12 18:49
本当にわかんないんだけどさ。

>>31
要求定義が出来ない顧客が、成果物に対して妥当な評価を出来るとは思えない。
「実際に顧客に利益があがったこと」なんてのは評価基準になりえ無いし。

XP的には、CRCカードに金額を書いていくのが妥当なのかなあ?

33 :仕様書無しさん:03/11/12 18:56
顧客自体がXPに賛同して、部分予算、部分納品を認めるなら分かるが。
まずありえない。
SEの自分としては、極力「必要最小限から」を勧めはするものの、
最終的にはどの範囲で納品とするかは顧客の希望次第。
その範囲が決まったなら、その範囲内においては責任を持ってWFでやるしかない。
その範囲内の中身を、勝手にXPでやるのはSEの逃げだ。

34 :仕様書無しさん:03/11/12 18:59
>>33
補足すると、部分納品で部分的に売り掛けた後、
その後の開発の対応が悪くなったら、という危険を顧客は想定するわけだ。
だからここまでやったらはじめてお金を払う、という範囲を考えるわけだ。

35 :仕様書無しさん:03/11/12 19:03
まぁ、ウォーターフォールモデル開発の問題点は散々指摘されてるわけだが。
すぐ適用出来るような対案は中々無いんだよね。

36 :仕様書無しさん:03/11/12 20:48
XPを中途半端にしか知らない先輩がXPを押し付けてきて困る。俺も余り知らんけど。
今のプロジェクト(保守)はオブジェクト指向言語ですらないのに、
テストケースを作れとか、何故かUMLを書けとか。

37 :仕様書無しさん:03/11/12 21:41
やっぱウォーターフォールでしょ。
XPはできる人がやるの!おれのID・・・

38 :仕様書無しさん:03/11/12 22:59
ダメな奴は何使ってもだめ

39 :ウォーターフォールはあと20年消えない:03/11/12 23:20
http://www.mars.dti.ne.jp/~hirok/xp/col/013.html


40 :仕様書無しさん:03/11/12 23:56
漏れ的には、
お客が鈴木宗男だったり、相方が鈴木宗男だったりする場合は、
XPはやりたくない。
というか、漏れの隣に座ってる馬鹿が鈴木宗男的で、もう、鬱。

41 :仕様書無しさん:03/11/13 00:00
>>38
超ウォーターフォールならダメな奴でも
いっぱしの作業員として使える。

42 :仕様書無しさん:03/11/13 00:51
>>41
いっぱしはムリ。 熱心なバカほど始末に追えないものはない。

43 :仕様書無しさん:03/11/13 09:15
>>36
「デブは例外なく無能」スレに書こうかと思ったけど、うちには
「最近の方法論では8時間以上働いたらいけないことになってる。
俺達は働きすぎだ」とうるさい豚がいたな


44 :仕様書無しさん:03/11/13 09:17
>>40
「あのですね、私はですね、ちょっと言わせてもらいたい…」
が口癖とか?

45 :仕様書無しさん:03/11/13 10:02
まあ滝を軽やかに泳ぐ俺サマはXPも完璧にこなせるわけだが。

46 :仕様書無しさん:03/11/13 15:10
XPの見積もりってどうなってんの?
作りながら客に見せて詳細要望聞くんだよね。
先に見積もりってできるの?

47 :仕様書無しさん:03/11/13 15:35
>>46
私が思うに、受託形式では見積不能。

自社製品の作成か、派遣形式でしか、お金には替えられないと思う。


48 :仕様書無しさん:03/11/13 21:10
>>46
実績ベースで貰うしかないかなあ。
四半期毎に、XX人月かけましたから○○円ですって。

49 :仕様書無しさん:03/11/13 21:49
>>48
んー、それじゃ期限が無いのと同じじゃあ?
自分達はミスって時間が掛かっても、人月分の金は貰えるが、
客にしてみれば、時間は掛かるわ金は掛かるわでキレるだろう。

50 :仕様書無しさん:03/11/13 22:31
逆ウォータはしょっちゅうある。
最後に外部仕様作ったりとか。

51 :仕様書無しさん:03/11/13 22:41
>>50
そりゃー危険だね。外部だけは先に客先承認印もらわんと。
タチの悪いのに当たったらどこまでも吸い取られる。

52 :仕様書無しさん:03/11/14 00:08
>>50
それを整理体系化したのがXP(w
ソフトは完成しない!なんつって。

53 :仕様書無しさん:03/11/14 11:17
>>52
一理ある。
「ソフトに完成は無く、リリースがあるだけ」は大昔からの格言だったし。

54 :仕様書無しさん:03/11/15 11:01
>>49
>んー、それじゃ期限が無いのと同じじゃあ?
そう。発注、受注、納品って流れで考えると「期限が無い」ってのはありえない。
しかしながら、これは「納品物の定義」が発注側、受注側の双方が出来ないっていう
現実/前提で始まっている話なんだ。
何を完成とするか。あるいは、現状が完成状態になっているか否か。
を判断するのは、オンサイト顧客だろう。もしくはオンサイト顧客の上司かな。
>>53も参照してね。

55 :仕様書無しさん:03/11/15 13:22
おまいら・・・
まずは本でも読んでからにしろ。
何も知らなさ杉だ。

56 :オブジェクト指向促進運動:03/11/16 01:21
IT業界にアージャイル開発とデザインパターンを広めよう!

C言語を使ってかなり苦労したので
その苦労を最小限におさえるために
アージャイル開発、デザインパターンを
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

デザインパターンを使うこと、アージャイル開発することが
プログラマの習慣、常識になってほしい。

なんとか、デザインパターン文化、アージャイル開発文化を押し広げられたら・・・。

IT業界の将来はオブジェクト指向とアージャイル開発が握っています!

57 :仕様書無しさん:03/11/16 01:26
>>56
じゃあためしに、広まるように内容の紹介してよ。
「ここ嫁」はなしだよ。それじゃ広まらない。

58 :仕様書無しさん:03/11/16 01:36
>>54
ってことは結局、発注元が人月単位で丸抱えするってこと?
それじゃ話にならんわな。
双方に旨みがない。
発注側 : 予算の確定ができない。
      受注側の言い値になるから、サボっていても文句を言えない。
受注側 : 人月レベルの儲けしかない。

そもそもXPとは10名程度が限度のはず。
そんな小さなプロジェクトに対して方法論もクソもないと思うのだが。

59 :仕様書無しさん:03/11/16 03:25
red/green/refactor--the TDD mantra

60 :仕様書無しさん:03/11/16 09:54
>>54
>>58
二人とも本は読んでいるんだろうけど、PGだからビジネス側面は読み飛ばしたかな。
利用者(顧客?)の決定事項は、スコープ、プライオリティ、リリースの集約、リリースの日付
技術側(開発側?)の決定事項は、見積り、結果、プロセス、詳細なスケジュール
のそれぞれ四種だ。計画ゲームの項に書いてある。

61 :仕様書無しさん:03/11/16 10:16
>>60
つまり、XP想定するスコープのような短期での予算計画ができる
ごく小規模の組織でしか適用できないってことかな?
少なくともうちの会社じゃ、だいたい半年前に事業計画の承認を
もらわないと予算をとれないから、その時点までに費用と検収
時期が固まっていなければならない。

62 :仕様書無しさん:03/11/16 10:24
>>61
「半年前までに費用と検収時期が固まっていなければならない」というならば、
顧客側はスコープとプライオリティを調整(譲歩)しなければならないね。
当然だな。

63 :仕様書無しさん:03/11/16 10:28

 ハ ゲ シ ク ワ ラ タ

http://www.ne.jp/asahi/e/yamane/software/engineering/xp/daiary/xp_process2.html
# プログラマの見積りに対して、顧客は変更を要求してはいけないということです。
# ストーリーにかかる工数を見積もる権利はプログラマにあり、顧客にはありません。

# 工数を強引に縮めても、プログラマのモチベーションの減退を助長するだけであり、

これを顧客に説明するのか?
顧客はまだしも、意外にやっかいなのが自社の社長だ罠。
どうやって部下の超限界を引き出すかに命かけてるんだから。

64 :仕様書無しさん:03/11/16 10:38
>>63
説明するよ。
「工数見積りは担当者のものが一番精度が高い」
ってのは工学全般の大昔からの常識だもん。
>やっかいなのが自社の社長
転社したら?

65 :仕様書無しさん:03/11/16 11:08
>>64
説明するよと銘打ったわりには…
キミは、サービス残業取り締まりを強化するという共産党に入れた上でそれを言ってるのか?

66 :64:03/11/16 11:25
>>65
共産党には投票してないし、サービス残業なんぞしたことも無い。
俺は今はフリーだから、会社を辞めるって事に全然抵抗も無い。

67 :仕様書無しさん:03/11/16 15:57
>>66
じゃあ単に世情の分かってないアホってことか。

68 :64:03/11/16 16:32
>>67
そうかもね。
で、あんたは人をアホ呼ばわりする以外に何ができるんだ

69 :仕様書無しさん:03/11/16 16:38
>>68
「で、」って何だよ、「で、」って

70 :仕様書無しさん:03/11/16 18:43
結論としては、狼男を撃つ銀の弾丸は無いので、XPだろうが何だろうが
お前ら明日からもデスマですよってことで良いのかな?

71 :仕様書無しさん:03/11/16 20:55
>>70
おうよ!
銅だか鉛だか知らんがとりあえず撃ちまくるだけ!

72 :仕様書無しさん:03/11/16 21:02
>>70 いーわきゃねーだろ
XPは、適切に使えばデスマにはならないという実績を踏まえての手法/方法論だ。
「この適切が何か」が議論の焦点だが。

73 :仕様書無しさん:03/11/16 22:01
どんな方法論でも適切に使えばデスマーチにはならないけどな

74 :58:03/11/16 22:23
>>60
なんの解答にもなってないのですが。
引用するなら正しい場所を引用してください。
できれば自分の言葉でね。

もしかしたら、質問内容を理解できてないかもしれないので
喩えで書く。

物を作るという理由で、建を作ることを考えてみよう。
もし仮にあなたが家を建ててもらいたい立場の場合。

・いつまでに引越したいから、この期日までに作って
・3階建ての2世帯住宅を作りたい。
・間取りはだいたいこんな感じね。

っと、設計屋さんに出して回答が。
・見積もりは実際に作る人じゃないとわからない。
 大工は今から集めるから集めてから決めるから。
 費用はそれから。
・その間取りは大工さん集めてからじゃないとわからん。
・集めた大工さん分お金かかるから。
・とりあえず一部屋づつ作っていくから、出来上がったところから入って。

とか答えられた時点でブチ切れてその建築会社との契約を
二度と考えなくなるのでは?


75 :オブジェクト指向促進運動:03/11/16 22:39
>>70
んじゃ、お前は狼に食い殺されてくださいね

76 ::03/11/16 22:52
>>74
おまいさんの発言の元は>>46でいいんだよね?

おかしいと思った所だけ書くよ。

> ・見積もりは実際に作る人じゃないとわからない。
>  大工は今から集めるから集めてから決めるから。
>  費用はそれから。

XPには、日本式のPG/SEのような区別は無い。
見積もりの出来ない人が工数を決める事はあり得ない。
そもそも、プログラムの書けない人が工数を決める事がおかしいのでは?

> ・その間取りは大工さん集めてからじゃないとわからん。

よって、基本的にはその場にいる人が自分が書いたらどれくらいになるかで見積もる。
半年後に開発がより困難になる要因があるなら、
半年後を指定したのは顧客なので、要因の影響を最大限に考慮した工数を提示する。

> ・集めた大工さん分お金かかるから。

XPのどの部分を例えているのか理解できない。

> ・とりあえず一部屋づつ作っていくから、出来上がったところから入って。

この例えは間違ってはいない。
「一部屋ずつ」というよりは「出来た所から」だと思うけど。

漏れも建て替える家が途中まで出来てる所に入って家具の配置イメージとかしたし、
そんな感じだと思うんだけど、如何でしょう。


77 :仕様書無しさん:03/11/16 22:52
狼なら銀の弾丸は要らない、ふつうのフルメタルジャケットで充分だ

78 :仕様書無しさん:03/11/16 22:54
>>73
このスレッドにいる厨房にはそれが分からんのです。

79 :58:03/11/16 23:18
>>76

おかしいと思われた所が更におかしいと思ったところだけ書くよw

>よって、基本的にはその場にいる人が自分が書いたらどれくらいになるかで見積もる。

さて。ここで質問です。
一般のPGさんは仕事を抱えてる時に、別案件の見積もりをやれ!
っと言われたら忙しいから無理だと答える。
そもそもXPの考え方だと、これはダメなんでしょ。
ってことで、その会社で暇な人が見積もるってことでイイか?

その暇な人達が見積もった結果で、工数が合わないとブーブー
文句言うのは君達なのだが、これは矛盾してないか?

もしかして、PG達はプロジェクトが終わったら、他の仕事が
来るまで口開けてまってるって言う素晴らしい職場の話ですか?
今の時代、直ぐに潰れるな。そんなことしてたら。

>> ・集めた大工さん分お金かかるから。
>XPのどの部分を例えているのか理解できない。

>>63 に書いてあることの皮肉。
見積もりは常にプログラマにあるってところ。


まぁ、全体的に皮肉で書いてる。
64のようなフリーの立場でXPとか言ってる時点でワラえるんだけどね。


80 :仕様書無しさん:03/11/16 23:18
>>77
ところがどっこい、
XP否定論者でかつウォーターフォール信者は
フルメタルジャケットも装備できないのです。

彼らは愚かな旧日本陸軍のように、竹やりや刀だけで
アメリカ軍に勝てると思い込んでいた大馬鹿者と同じなのです。

81 :仕様書無しさん:03/11/16 23:19
まあウォーターフォールは死滅したわけだが

82 :仕様書無しさん:03/11/16 23:21
>>79
物事をゆがんだ方向に捉え考え方が偏って短絡的だね。


83 :仕様書無しさん:03/11/16 23:22
むしろXPこそ竹やりだと思うが。
ただしいXPユーザは戦う相手を選ぶ術は知っている。
>80みたいなソフトウェア工学の基礎も知らない奴は別として。

84 :仕様書無しさん:03/11/16 23:24
>>83
なんだただの釣りか。
釣りで無いとしたら
XPを竹やりレベルといっている奴がソフトウェア工学を
理解してるつもりになっていること自体笑える。


85 :仕様書無しさん:03/11/16 23:28
>>83
ウォータフォールが竹やりであることを認めたくないなら
もう引き返すことができない特攻隊とでも言ってやろうか?w


86 :64:03/11/16 23:33
>>79
俺は何処かに「XPを支持する」って書いたか?
XPを方法論を適用することになったら、
技術側として「顧客への説明は当然必要だ」と思ったからそう書いただけだ。

87 ::03/11/16 23:47
>>79
> ってことで、その会社で暇な人が見積もるってことでイイか?

よくない。

> 一般のPGさんは仕事を抱えてる時に、別案件の見積もりをやれ!
> っと言われたら忙しいから無理だと答える。

漏れはそう感じた事は無いが、想像するに、
なぜ無理だと答えるかというと、見積もりに対して時間を貰えないからだと思う。

> 今の時代、直ぐに潰れるな。

時間に対するマネジメントが適切に出来てない事こそ、危ない気がするが。

暇な人に見積もらせるとか、考えてる事が危険すぎるよ。
君が当たり前のようにそういう事をしているなら、
君に出来る事は、その偏見から一歩抜け出す努力をするか、この議論を忘れる事だ。


88 :仕様書無しさん:03/11/16 23:56
割り込み作業発生して、その分工数くれないというのは論外としても、
リカバリ時間を考慮に入れてないような会社、結構多いような気がする。
そんな所じゃXPだろうな何だろうが結局うまくいかないっしょ。
開発の方法論以前にやらなきゃならない事が山ほどあるよな、実際・・・

89 :79:03/11/17 00:04
>>87
さて。ここで問題です。
XP的考えの見積もりだとどっぷりと顧客要望を分析する必要があります。
見積もり精度、プロジェクトの大きさにもよりますが、1wぐらいの
工数が必要でしょう。
(梨がどの程度のプロジェクトやってるかしらんが、私の平均がこのぐらい)
さて。
見積もりから受注につながる可能性。
それはだいたい1〜3割ぐらいでしょう。
そのぐらい低いのです。
まぁ、一番高い3割の確率として。
1個の仕事を取るためには3.3個の見積もりをしなければなりません。
時間でいうと3.3Wです。
さて、これはあなたが言うところの
>見積もりに対して時間を貰えないからだと思う。
というレベルの話でしょうか?


別に私はXPを否定してるわけではありません。
顧客にメリットがなければ、絵にか書いた餅。
PGのオナニーだと言ってるのです。

90 :仕様書無しさん:03/11/17 00:05
>>88
どうい。CMMを持ちだすつもりはないけど、レベルの低すぎる開発組織が大杉。
「金と時間をかけるべきところ」が判断できない香具師が大杉

91 :仕様書無しさん:03/11/17 00:08
XPってそういう見積〜受注のやり方を推奨してる訳でわないと思う

92 ::03/11/17 00:23
>>89
XPの話じゃなくなってきてるぞ。
XPは見積もりに一週間も使わないので。

「見積もりにかかった時間は費用を請求できない」という問題は、
別にXPであろうがなかろうが起こる問題で、
それは「電話番を雇った費用は請求できない」という問題と同列だと思う。

なので、最終段落とその前の話がどう関連するのかわからん。


93 :79:03/11/17 00:23
>>91
世の中の商習慣に則った話をしましょう。
理想の世界の話をしてもしゃあないだろ。

94 :仕様書無しさん:03/11/17 00:42
>>76
> 漏れも建て替える家が途中まで出来てる所に入って家具の配置イメージとかしたし、

途中で見るのはいいけど、そこまでで一旦金払って、それからその先の要望言うわけ?
「じゃあこの下に地下室作って」とか(激藁

95 ::03/11/17 00:44
>>94
作れるなら作ってほしかったけど、XPじゃなかったから、無理だって言われたよ。w

96 :仕様書無しさん:03/11/17 00:48
>>93
> >>91
> 世の中の商習慣に則った話をしましょう。
> 理想の世界の話をしてもしゃあないだろ。
このスレはXPについて語るスレだ。XPとは直接関係無い
話をするのは勝手だが勝手に話す内容を制限し押し付ける
行為はやめてもらいたい。

オープンソースソフトウェア開発を見て欲しい。
全てのソフトウェア開発が古めかしい商慣習に沿っているとは
限らないことがよくわかるだろう。

97 :仕様書無しさん:03/11/17 01:12
>>96
あぁ。なるほど。
これは、理想境でのXPの適用のスレであって
実世界には関係ないってことだね。
そりゃ失礼。

結局結論として、一般のPGがかかわるような
実世界ではXPは意味ないものなんだ。
なんか時間損した気分だよ。

98 :仕様書無しさん:03/11/17 01:19
>>97
> >>96
> あぁ。なるほど。
> これは、理想境でのXPの適用のスレであって
> 実世界には関係ないってことだね。
お前はオープンソースが幻想だと抜かしている馬鹿か。
M$厨と同じように扱われ恥をかくぞ。

実世界に存在しオープンソースソフトウェアは高く評価され
どこでも使われているぞ。

オープンソースソフトウェアによるビジネスも理解できない
盲目馬鹿にはわからんだろうが。



99 :仕様書無しさん:03/11/17 03:54
オープンソース
http://www.geocities.co.jp/SiliconValley/5634/t82A8_0003.html#353

100 :仕様書無しさん:03/11/17 05:52
オープンソースソフトウェアのビジネスモデルの大きな勘違いは、
ソフトウェアを作って稼ぐことではないということだ。

オープンソースは使ってなんぼ。暇人が作ったのをパクって
ちょっと見栄えをよくして売りつける。
作った奴は大損。利用した奴の勝ち。

作って稼ぎたいのなら客寄せの餌に利用するしかない。
基本部分はタダですが、オプションは費用がかかります。ってね。

101 :仕様書無しさん:03/11/17 09:48
XPって個人の才覚に依存しすぎると思うんだがどうでしょうか?


102 :仕様書無しさん:03/11/17 10:17
>>100
ほう。ではIBMは大損をしているわけか。

103 ::03/11/17 10:42
オープンソースは関係ないでしょ。。

>>97
実世界(?)の話として開発方法論を比較検討するのは良いけど、
>>93の言う「世の中の商習慣」の話をしてもスレの主旨にあわない。

>>92にも書いたけど、開発方法論に関係ない悪習までXPが解決してくれるわけではない。
なので、その部分の判断をするために、
「ウォーターフォールでこの例を解くには」という話を併記しては如何か。

104 :仕様書無しさん:03/11/17 10:42
ソフトで儲からないから丸投げで大儲けしてるのだろ?

105 :仕様書無しさん:03/11/17 10:50
>>100はM$に逆らえない頭が固いウォータフォール信者の頑固ジジイ

106 :仕様書無しさん:03/11/17 10:51
馬鹿はXPは愚かオープンソースビジネスまで否定しているのでした。

107 :仕様書無しさん:03/11/17 11:09
>101
ある程度のレベルを要求される事は確かだけど、個人に依存とは言えないっしょ。
少なくともペアプロによって技術の伝播を推奨している訳だし。



108 :仕様書無しさん:03/11/17 11:32
>>107
ペアプロの欠点は、電波が2人組んで共鳴したときだと思うが。w


109 :仕様書無しさん:03/11/17 12:46
>>108
ペアの交代をしていれば、メンバーの大多数が電波でもない限り補正が効く。
メンバーの大多数が電波なら、ペアプログラミングでなくてもとんでもないことになる。
という訳で、別にペアプログラミング固有の欠点でもなんでもない。

110 :仕様書無しさん:03/11/17 12:55
似たような論議が前のXPスレでもあったな。
「新人を二人組ませても生産性が上がるとは思えない」って。
思えないっていうか、当然だろうと。

111 :仕様書無しさん:03/11/17 13:06
>>110 当然というか絶対というべきか。正論だな。

112 :仕様書無しさん:03/11/17 22:05
>>110
何ができるか楽しみではある。

113 :仕様書無しさん:03/11/17 22:35
>>110
どうせ独りでも生産性は上がらないw
XPってPGが無能者ではないという前提でしょ。

114 :仕様書無しさん:03/11/17 23:30
たかがライカンスロープ一匹に何をてこずっている?
さっさと頭部を消し飛ばせ。再生する前に焼却しろ。
塵は塵に。灰は灰に。それが化物共の唯一の末路だ。

115 :仕様書無しさん:03/11/18 00:01
>>114
お前も早くチリにカエレ。

116 :97:03/11/18 00:59
>>98
はぁ・・・
まさかオープンソースのことで私がこんなに言われるとは。
日頃の行いが悪いのでしょうか?:-)
あぁ。高く評価されてないからですな・・・


117 :仕様書無しさん:03/11/18 04:16
>>113
そしてSEが無能という前提。

118 :仕様書無しさん:03/11/18 09:14
Excise the bug. Before reproduction, Write test for it and refactoring it.

-- How to kill lycanthrope <Nevinyrral>

119 :仕様書無しさん:03/11/18 21:14
結論としては、狼男を撃つ銀の弾丸は無いので、XPだろうが何だろうが
お前ら明日からもデスマですよってことで良いのかな?

120 :仕様書無しさん:03/11/18 23:06

毎日がクリスマスでないのと同様、毎日がデスマということはない。

121 :仕様書無しさん:03/11/18 23:59
>>119
>>75

122 :仕様書無しさん:03/11/20 00:26
このスレで、XPマンセー っと言ってる香具師って
キーワードを並べるだけで実のあること言ってないよな。
まぁ、聞きかじったカッコよさそうな言葉を理解も
せずに書いてるってのがバレバレで微笑ましいのだが。

123 :仕様書無しさん:03/11/20 01:39
>>122
現場で遭遇するとウザくてしょうがない。

124 :仕様書無しさん:03/11/20 14:50
うぉーたーふぉーる信者よかはましですけどよ

125 :仕様書無しさん:03/11/20 15:55
>>124
あなたはどういう現場で、どういう立場の人で、
なぜウォーターフォールを嫌うのですか?

126 :仕様書無しさん:03/11/20 16:53
>>125
入社2〜3年目の現場経験の薄いベンダーのSEで
最近XPを齧ってしまった頭でっかち。


127 :仕様書無しさん:03/11/20 17:04
XPは残業禁止ですよ

128 :仕様書無しさん:03/11/20 17:21
>>127
そんなことないよ

129 :仕様書無しさん:03/11/20 18:37
XPは夢精禁止ですよ

130 :仕様書無しさん:03/11/21 00:56
なんでおまいらはウォーターフォールとXPを同列に語れるんだ?

131 :仕様書無しさん:03/11/21 02:37
滝の下流でやってるファーストプログラミングでは
中国にもはや勝てません(人月ですよ)

XPかなんかでスロープログラミングしましょうよ
スローがいいって客もいるはず

132 :仕様書無しさん:03/11/21 09:05
>>131
XPのどこがスローだ?
滝に流されるか、鳴門の渦潮に巻かれるかの違いだと思うけど。

むしろ個人にとってはXPのほうが、責務は多いぞ。


133 :仕様書無しさん:03/11/21 14:49
まあどんな方法論を採用してもカスには意味ないねー。
1にも2にも個人のスキルだろ。


134 :仕様書無しさん:03/11/22 03:11
まぁそうだな。

ただ極端な話、本当に優秀な開発者を集められたら確たる開発プロセスが
存在しなくても良いソフトはできるだろうけど、現実はそうではなくて、実際には
メンバーのスキルにはばらつきがある。そのような現実においてプロジェクトを
成功させるための方法論というものが、これらの開発プロセスなんだと思う。

また、開発プロセスは開発規模やチームの性格などの条件なしに一概にその
優劣を判断することはできない。
ウォーターフォールは、優秀な開発者は希少なのに対し凡百のプログラマは
一銭五厘で大量に調達できるという、業界の生態系に即した構造をとっており、
大規模プロジェクトに向く。対してXPは、能力のほぼ均質なメンバーからなる
直接コミュニケーション可能な規模のチームでの適用を想定している。

135 :仕様書無しさん:03/11/22 03:55
>>134
そうでもないよ。

136 :仕様書無しさん:03/11/22 10:33
>>135
解説キボン

137 :135:03/11/22 15:54
>>136
つっこみどころが多すぎて解説不能。

138 :仕様書無しさん:03/11/22 20:58
>>137
じゃあ、一個でもいいから自分の言葉で突っ込んでみそ。

139 :仕様書無しさん:03/11/22 21:51
>>138
なんのために?

140 :仕様書無しさん:03/11/22 21:55
>>139=135
ようするにあなたは「つっこみどころが多すぎて解説不能」
ではなくもともと解説不能ということですね。
もう少し勉強しないと一生コーダのままでつよ?

141 :仕様書無しさん:03/11/22 21:56
>>140
ヤレヤレ

142 :仕様書無しさん:03/11/22 22:42
141の負けだな

143 :仕様書無しさん:03/11/22 22:47
>>134
XPはそんな想定はしていないよ。

144 :仕様書無しさん:03/11/22 23:15
>>143
どういう想定か解説きぼぉ〜んw

145 :仕様書無しさん:03/11/22 23:17
>>143
だとすると、外注を何社も使うようなプロジェクトにも
XPは適用できるってこと?

146 :仕様書無しさん:03/11/22 23:17
>>144
本よめ、知障

147 :仕様書無しさん:03/11/22 23:18
>>145
ヤレヤレ

148 :仕様書無しさん:03/11/23 00:16
>>146
結局、解説できる人は一人もいないのですな。
コーダは所詮そのレベルでつな。

149 :134:03/11/23 00:24
俺様に文句を付けようなどとは百年早い

150 :仕様書無しさん:03/11/23 04:59
>>149
俺を何様だと思ってるんだ? 俺様だぞ!


151 :仕様書無しさん:03/11/23 10:57
お前らのいるようなヘタれな職場じゃ、XPだろうがWFだろうがうまく
いかねーだろ。結局デスマになるんだからなw

152 :仕様書無しさん:03/11/23 14:35
>>134
総論を支持する。

ただ開発プロセス(方法論)に優越はない。
>また、開発プロセスは開発規模やチームの性格などの条件なしに一概にその優劣を判断することはできない。
「開発規模」や「チームの性格」のみならず「商習慣」や「チームの属する組織文化」も無視出来ない。
「開発の性格/種類」ごとに最適な方法論(未提唱のものを含む)が存在する。

153 :仕様書無しさん:03/11/23 16:36
ウォータフォールは死滅!これからはRational Unified Processで決まり!


154 :152:03/11/23 19:04
>>153 おまえ、俺を煽っているな。

155 :仕様書無しさん:03/11/24 03:05
日本って、最初から開発の総予算が決まっている契約が多いので、
工程別に成果物を納品して支払いが行われる、ウォーターフォール
のようなスタイルがユーザーに受け入れられ易いんです。
>>134 の「商習慣」ですね。
また、仮に、「開発の性格/種類」ごとに最適な方法論として、
RUPのようなインクリメンタルな方法論を採用するとしても、
所謂、「拡張変更差分」に対しての追加請求でユーザーには嫌
な顔をされる事が多いですね。


156 :155:03/11/24 03:10
あ、「商習慣」は >>152 の発言でした。
スマソ。

157 :仕様書無しさん:03/11/24 04:26
>>153
RUP 重すぎ。


158 :仕様書無しさん:03/11/24 04:57
>>155
日本以外は
「最初から開発の総予算が決まっている契約」
が少ないのか?

妄想や無知を書いていて恥ずかしくないか?

159 :仕様書無しさん:03/11/24 05:04
XPで組んだとしても例えば、二人して徹夜して神が降りたコード書いて
バグ埋めこんだら結局デスマーチですよね。
結局何人に増えようが同じ事です。
そもそも塵芥戦術は不実雨の得意とする戦略なんで、真似したくないですよね。

160 :仕様書無しさん:03/11/24 07:43
>>159
> XPで組んだとしても例えば、二人して徹夜して

その時点で XP ではない。


161 :仕様書無しさん:03/11/24 09:43
いまのところ、XPが適用できるのって組み込み系、携帯の開発なんかだけだと思うけど。

大規模業務系の場合、全体はどうしても水落式でしかできない。
個別機能の実装では渦巻も部分適用できるけど。

162 :仕様書無しさん:03/11/24 10:27
>>161
すまん。
携帯のようなとんでもない規模で、仕様の統一性、
エラーケースの内容等、とんでもなく厳しいシステム
においてXPをどのように適用できるのか教えてくれ。
適用事例があるのか?
マジレス希望。

163 :仕様書無しさん:03/11/24 10:55
携帯電話のソフトウェアは通信周り以外はヌルすぎもいいとこだ。
アプリケーションの品質酷すぎる。ヘボチンどもがエセXPでやってるんじゃないのか。

通信周りも各キャリアでオラが村の独自企画でやりたい放題だけどな。

164 :仕様書無しさん:03/11/24 11:16
>>163
>通信周りも各キャリアでオラが村の独自企画でやりたい放題だけどな。
そんな風にやってもチャンと電話は通じて話しも出来るんだからすごいよね。

165 :仕様書無しさん:03/11/24 11:25
>>163
推測でここまで言い切れちゃうのが凄いでつね。
その推測が明後日の方向を向いて、それに対して
164のようなレスが付くところが、マ版らしいん
だけどね。

166 :仕様書無しさん:03/11/24 12:11
まず、携帯って本体側開発ってことでいいんだよね。
そうならば、とんでもない規模ではないだろ?
I/Fが明確でClosedなシステムなんだから、XPの適用ってしやすいと思うが。


167 :仕様書無しさん:03/11/24 12:31
>164
普通の発呼着呼、人間同士の話しは問題ないんだが、
新機種でディジタルPBXでのイベントの上がり方が急に変わったりするんだよ。参るよ。
キャリアごとに解釈自在の八方美人の規格つくるんじゃなくて真の統一をしてくれ〜

168 :仕様書無しさん:03/11/24 12:38
>165
もしかして「マばん」って読んでる??

>165
「端末側」って言いたいんだろうけど・・・
プロトコルからメーラ、ブラウザ、最近だとJVMまである訳だが。

>167
悪いのはAvaya等の交換機メーカーも同罪。



169 :164:03/11/24 13:17
>>167
シロートなんでよくわからんけど交換機の中のソフト屋さん?
かかって来た電話の振り分け(って言うんだろうか?)ってソフトでやってんの?
漏れはハードウェアが勝手にやってくれるもんだと思ってタよ。
何だか知らなんが大変そうだ。

170 :仕様書無しさん:03/11/24 14:58
>>169
本体なら上で出てるように業務系より小規模だけど、
センターのデータベースはとてつもないよ。
かつて不治痛がNTTのデータベース1兆円で請けて失敗し、
さらに1兆円で丸投げしたそうな。

171 :仕様書無しさん:03/11/24 15:45
>>168
「マばん」と読んでいったい何の問題があるというのだろう、この馬鹿は。

172 :仕様書無しさん:03/11/24 18:19
1兆円・・・・まぁ、漏れらのごめんなさいとはレベルが違うということで(ry
不治痛もみかかもいきなり今みたいな巨大企業になった訳じゃないし、とりあず、
最初はXPとかでちまちまやってて、その内の1つが大きく育てばいいではないか。
とまとめてみた。オヤヂくせー

173 :仕様書無しさん:03/11/24 18:28
>>170
そんな事実は無い。

174 :仕様書無しさん:03/11/24 18:42
>>173は不治痛の社員

175 :仕様書無しさん:03/11/24 21:23
>>171
最近の世界情勢や世界経済をかんがみるという立場からは、諸般の問題があるのでしょう。


176 :仕様書無しさん:03/11/24 21:28
じゃあ、DoCoMoのCORBA基盤についてでも語ろうか。

177 :仕様書無しさん:03/11/24 21:28
>165は相手がプロと見て逃げ出したのだろうか

178 :仕様書無しさん:03/11/24 21:29
>>175
板と版の単なる誤字から、そんなレスをつけられるとは。ただものではないな。

179 :仕様書無しさん:03/11/24 21:35
にちゃんねらなら「いた」だろ「いた」!!

180 :仕様書無しさん:03/11/24 21:46
ババンガバンバンバン
あ〜それそれ!

181 :仕様書無しさん:03/11/24 21:48
>>177
165??
相手を間違えてませんか?

182 :仕様書無しさん:03/11/24 21:50
  マ  ぼ  ー  ど
 programmer board と読んでいます。




 い け ま せ ん か ?

183 :仕様書無しさん:03/11/24 22:27
>>182
久美、そんなこといけないと思う。


184 :仕様書無しさん:03/11/24 22:34
>>183
そんなこといわれましても、マboardはマboardですし。
シュバルツゲルト星団の方はそう仰っていますし、と、時々電波を装ってみたりもするわけで、
マboardということになっていたほうが諸々の諸事情を鑑みますと
色々都合がよろしいのではないかと思う次第です。はい。

185 :仕様書無しさん:03/11/24 22:49
>>184
しかしアルファ宇宙域ではマ板(まばん)という呼称がすでに定着しつつ
ありますし、カーデシア星系の評議会の結論待ちということで。


186 :仕様書無しさん:03/11/24 23:54
ロミュラン帝国ではどうなんですか?


187 :仕様書無しさん:03/11/25 00:01
ロミュラン帝国では"まきはん"(マ木反)と読んでいます。

188 :仕様書無しさん:03/11/25 04:43
ようするに、お前らデスマの最中にXPがどうとか夢みたいなこと言ってないで
目の前の仕事を片付けろってこった。
しょせんXPなんて顧客と上司が納得するわきゃないんだしよ。

 XPもアジャイルもRUPも死滅!これからもこの先もWFで決まり!

189 :仕様書無しさん:03/11/25 06:45
デスマなんかしていませんが何か?

190 :仕様書無しさん:03/11/25 06:53
毎日遅く出勤して帰りは定時ですが何か?

191 :仕様書無しさん:03/11/25 07:05
>>190
それはそれで問題が...。
会社傾いてない?

192 :仕様書無しさん:03/11/25 07:49
という脳内妄想なわけですが何か?

193 :仕様書無しさん:03/11/25 10:42
>>192
プ 能無しの脳内ですかw

194 :仕様書無しさん:03/11/25 20:29
お前ら奴隷は、文句を言わずに働くのが仕事やろ?

195 :仕様書無しさん:03/11/26 01:44
>>187
武器の密売はよくないとおもう。


196 :仕様書無しさん:03/11/26 01:52
WFでうまくいってりゃ新しい方法論なぞ出てこないだろうよ。
しかしWFしか知らん人間を説得するのは至難だ。
世代交代が起こるだけの時間がかかるかもシレンな。

197 :仕様書無しさん:03/11/26 06:25
計画性のない計画と、無計画ではどっちもどっちだな。
所詮は計画性のある計画をするしかない。

198 :仕様書無しさん:03/11/26 08:44
計画を立てて実現できなければ、
それは無計画だったようなものさ。

否。尚悪い。計画は立てた。実現者が無能だった。
そういう言い訳が許されるってんなら、

寧ろ最悪。寧ろ罪悪。

全くの無計画のほうがどれほどマシか。

199 :仕様書無しさん:03/11/26 11:07
客が納得しなければXPに持っていけない。
だから初回はなるべく無理のないWFですっきり納品し、
以降のカスタマイズを月々のサポート契約という形で、
今度は思い付きに順次対応できますと言うとすんなり通る。
初回の納品で信用されてるし、当初予定の業務は回ってるし、
WFの打合せ過程で客も疲れきってるから。

200 :仕様書無しさん:03/11/26 12:00
つまり、まずはWF開発によるデスマで顧客&PMの思考能力を奪い、その隙に自分好みのオサレな開発手法をねじ込むという戦略でつね。

自分達が生きてればの話だが・・・

201 :仕様書無しさん:03/11/26 17:11
WFだろうがXPだろうが
PGは救われないよ

202 :仕様書無しさん:03/11/26 19:47
この業界だけだぜ?
こんなぐらだないことで議論できるのって。
そうでもないか・・

203 :仕様書無しさん:03/11/26 21:35
例えば建築業界と違って成果が目に見えないからな。


204 :仕様書無しさん:03/11/26 21:41
お前ら奴隷は、文句を言わずに働くのが仕事やろ?

205 :仕様書無しさん:03/11/26 23:06
えっくすぴ〜〜〜〜〜〜〜えっくすぴ〜〜〜〜〜〜〜
ヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノ
ヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノ
ヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノ
ヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノヾ(@゜▽゜@)ノ


206 :仕様書無しさん:03/11/26 23:35
WF…仕様変更で大戻りする孤独なデスマ
XP…仕様を小出しにされてペアでもめながらデスマ

207 :仕様書無しさん:03/11/26 23:39
WF…たまにデスマ
XP…常にデスマ

208 :仕様書無しさん:03/11/26 23:42
WF…よくあるデスマ
XP…まだ未経験のデスマ


209 :仕様書無しさん:03/11/27 00:29
WF…デスマになるのがプロジェクト中にわかる
XP…デスマになるのがプロジェクト開始前からわかる

210 :仕様書無しさん:03/11/27 00:29
結局デスマかよ

211 :仕様書無しさん:03/11/27 00:32
WF…見事なデスマ
XP…悲惨なデスマ

212 :仕様書無しさん:03/11/27 00:48
WF…伝統的なデスマ
XP…先進的なデスマ

213 :仕様書無しさん:03/11/27 00:54
WF…赤い糸のデスマ
XP…出会い系のデスマ

214 :仕様書無しさん:03/11/27 03:41
結局デスマ。
何気に真理

215 :仕様書無しさん:03/11/27 10:10
判ってないな、行進の行き先が一方向か循環か、それだけの違いだ。


216 :仕様書無しさん:03/11/27 11:52
ウォータフォールは死滅!これからはRational Unified Processで決まり!

217 :仕様書無しさん:03/11/27 11:56
まあ、温故知新って言葉を知らない奴はどっちにしてもだめだね。
あらゆる手法をきちんと知った上で、自分なりに消化して使う。
どれがだめとか言ってるうちは、単に道具として使っているだけ。

218 :仕様書無しさん:03/11/27 12:06
あらゆる手法をきちんと知った上でデスマ

219 :仕様書無しさん:03/11/27 12:09
デザインパターンぐらいアタマいれとけよ! オメーら!

220 :仕様書無しさん:03/11/27 12:09
がむしゃらにコード組んでんじゃねぇよ!

221 :仕様書無しさん:03/11/27 12:15
>>217
されど温故知新に固執しすぎるのも発展性が望めず

222 :仕様書無しさん:03/11/27 12:24
温故知糞

223 :仕様書無しさん:03/11/27 13:10
>>221
知新の部分は?
温故知新って言葉の意味をきちんと理解してるか?

XPだって、昔のいろんな手法があってこそ生まれたもの。
その昔を知らずに新しい奴の表面だけ見て、万歳しちゃうような奴では、何処まで言っても死の行軍。


224 :仕様書無しさん:03/11/27 13:40
見積の部分はともかくとして、それ以外のプラクティスってそう目新しい物でもないと思う。
ウォーターフォールだろうがなんだろうが、まともなプロジェクトならそれに近い方法を取っていた。
XPって、それらをまとめて体系化しただけじゃ?デザパタと同じで。

225 :仕様書無しさん:03/11/27 13:49
>>224
そういうことを言う人に限って、まとめて体系立てが出来ないんだよね。w
あんなの簡単だよとかって後だしでいっちゃうのって結構恥ずかしい。
こういうことはある意味やったもん勝ち。


226 :仕様書無しさん:03/11/27 16:14
別に体系立ては誰でも出来るなどと言いたい訳ではなかったのだが・・・
誤解を招く書き方だったかな。スマソ。
私が言いたいのは、XPを見て「全く新しい開発手法」という印象を持つようなプロジェクトには、
XPを導入してもより混乱を増大させるだけじゃないか、と。

227 :仕様書無しさん:03/11/27 17:51
>>255
えっ!? やって、勝ったの?

228 :仕様書無しさん:03/11/27 17:56
>>25
うちは、激しく狭いので風呂の脱衣場はカーテンのみ。
こないだスッポンポンになってたら、いきなり父親にカーテン開けられました。
16歳にもなって、父親に全裸見られました。凄く恥ずかしかったです。
父は心臓が悪いのですが、娘の裸を見たショックで軽い発作を起こしやがりました。
だ〜か〜ら〜普段から、誰も居ないか開ける前に気をつけろと言ってんのになぁ…。
http://www.dfnt.net/t/photo/column/kabuto.shtml


229 :仕様書無しさん:03/11/27 18:15
どう考えてもおかしい。
WFの方が、XPの目指さんとする仕様修正をもっと高速にできる。
なにしろ実装しないで紙の上で次々にソフトを修正して見せるんだから。
そして全部紙の上で修正し終わってから実装した方が、
実装も総合的に捉えて計画的にできる。
いわゆるITバブル系の詐欺事件とみた。

230 :仕様書無しさん:03/11/27 18:51
実父ならまだいいじゃないか
私は義父に見られたぞ。
お風呂あがろうとドア開けたら、義父がちょうど洗面所に入ってきた。
義母に激しく叱られてたけど

231 :仕様書無しさん:03/11/27 19:10
>>229
あなたにとっては、机上の空論のほうが現実なんですね。
処置無しです。

232 :仕様書無しさん:03/11/27 19:41
>>229
そんなあなたにはRational Unified Processがお勧めです(w

233 :仕様書無しさん:03/11/27 22:09
WFの場合:
 仕様がなかなか決まらず、最終的にはっきりしたのが納期の
1週間前。結局デスマーチに。

XPの場合:
 クライアントの要求が迷走。次から次へと180度変わる要求
にプロジェクトも迷走。結局デスマーチに。

234 :仕様書無しさん:03/11/27 22:15
>>233
> XPの場合:
> クライアントの要求が迷走。次から次へと180度変わる要求
> にプロジェクトも迷走。結局デスマーチに。

それはいいんだよ。XP とはそういうものだ。ハンドルを握っている人の
思い通りの方向に走る。


235 :仕様書無しさん:03/11/27 22:30
WF は客の要求が変わらないのが前提。
XP は客の要求が変わるのが前提。
チームは 180 度でも 270 度でもまるっとすりっとごりっとアジャイルに方向転換できる。
どこで終えるかもクライアントが決める。


236 :仕様書無しさん:03/11/28 00:13
>>228
ひょっとしてここ数日、誤爆しまくってる?
ツール変えた?

237 :仕様書無しさん:03/11/28 00:40
>>233
印刷業界じゃないんだから。w
仕様が決まってから再見積もりでしょ?普通。うちはそうだけど。
あまり大きく暫定見積もりから外れる場合はそれ以上増やさないように言うし。
金額上げても増やしたいなら応じるし。それだけの話。
規模にもよるだろうけどそれまでに数ヶ月かけて納得してもらってるわけだから。
実装に入ってからさらに数ヶ月あったとしても、その間はゼロ秒のできごととして考えてくれと、
まして2週を切ったらたとえ数分で終わる作業でも変更を入れると危険だと始めから説明してる。

238 :仕様書無しさん:03/11/28 00:45
>>235
騙されてるよ。
WFは紙の上でいくらでも要求変えていいんだよ。
要求の変化のたびにコーディングして見せ、コーディングし直すのと、
要求の変化のたびに資料を作って見せ、資料を作り直すのと、
どっちが早いかといったら圧倒的に後者だよ。

239 :仕様書無しさん:03/11/28 01:03
>>238
資料納品だけで良いならWFでOK。コード書き始めた瞬間に、客が黙り込むならWFでOK。
だが決してそんなことはありえない。
客が最終的に要求しているものはプログラム(を実行することにより発生する効果)だ。

240 :仕様書無しさん:03/11/28 01:07
WFとXPを比較していると戦略と戦術を比較しているような感じがする

241 :仕様書無しさん:03/11/28 01:12
>>240
どっちも戦術じゃん。


242 :仕様書無しさん:03/11/28 01:14
うちは、激しく狭いので風呂の脱衣場はカーテンのみ。
こないだスッポンポンになってたら、いきなり父親にカーテン開けられました。
35歳にもなって、父親に全裸見られました。凄く恥ずかしかったです。
父は心臓が悪いのですが、娘の裸を見たショックで軽い発作を起こしやがりました。
だ〜か〜ら〜普段から、誰も居ないか開ける前に気をつけろと言ってんのになぁ…。
http://www.dfnt.net/t/photo/column/kabuto.shtml

243 :仕様書無しさん:03/11/28 01:29
>>241
そう?
長い期間で見たらWFだけど短い期間で見ると開発の現場ではXPですすめてる、とか。

244 :仕様書無しさん:03/11/28 03:17
>>243
逆じゃないか?「今回はこの範囲にして、これは次期バージョンに回しましょう」
で、今期バージョンの中に関してはWF。長期がXP的で、短期がWF。
その短期が1〜2週間というふざけたものがXP。
その短期を数ヶ月という期間にするとWFと言われるものになる。

245 :仕様書無しさん:03/11/28 10:53
>>244
逆でもその逆でもない。
つーかネタか?

246 :仕様書無しさん:03/11/29 02:26
そんな事はどうでもいいからとにかくコード書け!!

247 :仕様書無しさん:03/11/30 00:16
何か最近アジャイルとかXPに関する本が多いな。
中身は見てないが、本当に精通した人が書いたのか疑わしい目で見てしまう。

248 :仕様書無しさん:03/12/02 02:07
× アジャイル
○ アジル

249 :仕様書無しさん:03/12/02 09:12
>>248
× アジャイル
× アジル
○ アジャ


250 :仕様書無しさん:03/12/02 22:37
XPにしろAgileにしろ、日本語の響きとしてはいまいちだ・・・



251 :仕様書無しさん:03/12/04 01:13
>>248
×アジル
○あぁ〜ん汁

252 :仕様書無しさん:03/12/04 01:44
…。

この板さ、いつもCOBOL叩きが起こると発狂する奴が出てくるところとかから考えて、
かなりオヤジ率高いよな。40歳くらいの結構いるだろ?

253 :仕様書無しさん:03/12/06 22:10
武富士よりひどいという噂の会社
http://www.b-times.jp/backnumbers/20031027.html
http://www.b-times.jp/backnumbers/20031103.html#2
タイムカード改ざんでおなじみのあの会社がまた新聞の1面を飾った。
・これが過労死疑惑の実態か!?…日本ロジテム(みずほの融資先)
 〜子会社社員の勤務報告書を全面公開!!
 〜それでも疑惑否定する幹部と子会社セイモスの辻範夫社長!!
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
http://tmp2.2ch.net/test/read.cgi/company/1065447680/l50

254 :仕様書無しさん:03/12/06 22:38
× アジャイル
○ アルジャジーラ


255 :仕様書無しさん:03/12/06 22:41
アジャイルなんてダメなプロマネの言い訳に使われるだけだろ。
ビジネスは契約をともなって遂行されるものだし
たいていはいくつかの会社が関係するからウォーターフォールで進めるのが一番でしょ。
アジャイルだのXPだの言ってるやつは日曜日に家で友達とプログラミングしててね。

256 :仕様書無しさん:03/12/06 22:42
以上。ダメな奴のいいわけでした。

257 :仕様書無しさん:03/12/07 19:32
XPって何?

258 :仕様書無しさん:03/12/07 20:27
>>257 キシリトール配合のガムのことだろ

259 :仕様書無しさん:03/12/07 20:46
アージャイル開発もできない愚か者には死を!
http://pc.2ch.net/test/read.cgi/prog/1070781553/

260 :仕様書無しさん:03/12/08 01:34
>いくつかの会社が関係するからウォーターフォールで進めるのが一番
>いくつかの会社が関係するからウォーターフォールで進めるのが一番
>いくつかの会社が関係するからウォーターフォールで進めるのが一番

261 :仕様書無しさん:03/12/08 07:27
>>255
> ビジネスは契約をともなって遂行されるものだし

XP ってもろそうじゃん。


262 :仕様書無しさん:03/12/08 12:40
オブジェクト指向でいうクラスとはプログラマ間の契約を定義するためにあるのだが。


263 :仕様書無しさん:03/12/08 14:05
>>262
261 への返事?
XP は顧客が次のイテレーションを決めるから、契約を伴わずにどんどん進んでいくことはない。


264 :仕様書無しさん:03/12/08 14:11
オブジェクト指向とは契約を定義するためにある。
契約なくしてオブジェクト指向は語れない。

つまり独りよがりでこーでイングしている香具師がオブジェクト指向を否定する。
そしてXPやRUPをも否定する時代遅れな厨房ジジイなのだ

265 :仕様書無しさん:03/12/08 14:14
>>264って如何にも読み齧り、誰かの受け売りだよな。
ぜっっっっっったい自分では実務をやったことの無い、メーカーの新卒SE。


266 :仕様書無しさん:03/12/08 14:25
>>264
ここでいう契約とは、顧客と開発者との契約のこと。
それに、XP は必ずオブジェクト指向でやるものとあなたは誤解している。

267 :仕様書無しさん:03/12/08 14:26
>>264
顧客が次のイテレーションのクラス設計をするわけではない。ストーリーとタスクを
開発者とともに決めるだけ。それが契約。



268 :仕様書無しさん:03/12/08 14:31
実際さ、とりあえずXPって自社開発にしか適用できないよ。
自社主導で社員か契約社員なら普通にできる。

受託形式だと、発注側が望まない限りは、受注側からは難しいだろ?
顧客の手間、コストが増えるんだから。


269 :仕様書無しさん:03/12/08 14:35
>>268
そんな顧客は切って捨てればいい。
理解あるお客だけと仕事をすればいい。


270 :仕様書無しさん:03/12/08 14:47
おまいらオブジェクト指向のことを勉強したとき「契約」という言葉をマジで聞いたことがないのか?

顧客との対応のときだけ契約かよ

271 :仕様書無しさん:03/12/08 14:48
>>270
バカだなあ。ここでは契約による設計の話をしているんじゃなくて、
顧客との契約の話をしているんだよ。
それに、契約による設計は構造化プログラミングでもやんなきゃだめでし。


272 :仕様書無しさん:03/12/08 14:48
>>270

>>255 はビジネス上の契約のことを言っている。国語力を身につけよ。


273 :仕様書無しさん:03/12/08 14:49
s/>>255/>>261/ スマソ


274 :仕様書無しさん:03/12/08 14:50
XP では契約による設計は、テスト・ファーストによるユニット・テストで保証している。

275 :仕様書無しさん:03/12/08 14:50
>>269
その種の発注能力がある客はそんなに多くないと思うけど

276 :仕様書無しさん:03/12/08 14:51
>>275
勘を信じるな。君が見るべきものはデータだけだ。


277 :仕様書無しさん:03/12/08 15:28
あ、つまりビジネスロジック上での契約の話か。そうかそうか。

278 :仕様書無しさん:03/12/08 15:29
>269 そんな顧客は切って捨てればいい。

こいつはナニモノだ?

279 :仕様書無しさん:03/12/08 15:30
ワイアドロジック

280 :仕様書無しさん:03/12/08 16:13
>>278
269の言うとおり、付き合いたくない顧客とは仕事はしない方がいいよ。



281 :仕様書無しさん:03/12/08 16:55
でも営業部長が許可してくれない

282 :仕様書無しさん:03/12/08 16:57
XP適用を言ってる割には根性がねーよな。
客を教育するぐらいの勢いみせろよ。逃げるだけの負け犬。


283 :仕様書無しさん:03/12/08 17:13
>>282
無料で教育しろと?
商習慣を変えるってのは関係各位の全員の理解と納得と承認が必要だなあ。
and条件だから誰か一人の理解と納得と承認が得られないと失敗するって事だよなあ。
誰かの教育に失敗したら全く売上につながらないことをやったということになる罠

ということは最初に教育すべきなのは自社の経営トップだという結論か。

284 :仕様書無しさん:03/12/08 17:19
>>283
無料で云々というのは、それを言ったら営業活動が成り立たなくなるよ。
2行目からはいいたいことはわかる。

だが、>>280みたいのばかりが社員だと、縮小していくパイを喰い尽すだけ。


285 :仕様書無しさん:03/12/08 18:12
客はね、手法はXPでやりたいの。XPの方が打合せ楽だから。
触ってから思いつきで文句言えばいいんだから。頭使わなくていいの。
でも支払いはWFで固定したいの。そのためにWFの難解な打合せに付き合うの。

286 :仕様書無しさん:03/12/08 18:14
ほとんど教育もしない、ほとんど説明もしない、それで分かってくれる
お客とだけ取引してればいいんだよ。
無理して変な客と付き合うとビジネスがおかしくなるし、経営上の
負担も増える。


287 :仕様書無しさん:03/12/08 18:24
なんつうか、引きこもりの論理だな。w
自分を理解してくれる人としか付き合えない。


288 :仕様書無しさん:03/12/08 18:28
>>287
商売の下手な人が、お客様を神様に祭り上げて、誰とでも取引しないと
儲からないからだね。


289 :仕様書無しさん:03/12/08 18:29
うんうん。嫌な客でも呼ばれれば尻尾を振って飛んでいく業者。よくいるよね。
それで儲かっているかといえばそうでもない。


290 :仕様書無しさん:03/12/08 18:31
嫌な客、やだよ。くたびれるだけ。
同じ儲けるなら優良顧客の仕事しか受けない。


291 :仕様書無しさん:03/12/08 18:35
なんつうか、図星だった?必死だな。


292 :仕様書無しさん:03/12/08 18:38
優良顧客と不良顧客ができてしまうのは、SEが無能なんだ罠。
客側にもSEに相当する人間がいないとできないようでは、下請けしかできん罠。

293 :仕様書無しさん:03/12/08 18:38
お客を切れば切るほど儲かるのは確かだ。


294 :仕様書無しさん:03/12/08 18:42
>>292
違うね。
値段だけにこだわる、社員に無礼、細かい苦情が多い、ルールを守らない、
すぐにキャンセルする、説教を長時間する、生理的に嫌い。
こんなお客は、相手がどんな会社であろうと一定数はいるもの。そういうのを
切る。


295 :仕様書無しさん:03/12/08 18:45
>>294
そんなのに構っていると経営資源のムダだな。


296 :仕様書無しさん:03/12/08 18:47
>>287
商売なんだから、ひきこもりだろうとなんだろうと、儲からなくちゃ意味がない。


297 :仕様書無しさん:03/12/08 18:49
>>296
まあ、あんたがそういうんならそうでいいんじゃないの?
その主張が何処でも通じるか疑問だけどね。

298 :仕様書無しさん:03/12/08 18:57
>>294
その場合切るっつーか、見積が合わず普通にお流れになるだけでは?

話の流れからすると、「XPを理解し得る客かどうか」ということでは?

299 :仕様書無しさん:03/12/08 19:26
要は
「この先もずっとウォーターフォールでいい人手ぇ挙げて!!」
って事だろ?

300 :仕様書無しさん:03/12/08 20:18
>>299
それって核心を突いてる。
変化を抱擁せよ

301 :仕様書無しさん:03/12/08 20:28
変化ってw
Windowsのように変わりまくるのがいいとでも思っているのかw

302 :仕様書無しさん:03/12/08 20:30
>>294
おいお前。これは「ルールを守らない」以外はいけいれても良いだろ。
その顧客がそれなりに金をだしてくれるならな。

まあお前みたいな奴は宇宙飛行士にも軍人はおろか営業にもSEにもなれないな。


むかつく奴といかにつきあっていくか、むかつく奴をどうやってむかつかない奴にかえていくか、
あるいは導いていくか、うまく利用していくかが勝利の秘訣なんだよ。
むかつくやつでも大金をもってきてくれたら受け入れてやれ。

303 :仕様書無しさん:03/12/08 20:32
>>301
Windowsや.net, Win32 APIなどは逆に変化を擁護するものではなく変化を否定している。
なぜならオブジェクト指向を無視したAPIが多く、拡張性が低く変化に耐えにくいAPIが多いからだ。

304 :仕様書無しさん:03/12/08 20:33
>>301
>>2の先のサイトをよく見よ。
その標語がすぐに目に入る。

305 :仕様書無しさん:03/12/08 20:35
XPでいう「変化ヲ擁護セヨ」とはWindowsのような変化ではなく。
「簡単に変化させやすものヲ擁護セヨ」に近い。
すなわち「オブジェクト指向ヲ擁護セヨ」だ。



306 :仕様書無しさん:03/12/08 20:37
> なぜならオブジェクト指向を無視したAPIが多く、拡張性が低く変化に耐えにくいAPIが多いからだ。
具体的な例を身って見ろよw

307 :仕様書無しさん:03/12/08 20:48
実際に使って見れ。Javaには適わない。

308 :仕様書無しさん:03/12/08 20:53
なんだ。やっぱり具体例を出せないのか。

309 :仕様書無しさん:03/12/08 20:54
>>302
そんな暇があったら、いいお客の仕事をどんどん成約させなきゃ。時間がもったいない。
嫌な客には社内リソースは一切使わせない。
買う気のない客には見積もりも取らせない。


310 :仕様書無しさん:03/12/08 21:00
>>309
交渉能力にたけていりゃそんなことイワネ。

たとえば、やくざが1000万の車を買いたいといった。
それをお前は断るのか?


やくざといえど犯罪者とは限らない。


311 :仕様書無しさん:03/12/08 21:01
>>308
とりあえずファイルI/O関係とでもいっておこう
あとは自分で調べろ。教えて厨房君(w

312 :仕様書無しさん:03/12/08 21:05
>>310
あとで関係が問題になるようなお客は断るね。
関わらない方がいい。


313 :仕様書無しさん:03/12/08 21:06
てかさ、金に目がくらんで契約しちゃうようじゃ危ないよ。
いつでも、目の前にある取引を断ってもいい経営状態にしておかないと。
そうじゃない会社が、変な仕事を引き受けてきてデスマになる。


314 :仕様書無しさん:03/12/08 21:11
http://japan.pinkserver.com/mariko/2.html

315 :仕様書無しさん:03/12/08 21:17
>>313
おいおい、武富士みたいなのと一緒にするなよ

316 :仕様書無しさん:03/12/08 21:17
>>314
このスレに糞リンクを張るなこの餓鬼!

317 :仕様書無しさん:03/12/08 21:30
>>313
お前よ、餓鬼のころ喧嘩したことないだろ。
喧嘩やいじめなどでありとあらゆる恐怖を味わってこそ大人になれるもんだぞ。
今まで、嫌な奴と仲が悪くなって酷い目にあった、あるいは会いそうなとき、
面倒くさがり屋や忙しい奴はかかわらないほうがそりゃあ一時的に楽できるわい。
だがな嫌な奴と散々な嫌悪な関係になっても後になぜか一緒に飯を食いに行ったりしているものだぞ。

餓鬼の頃喧嘩したことがない、殴られた経験が一度もないホモみたい奴は度胸がなく
ちょっとしたことで怒鳴られたくらいで拒絶反応を示して
優良顧客を逃がすこともあるものだ。

まるでエイズ患者が触ったものを触れそうになっただけでビビる勘違い君みたいにな(w


318 :仕様書無しさん:03/12/08 21:32
>>294に示されるようなどんなに嫌な客でもルールをしっかり守り法律も倫理もマナーを守る奴なら
仕事は引き受けろ。

319 :仕様書無しさん:03/12/08 21:33
まあ、それでも優先順位は自分でつけてもいいが。

320 :仕様書無しさん:03/12/08 21:34
プログラマってのは臆病者がそんなに多いものなのかと

321 :仕様書無しさん:03/12/08 21:53
>>317
おまえの言っていることは科学的根拠は無い。

322 :仕様書無しさん:03/12/08 22:03
>>321
科学的根拠の無い言い訳をするな


323 :仕様書無しさん:03/12/08 22:11
>>322
科学的根拠がないことを指摘されて逆切れかw

324 :仕様書無しさん:03/12/08 22:33
>>317
ビジネスとは嫌なやつと仲良くなることではない。そんなことしている間に
市場の波は消えている。
マゾなやつは好きにすればいいが、文句を言わず、理解があり、手離れのいい客と
どんどん成約すればいい。金をたくさん儲けることだ。


325 :仕様書無しさん:03/12/08 22:43
>>324
とりあえず、暗い夜道には気をつけとけよ。

326 :仕様書無しさん:03/12/08 22:45
>>324
余計な手間を取らせる客を相手にしている暇があったら、
扱いやすい客だけに絞れということですね。
いまは、市場のライフサイクルが数年で終わってしまいますからね。
仲良くなった頃には使い道がないと。

戦艦大和を一生懸命造っている間に、戦艦の時代から航空母艦の時代になり、
造り終わって発進した時には、もうアジャイルな戦闘機の時代になっていた。
大和は身軽ですばやい戦闘機にやられて沈められた。

そういう無駄はやめろということですね。


327 :仕様書無しさん:03/12/08 22:47
>>325
バカだなあ。いちいち些細なことに文句を言ってくる客や、分けなく怒りまくる
手離れの悪い客に、無理に仕事を「させてもらっている」方が、夜道に気をつけなくちゃならない。


328 :仕様書無しさん:03/12/08 22:49
>>327
文句言ってくれる人がいなくなると、進歩が無くなるんだよ。

329 :仕様書無しさん:03/12/08 22:53
>>328
そういうのはいるね。「クレイジー5%」と言う。
クレイジー5%の言うことは、たいてい至極もっともなことだからありがたく参考にはするが、
客としては切り捨てる。


330 :仕様書無しさん:03/12/08 22:55
お前らホモ。
平和ボケしすぎてホモになっているんだよ。お前らは自己防衛能力が低下しすぎて甘えすぎなんだよ。
今だに日本の治安は世界一を信じているのか(ワラ

いつまでも甘い汁を吸っていられる自体はやって来るまい。
いつまでもウォータフォールを使っていられないようにな。

もしどんな顧客もむかつくやつしかいなかったらどうする? 甘い汁をすえそうな顧客がいなくなったら
お前らはプログラマやめるか? しかしプログラマ以外の仕事もどこへいっても嫌なやつ。
とくにな、出生すればするほど嫌な奴に遭うもんだぞ。
政治家は常に嫌な奴と対面している。
宇宙飛行士はどんなに嫌な奴でも長時間嫌なやつと一緒に作業しなければならない。
お前らはそれでも本当にエンジニアか?

嫌な奴とどのようにしてつきあい、嫌な奴をどうやって矯正しいい奴にするか? それも考えられないのか?
これだけストレスがたまりやすい世の中になったんだ。
これから嫌な奴はますます増えていく。とくに若年層から。

331 :仕様書無しさん:03/12/08 22:56
なるほど。

332 :仕様書無しさん:03/12/08 22:56
>>327
文句をいってくれないと、だれも自分の欠点をいってくれず
あの技術者どもはつかえない。やつらにたのむのはやっぱりやめてほかの会社にしよう。

ということになりかねない。

333 :仕様書無しさん:03/12/08 22:58
いい顧客がいるのになんでわざわざ茨の道を進むわけよ?
楽にたくさん金を儲ける人が偉いに決まってるじゃん。


334 :仕様書無しさん:03/12/08 22:59
>>332
文句を言ってくれないのと、文句を言わないのとは違う。
こっちの売り方が嫌な客とは契約しなければいい。こっちのやり方を気に入った
客とだけ仕事をすればいい。


335 :仕様書無しさん:03/12/08 23:00
>>329
お前は言ってしまえばブライドとエリート意識が高すぎた馬鹿と同じだ。
聖徳太子馬鹿みたいにうわべだけ笑みを浮かべた顧客をこのみ本質をつかめない性善説のみを信じているアフォか。
困難を乗り越えられないお前は大金持ちになれない。


お前に顧客を切り捨てられる権限があればの話だがな(w

336 :仕様書無しさん:03/12/08 23:02
>>333
いい顧客がもしいなかったら?
表面上のみいい顧客でも金蔓にもならず契約してから後で嫌な顧客だと発覚したら?

という場合どうするのかってきいているのだよ。そういうのが平和ボケしすぎっていうんだよ。

337 :仕様書無しさん:03/12/08 23:02
>>335
なんか難しい話されてもよく分からんが、要するに、こっちの気分が悪くなる
客とは取引しない。対等なビジネス・パートナーとなりえて、互いに互いの
存在がいいなあと思える相手とだけ商売する、そういうこと。


338 :仕様書無しさん:03/12/08 23:03
>>334
最初からそういえよw

339 :仕様書無しさん:03/12/08 23:04
>>336
作るか探すかほかの市場に切り替えればいいじゃん。
いまは、めまぐるしくいろいろな市場が成長し消えていくから、どれかにはある。


340 :仕様書無しさん:03/12/08 23:04
>>337
つまりお前は顧客の表面上のみを見て判断するDQNなわけだな。
氷山の一角のみを見て「氷山って小さいな」といっている馬鹿と同じだな。

341 :仕様書無しさん:03/12/08 23:06
>>340
バカだなあ。優良顧客とマッチするってのは、表面だけじゃだめなんだよ。
そのために、最終的に成約する客以外は、いろんなマーケティングで切り捨てて
行くわけじゃないか。


342 :仕様書無しさん:03/12/08 23:06
>>339
そのほかの市場も感じよさそうないなかったら?
お前らはそういったことを想定していないだろ。
餓鬼の頃に教師に怒鳴られたり説教された経験がないだろ。
本当に忍耐力の無い奴だな。

343 :仕様書無しさん:03/12/08 23:07
>>341
もっと具体的にどうぞ

344 :仕様書無しさん:03/12/08 23:08
>>342
そういったやつは初めから起業に向いていない。


345 :仕様書無しさん:03/12/08 23:09
>>343
たとえばだなあ。「彼氏の見つけ方無料小冊子プレゼント!」とやれば、
彼氏のいる女は募集してこない。


346 :仕様書無しさん:03/12/08 23:09
>>341

あれ? おかしいなあw
すでに成約してから顧客が怒鳴りだした場合はやっぱり切り捨てないんだw
いっていることが>>294と矛盾しているよねw

347 :仕様書無しさん:03/12/08 23:10
>>344
なんだって? 顧客が起業に向いていないって?
>>342といっていることがかみ合ってないなあ(藁


348 :仕様書無しさん:03/12/08 23:12
>>345
徐々に言い訳に必死になってきたなw

平和ボケしていたというのはまさに図星だったんだなw

349 :仕様書無しさん:03/12/08 23:13
もしお前らがアメリカ人だったら?
お前らすでにアメリカで射殺されているよ。

350 :仕様書無しさん:03/12/08 23:14
機嫌の悪そうな顧客を切るときは逆切れされないように気をつけよう。
逆切れしてあなたが殺されてしまいます。

351 :仕様書無しさん:03/12/08 23:25
>>346
バカだなあ、そんなこと言ってないよ。成約してからでも、契約書類上まずくなければ、
いつでも取引を停止する。

>>347
きみもバカだなあ。顧客じゃなくて、顧客を探すこちら側にいる人間のことだよ。


352 :仕様書無しさん:03/12/08 23:28
馬鹿というほうが馬鹿。

353 :仕様書無しさん:03/12/08 23:38
>>348

>>345の方法はマーケティングではふつうの方法ですよ。
たとえば「タラバガニプレゼント!」だと、自分の売りたい商品に直接
関係ない客まで応募してきて、顧客リストが薄くなってしまう。だから、
自分の売りたい商品に関連するものをプレゼントして応募させる。
たとえば熱帯魚屋さんだったら「熱帯魚の餌 1 年分プレゼント」とかすると、
すごく密度の濃い見込み客リストができる。
なんでもない人にセールスかけるより、応募してきた人にセールスをかけた方が
成約率が高いし、コストもかからないです。


354 :仕様書無しさん:03/12/08 23:51
1. 説得しないでも、あなたの商品を「それ、ください」といってくれる。
2. 費用がかからず出会え、そして手間がかからない。
3. さらに、他の顧客を連れてきてくれる。

このような理想的な顧客を、あなたは選ぶことにするわけ。
ここでたいていのヤシは怯むのである。「そんな都合のいい客がいるはずもない」とな。
しかし理想的な顧客を選ぼうとしなければ、はなっから理想的な顧客に選ばれる
はずがない。ほとんどの会社は、理想的な顧客の条件を詰めることもなければ、
イメージすることもない。理想的な顧客がイメージできなければ、アプローチ
できるはずがない。
その結果、他社と同じような商品を、多少同じような価格で、他社と同じように
営業する会社が大量に作られる。
看板を付け替えれば、どの会社だかわからないと言う状況だ。

本質的に、戦略というのは他社と差別化することである。差別化できないと、
顧客にとってはどの会社でも同じだから、きみの会社と契約する必然性は
まったくなくなる。だから値段を叩かれ、利益が取れなくなる。きみの会社は
付加価値をつけることができない。ということは、存在価値がないということ。
単純に言えば、企業にとって差別化が善であり、均質化は悪である。

355 :仕様書無しさん:03/12/08 23:55
>>351
> >>347
> きみもバカだなあ。顧客じゃなくて、顧客を探すこちら側にいる人間のことだよ。
きみが馬鹿なんだよ。良い顧客が豊饒の角のように無限にいると思っているのかい?(w
運悪く悪い顧客がいたらどうするんだ(藁
プロジェクトが進んで途中で取引を停止だって? そこで損害などがでて金だけもってかれるぞw


356 :仕様書無しさん:03/12/08 23:56
均質化は思考停止から生まれる。まわりの常識を疑わない。顧客からクレームが
来れば、それを受け入れ、社員から文句が来れば、それに従う。哲学がないから、
浮き草のように常識に流されていく。

差別化するためには、常識人たることを恥に思い、必要ないものを捨てることが
必要。丸い会社を目指すのではなく、尖った会社を作ることである。尖った会社を
嫌う客は当然出てくる。誰からも嫌われないということは、すでに危険信号なのだ。

誰からも好かれる。しかし誰も魅了できない。
顧客を魅了できる会社になるためには、自分に必要のない顧客を捨てることから
始めなければならない。


357 :仕様書無しさん:03/12/08 23:57
>>353-354
趣旨がずれて必死だな。
そんな百も承知なことで自分の無知を隠そうったって無駄だよw


358 :仕様書無しさん:03/12/08 23:58
>>355
ほとんどの会社は、理想的な顧客の条件を詰めることもなければ、イメージする
こともない。理想的な顧客がイメージできなければ、アプローチできるはずがない。

359 :仕様書無しさん:03/12/08 23:59
>>355
なんでもかんでも契約取っちゃうほうが危ないよ。

360 :仕様書無しさん:03/12/09 00:00
確かにね。お客さんを切り捨てれば切り捨てるほど儲かるね。


361 :仕様書無しさん:03/12/09 00:05
>>357
嘘つくなよ。嫌な客でも契約取るんだろ。それが君の常識なんだろ。


362 :仕様書無しさん:03/12/09 00:06
>>360
それは、こちらの商品、サービスに、より熱狂的な顧客層がつくからだよ。
そういうのはリピーターになってますますファンになってくれる。


363 :仕様書無しさん:03/12/09 00:09
そのうち客も、己のバカさ加減に気がついて少し賢くなる。
しばらく経つとまたその裏を掻くヤシが出てきてまた馬鹿に逆戻り。
この繰り返しが永遠に続くんだよなー。
進歩ねーよな。漏れたち。

364 :仕様書無しさん:03/12/09 00:09
ようするにさ、君らが言っているのは、儲けるためには、市場規模を小さく設定して、
悩みの深いところを狙うってことだろ。
市場規模を大きく取って、悩みも浅いと一番儲からないからね。


365 :仕様書無しさん:03/12/09 00:11
>>363
バカスパイラル、略してバカスパだな。


366 :仕様書無しさん:03/12/09 00:11
なんだかサラスパみたいだね。

367 :仕様書無しさん:03/12/09 00:12
なるほど。


368 :仕様書無しさん:03/12/09 00:43
狐と狸のバカかし合い.。

369 :仕様書無しさん:03/12/09 00:49
で、結論は奇麗事ばかり言っていて海外に駆逐されると。
技術力のあった町工場が結局は半分以下に淘汰された現状から考えるに、
技術力の全くないお前らは全員あぽーんだな。

370 :仕様書無しさん:03/12/09 09:16
つうか、引き篭もりの自称SEか?
こんなに2chで必死なところを見ると、暇なんだな。w


371 :仕様書無しさん:03/12/09 09:39
>>359
馬鹿か。優先順位をつけたうえでやっているんだが。
客がいなくなって収入源確保できなくなって
嫌な客しかいなくても取らないのか(w

372 :仕様書無しさん:03/12/09 09:42
日本の景気も徐々に衰退している。
いつまでも安全神話を鵜呑みにするのはそろそろやめたらどうだ?
現状維持ではこれ以上の景気回復は望めない。

顧客を切り捨てられる余裕がいつまで続くかな。

373 :仕様書無しさん:03/12/09 10:57
ウォーターフォールはあと20年消えない(実は「ウォーターフォールは終わり」の意味を隠している記事)
http://www.mars.dti.ne.jp/~hirok/xp/col/013.html


374 :仕様書無しさん:03/12/09 11:57
ウォーターフォールかXPか(あるいは別の何か)っていう選択はどうでもいい。

375 ::03/12/09 15:37
「悪い顧客を切り捨てずに受け入れる」という考え方の人に質問するけど、
そういう仕事を取って、業界をどのように健全化させていくつもりなの?

悪い顧客の言う悪い話を聞き入れて無理矢理開発する。
悪い顧客は、さらに悪い話を通そうとする。
悪い顧客がうまくいったという事例を聞き、もっと悪い顧客が増える。

という悪循環が出来るのは自明だと思うけど、その方が将来性に欠けるのでは?

376 :仕様書無しさん:03/12/09 16:04
>>375
あなたの考え方では他力本願で、パイの縮小を止められないよ。
受け持ち顧客を自分の好み基準で純化してるだけじゃん。

悪い顧客を受け入れるってのは無条件ではなく、それを教育してアジャストすること。


377 :仕様書無しさん:03/12/09 16:28
変化ヲ放尿セヨ

378 :仕様書無しさん:03/12/09 22:10
>>376
教育なんかに無駄な会社リソースを使うな。
教育にいくらかけるといくらになって戻ってくるんだ??


379 :仕様書無しさん:03/12/09 23:02
>>371
USP がないからだよ。See >>354>>356


380 :仕様書無しさん:03/12/09 23:11
>>376
> 受け持ち顧客を自分の好み基準で純化してるだけじゃん。

違う。新規顧客を集客する過程からダメなお客の切捨ては始まっている。


381 :仕様書無しさん:03/12/09 23:13
>>372
森を見て木を見ていないね。
成熟した経済では、景気が後退していきデフレになる傾向があるけれど、
超成長組と、超負組と、極端な二極分化が始まるんだよ。
西欧を見ても分かるとおり。
平均値としては景気後退だけれど、超勝組の企業が残るのが成熟経済の特徴。

382 :仕様書無しさん:03/12/09 23:14
>>372
森を見て木を見ていないね。
成熟した経済では、景気が後退していきデフレになる傾向があるけれど、
超成長組と、超負組と、極端な二極分化が始まるんだよ。
西欧を見ても分かるとおり。
平均値としては景気後退だけれど、超勝組の企業が残るのが成熟経済の特徴。

383 :仕様書無しさん:03/12/09 23:15
二重カキコスマソ

384 :仕様書無しさん:03/12/09 23:16
>>371
> 嫌な客しかいなくても取らないのか(w

そんな状況になるようでは、商売なんかしない方がいい。向いていない。


385 :仕様書無しさん:03/12/09 23:23
>>375
君の思っている「悪い顧客」の定義にもよるよ。

ちなみに、突然の仕様変更をしつこくなんども要求してくることは
XPやRUPの登場によってそれほど「悪い顧客」ではなくなったといっておもう。
度が過ぎるのも限界があるがウォータフォールモデルよりもまし。


386 :仕様書無しさん:03/12/09 23:26
>>384
お前は何もわかっていない。お前は現実を見ていなさすぎ。
もしお前が飛行機事故でサハラ砂漠の中心に立たされたとき
お前はどうする?

近くにオアシスも無い。手元には大金がある。
だが水も食料も残り少ない。

387 :仕様書無しさん:03/12/09 23:29
>>382
自分の会社がその超勝ち組に常になれると思ったら大間違い。
勝ち組よりも負け組みのほうが多いのが資本主義の世界。
負け組みになったときに対する備えも必要だ。
地震対策をするようにだ。

とくに日本人は危機管理を不得意としている。






>>382に限らずこのスレでレスしている香具師どもの
危機管理の悪さにはまったく呆れる。





388 :仕様書無しさん:03/12/09 23:29
勝負師のような厨房にはあきれる

389 :仕様書無しさん:03/12/10 00:03
>>387
だから USP を日々高めていく必要があるんだね。


390 :仕様書無しさん:03/12/10 00:17
セックスピーって何ですか?

391 :仕様書無しさん:03/12/10 00:19
>>386
サバイバルするよ。
あれね、袋を砂の上に置いとくと、飲み水できるよ。
金を増やすのなんか簡単だから、手元の金ぐらいどうってことない。
帰ったらまた増やせばいい。


392 :仕様書無しさん:03/12/10 00:21
>>386
コカコーラの自動販売機を探すよ。絶対あるよ。

393 :仕様書無しさん:03/12/10 00:21
大体金持ちって手元に大金持ってないだろ。
会社名義で証券や建物などとして管理しているんだよ。所有してるんじゃなくて。


394 :仕様書無しさん:03/12/10 00:23
金持ちは「自分名義の財産」ということで調べると、ほとんど貧乏人と
同じらしいね。税務署がきても。


395 :仕様書無しさん:03/12/10 00:27
大体、自分が海の上にいようと砂漠の真中にいようと、金持ちは勝手に
金が金を生んで、家に帰ったらもっと金が増えているようになってるんだよ。
生きて帰れればだけど。
せいぜい事故らないようにね。



396 :仕様書無しさん:03/12/10 00:28
>>395
労働から開放されているから、どんどんと新しい金儲けの勉強もできるし、
絵や音楽が好きなら、もっといい先生に習うこともできるんだね。
お金が儲かれば儲かるほど自由な時間が増える。


397 :仕様書無しさん:03/12/10 00:30
俺も金持ちになりたいな。
俺は金持ちになった。


398 :仕様書無しさん:03/12/10 00:30
>>397
よかったね。うん、よかったね。


399 :仕様書無しさん:03/12/10 01:24
>>391
おいおい、何もないところでは金は何も役にたたんぞ。

>>392
くだらないCMの影響をうけて幻覚でもみるやつがそういうことをいう。

400 :仕様書無しさん:03/12/10 01:25
>>386
電話する

401 :仕様書無しさん:03/12/10 01:35
なんかマジレスしてる人がいるよな、ここ…

402 :仕様書無しさん:03/12/10 05:07
>>399
> おいおい、何もないところでは金は何も役にたたんぞ。

バカだなあ。だから、サバイバルするって書いてあるじゃん。


403 :仕様書無しさん:03/12/10 05:13
>>402
>>399のサバイバルは大金がかかるらしい。


404 :仕様書無しさん:03/12/10 09:08
ウォータフォールで、突然の仕様変更をしつこくなんども要求してくる顧客
に困らされるはずはないのだが。それを防止するためにあるので。
そのような顧客に困らされるということは、単に、
ウォータフォールを実践できてないのであって、その良し悪しを言う以前の話。

自販機のボタンを押してから出てくるまでにたまたま時間がかかるからといって、
その間に変更できると思う馬鹿はいない。
問題は、そのボタンを吟味して選んだかどうかだ。

405 :仕様書無しさん:03/12/10 10:00
>>404
前半は日本語とは思えないが理解は出来た。
後半は「いい比喩をありがとう」とだけレスしておこう。

406 :仕様書無しさん:03/12/10 10:33
>>400
こいつ真性のアフォだな。
お前はすぐに即死だ。

出直して来い!

407 :仕様書無しさん:03/12/10 10:36
http://sports.2ch.net/test/read.cgi/kyozin/1062569486/l50

524 :ナナシマさん :03/11/28 13:54 ID:???
彼は、阪神公式サイトを作成管理している会社にいたらしい。
マジで書いてたよ。
2.削除依頼について
確かに、A社の常務と総務部長が、大阪から徳島にやってきて、私の父にコピーを見せて削除を依頼しました。
父は定年退職しており、インターネットのことなどまるでわかりません。
それ以降、家族を撒き込まれるのが絶えられず、インターネットに同種の投稿をするのを控えていました。
ところが、数ヶ月後、最初の訪問より前に書いた同種の書き込みのコピーが、私の父宛てに内容証明郵便で送られてきました。
それには、「親会社の阪神電鉄と共にネット上を検索していたら、こういう書き込みが見つかった。また削除してくれ」と書いてました


408 :仕様書無しさん:03/12/10 10:36
>>404
自販機を使うのはリリースされた製品使うをユーザであって
プログラマとして自販機を開発する立場そんな制限された使い
かたをするではない。


409 :仕様書無しさん:03/12/10 10:36
ウォータフォールで開発している方々へ質問
仕様凍結日付というのを設定していますか?

410 :仕様書無しさん:03/12/10 10:43
>>409
仕様は永遠に凍結されない。
完成したものが仕様だ。


411 :400:03/12/10 15:00
>>406
馬鹿馬鹿しさに気がついた?冗談としてはいい出来だと思うけど。

412 ::03/12/10 16:04
レス遅くてごめんねー。

>>376
理解できるが、理想論にしか見えない。
どうやって悪い顧客を教育するの?

長文読める人は以下も読んでね。

最終行の「悪い顧客を教育する」という考え方について質問するけど、
1. 「XPは開発方法論だけでは無く、顧客を教育する方法論でもある」と考えるか、
それとも、2.「顧客を教育するために何らかの新しい方法論が必要」か?

言い方を変えると、このスレの流れでは、
「開発方法を選択するのは顧客の権利である」という意見があるのだけれど、
開発方法論によって顧客が教育を受けれるか受けれないかが変わってしまうのなら、
「悪い顧客を教育するのは無理」という結論が導かれかねないのではなかろうか?

413 ::03/12/10 16:09
>>385
「悪い」は定義しない事にするよ。それだけで1スレ消費できそうな話題だと思うから。

「突然の仕様変更をしたいならXPを開発方法論に選びなさい」
というのは可能なのかな?

これは「教育」なのだろうか?

414 :仕様書無しさん:03/12/10 16:21
仕様が決まらなきゃ完成もありえないだろ・・・


415 :仕様書無しさん:03/12/10 16:26
>>413
どの程度の仕様変更かによる。
度が過ぎれば断ってもらうことは当然。

だが、XPやRUPはWFよりも突然の仕様変更に対する柔軟性が高いことは間違いない。

416 :仕様書無しさん:03/12/10 17:01
>>414
仕様は絶えず変わることを前提とする。
完成したと判断したときのものが仕様となる。


417 :仕様書無しさん:03/12/10 17:31
>>416
どこが、あるいは誰が「完成したと判断」するのか
を教えてくれ。

418 :仕様書無しさん:03/12/10 17:56
検収はどうすんの?

419 :仕様書無しさん:03/12/10 18:01
>>417
顧客(自社の場合は責任者)が製品として納得したら完成だろ?
だから受託形式では成り立たない。



420 :仕様書無しさん:03/12/10 19:16
>>414
そなたの考え方は
ウォータフォールモデル症候群がもたらした悪しき化石的思考だ。

421 :仕様書無しさん:03/12/10 22:30
>420
XPを歪んだ捕らえ方してるいい例だ。
仕様は絶えず変わるが、少なくともその時点での完成(仕様)を明確にせんでどうする。
君はメソッドを実装する前にテストケースを用意しないのか?


422 :仕様書無しさん:03/12/11 00:37
負けず嫌いが>>420のレスを勝手に脳内解釈してどうする。

423 :仕様書無しさん:03/12/11 00:53
>>422
リンクが切れた。再カキコ。

こんな風に吹きたいんですけど、リガチャーは何にすればいいんですか?
http://mfile.akamai.com/3171/wm2/muze.download.akamai.com/2890/us/uswm2/273/60273_1_05.asx?obj=v10207
とか
http://mfile.akamai.com/3171/wm2/muze.download.akamai.com/2890/us/uswm2/273/60273_1_09.asx?obj=v10207
とか。

424 :仕様書無しさん:03/12/11 09:02
>>421
あなたこそ、話の主題が見えていないと思う。
自社開発、派遣形態で無い限り、お客は納品物に対して評価をするわけでしょ?
その納品物ってXPの1イテレートで作成された中間生成物に対して払うと思う?


425 :仕様書無しさん:03/12/11 10:17
まずどのレベルの「完成」を語ってるのかはっきりしてくれ。
メソッドの完成か。
機能の完成か。
システムの完成か。
仕事の完成か。

426 :仕様書無しさん:03/12/11 15:17
顧客にリリースすることをひとまず完成とすると、

それでも潜在的バグは存在することが多い。
完成後も引き続き反復型開発でバグ修正などを行う。
リリース後に機能拡張を求められることもある。ここで「それは仕様です」と逃げれば
己に対する悪いうわさが顧客の間で広まる。拡張しやすい製品をつくることだ。
そのためにはオブジェクト指向は大前提。

427 :仕様書無しさん:03/12/11 15:21
>>426
全然理屈になっていない。
バグがあるものを売ることを前提としている時点で、感覚が麻痺している。


428 :仕様書無しさん:03/12/11 18:19
あほか。バグの全く無いソフトなどあると思ってんのかこのトンチンカン。

429 :仕様書無しさん:03/12/11 18:22
>>423
誤爆? 

430 :仕様書無しさん:03/12/11 18:54
ある程度以上の規模のソフトは、バグの存在が確認されていても、
(「出荷判定会議」とかを開いて)リリースされる場合もある。
これは事実

431 :仕様書無しさん:03/12/11 20:22
ウィンドウズを搭載した銀行ATMに初のウイルス/Hotwired Japan 12月11日 17時20分

http://www.hotwired.co.jp/news/news/technology/story/20031211305.html

432 ::03/12/11 22:46
>>424
それを「中間生成物」と考える事こそが、>>420の言う「化石的思考」なのでは。

1イテレーションごとに実用的な物を作って、
好きなイテレーションで契約を終了できるのがXPです。
と定義したら、その定義において「契約の終了が完成を意味する」事は納得できる?

「1イテレーションごとに実用的な物が作れるか」という問題とは別にして考えてね。


433 :仕様書無しさん:03/12/12 09:15
>>432
で?
その半端な状態で客はどうするの?
最初に予算決定があるわけだから。

434 :仕様書無しさん:03/12/12 10:09
>>430
ある程度以上の規模のソフトは、バグの存在が確認されていなくても、
バグは存在することが知られている。

435 :仕様書無しさん:03/12/12 10:15
>>434
確認されたバグの話をしているのに、確認されていないバグの話を持ち出すとはこれいかに

436 :仕様書無しさん:03/12/12 10:20
>>433
半端かどうかは客が判断するわけだから、

1) 客にとっては半端ではなく十分な機能となった
2) 半端な段階だが急遽予算削減の指示があった
3) 半端な段階だが完成しても意味がないぐらいビジネスの状況が変わった
4) 半端な段階だが完成させるには開発側の能力が不足していると感じた
などの理由で契約終了を判断したわけだ。

1)はXPだからこそ発生する状況。予算が余ることになるが、余ると困るというのは
「化石的思考」や「役所的思考」、「大企業病」の一種である。
まあ、余ったら困るところは契約を終了しないだろうが。
2)、3)は開発側の状況や、開発プロセスの選択とは全く関係ない理由。XPでは
このような状況においても価値を残すことを目的に構成されている。半端な価値だが
0では無いということ。
4)はXPだからこそ、顧客側はその判断を下せたとも考えられる。WFでは中間生成物
に対して顧客側が十分な評価を下すことは困難である。
つまり、自分の能力に見合った評価を受けると困る者は、XPでは困るということだ。




437 :仕様書無しさん:03/12/12 10:22
>>435
426では、「潜在的」といっているので、元々確認されていないバグの話だったのだよ。


438 :仕様書無しさん:03/12/12 10:33
>>436
では、ある仕事の依頼があって、概算を出せといわれた場合はどう対処するの?
また、それをオーバーした場合の責任の所在は客?

439 :仕様書無しさん:03/12/12 10:42
>>408
自販機のボタンを押すまでに悩む過程が設計フェーズ。
押してから出てくるまでが開発フェーズ。
という喩え。

440 :仕様書無しさん:03/12/12 10:46
>>426
何か勘違いしてないか?
機能拡張はごく普通に追加発注だよ。
改めて拡張部分の設計をし、確定し、開発するだけ。それがWF。

441 :仕様書無しさん:03/12/12 11:23
>>435
あほか、>>426ですでに潜在的バグ(==確認されていないバグ)といってるだろうが
それをお前は勘違いして>>427で全然理屈になって無いなどとほざく

442 :仕様書無しさん:03/12/12 11:27
>>440
機能拡張の規模にもよるんだよ。
作って顧客が進捗状況を確認している間にあらゆる問題点や疑問点に気づく。
そこで追加機能や修正などの変更を求めることがある。

ソフトウェアだからこそできるものだ。
これがハードウェアや製造業だったらすでに加工済みのものを無理やり解体するなどして到底できないことがほとんどだろう。

そうだ、ウォータフォールは製造業向けなのだ。

443 :仕様書無しさん:03/12/12 11:41
それって所謂終わり無き仕様変更では?



444 :仕様書無しさん:03/12/12 11:45
>>442
>ウォータフォールは製造業向けなのだ。
よく気がついたね。昔からそれはいわれている。
古典的な要素還元主義主義を理論的な基盤にした、テーラーの科学的管理法を
フォードが適用して成功を収めたのが有名だ。
ウォータフォールは科学的管理法のソフト開発への応用なんだ。
だがこれは、多量少品種向きの生産方法論であって、少量多品種の極限であるソフト開発
とは親和性が悪いのは衆目の一致するところだろう。

445 :仕様書無しさん:03/12/12 12:06
>>436
から考えると、XPって開発側よりも顧客にとってのメリットが大きい方法論だといえるね。
もっとそういうことを強調していけばXPを広めやすいんじゃないかな。

446 :仕様書無しさん:03/12/12 12:52
>>438
開発プロセスとは何の関係もない話。
ウォータフォールはウォータフォールのプロセスに従って見積るし、
XPはXPのプロセスで見積る。
見積り結果が間違っている可能性が高い場合(対象が初めてやるものなら大抵間違う)は
見積り条件に含める。


447 :仕様書無しさん:03/12/12 12:55
>>445
ちょっと違う。
XPだろうと何だろうと顧客側は既にこういうメリット
(短期開発や臨機応変な仕様変更など)を求めてきている。
それを開発側が現実的に受け入れられる(つまり成功する可能が
高いものにする)ための一つの方法がXP。

ウォータフォールで顧客の要望を満たせるなら、別のものに変える必要は無い。


448 :仕様書無しさん:03/12/12 12:58
XPの中身はそのテの本を読めばいいから別に良いけど、既存の開発からXPへの
移行に伴うノウハウを聞きたい。
対外的な契約や見積もりをどうする、とか。
>436じゃないけど、海外では商習慣が違って話はよく聞くけど、本場でも概算見積の
要求とかはある訳でしょ?



449 :仕様書無しさん:03/12/12 13:34
>>443
人生とはそういうものだ。
勉強は終わらない。生涯学習あるのみ。

450 ::03/12/12 16:29
>>448
> 既存の開発からXPへの移行に伴うノウハウを聞きたい。

ノウハウじゃないけど、感想。

開発側が小規模リリースやペアプログラミングや、
特にテストファーストがしっかり出来てないと、XPは対外的に要求できないよ。

XPの利点を示すために「まずやってみせる」というのは、確実だと思うなあ。


451 ::03/12/12 16:47
>>447
最終行に激しく同意。

>>438
君の言いたい事を言い直すと、
「XPではどうやってプロジェクト全体の見積をとるのか」という事だよね。

別に、1つのイテレーションが定義できれば、
「そのイテレーションが予定通り達成した場合にどう次のイテレーションを行うか」は、
見積もる事が出来ると思うよ。
ただし、XPでは「実現可能かどうかの調査は見積時に行う」事になっていたと思うので、
調査事項は多岐に渡り、調査時間はかかるかも知れない。

でも、見切り発車をしてはいけないのはWFでもXPでも同じだと思うけどね。>>446が言う通り。


452 ::03/12/12 17:20
シナリオ。
顧客「私はABCDEシステムが3ヶ月以内に欲しいです。できますか? いくらですか?」
開発「見積には時間がかかりますが、よろしいですか?」

見積その1。
開発「2週間かけて調査と見積をおこないました」
開発「開発者の数には限りがありますので、システムを平行開発する事はできません」
開発「AシステムとBシステムは各1ヶ月で各600万円、Cシステムは0.5ヶ月で300万円です」
開発「DEシステムは別途各1ヶ月戴ければ出来ます。費用は各600万円です」
開発「納期が重要であれば、子会社で、DEを各1,000万円で、ABCと平行開発できます」

見積その2。
SE 「即答いたします。システムの開発費用はおよそ3,000万円です。
   調査に0.5ヶ月、設計に1ヶ月、開発に1ヶ月、検査に0.5ヶ月です」

てきとーに書いただけなので、この案件がどうなったかはご想像におまかせします。


453 :仕様書無しさん:03/12/12 23:34
>>442
仕様凍結後は封印して、テストが終わる前に見せちゃ駄目だよ。
別に見積修正すればいいけど、ややこしくなる。
それより、そういうのが頻繁に出るのは打合せ資料に問題があるんじゃないかな。
外形仕様ベースで明確に説明してる?

454 :仕様書無しさん:03/12/13 10:30
梨って自分の日本語がおかしいことに気づいてるのかなぁ

455 :仕様書無しさん:03/12/13 11:39
>452
顧客「うーんもっと安くならないの?
営業「すみません、これでギリギリなんです
顧客「じゃあ値引きはいいからこっちの要望をもっと取り込んでよ
営業「わかりました!!

って事でその1もその2もデスマ

456 :仕様書無しさん:03/12/13 15:22
どうやらその様デスマ(あげ)

457 :営業:03/12/13 18:32
大丈夫です!
これがXpのメリットです。作りながら仕様を追加できるんですよ。
私が開発を上手いこと丸め込んでおきます。ご安心下さい。

458 :仕様書無しさん:03/12/13 21:25
>>457
虚露すよ。営業はだぁっとれ!

459 :仕様書無しさん:03/12/14 02:56
営業が打合せやってるような会社はそのうち力尽きて派遣会社に成り果てる。

460 :仕様書無しさん:03/12/14 03:23
ホントのデスマを知っていてここにいるヤツはいまはデスマとは無縁

461 :仕様書無しさん:03/12/14 10:53
『結論』

要求仕様書の作成さえもベンダに任すユーザがほとんどなのに、
そのユーザがXPを適用できるわけがない。

-------終わり-------

462 :仕様書無しさん:03/12/14 14:50
じゃ、つまりRUPを適用すればいいってわけね

463 :営業:03/12/14 14:57
Xpですから、ウチのSEには適当に言っておいて良いですよ。
後からいくらでも追加できる。これがXpです。お客様を第一に考えた結果、
我社はXpを採用しました。
検収までに、思いついたことをお申し付けください。

464 :仕様書無しさん:03/12/14 16:29
アージャイル様に頼めばウォータフォールを破壊してくださる。

465 :仕様書無しさん:03/12/14 17:05
    「XP……RUP……」
      「どうやらこの板にはアジャイル開発を信仰してる奴がいるみたいだな」
「どうせ雑誌かネットで記事読んで誤解してるんだろ? ウケウリってやつ?」
  「……無能な者は極論に走り……拠り所を失いて己を狂信者と成す……」
 「やらせておけばいいさ。流れる水は不滅だ。そうだろう?」
          「……流れる水は……滅ぶことは……無い……」
    「文明が水に頼ることを続ける限り」
            「我等の滅びは有り得んのだ」

           「「「「ハイル!」」」」

466 :仕様書無しさん:03/12/14 17:46
おお!

これがウォータフォール信者の最後の断末魔かっ!


467 :仕様書無しさん:03/12/14 21:40
cobolerはxpできまつか?

468 :仕様書無しさん:03/12/14 21:55
>>467
オブジェクト指向言語で無いと、テストやリファクタリングの実現方法の
関係で、XPするのは難しいそうです。

469 :仕様書無しさん:03/12/14 22:01
>>468
cobolerは逝くしかないようですね。


470 :仕様書無しさん:03/12/14 22:02
COBOL2000とかでなんとかかろうじて延命処置をとってXPのさわりがやっとできるといったところだろうか・・・

471 :仕様書無しさん:03/12/15 01:18
VBerはxpでき...そうで難しい

472 :仕様書無しさん:03/12/15 01:36
営業は喜ぶだろうな。

473 :仕様書無しさん:03/12/15 04:20
Delphierだけはxpできそうもないな。

474 :仕様書無しさん:03/12/15 09:24
大体どちらかの手法のみに傾倒するってのは、厨の証拠だよな。
良方式の良い部分を上手く抜き出して、程よくブレンドするのが、真のSEってもんだ。


475 :仕様書無しさん:03/12/15 15:08
>>473
できんじゃねえの? オブジェクト指向言語だし

476 :仕様書無しさん:03/12/15 15:09
>>474
いっておくが
ウォータフォールの考え方はXPやRUPに包含されているぞ

477 :仕様書無しさん:03/12/15 17:36
エンタープライズの受託開発で実際にやってみたことある?

478 :仕様書無しさん:03/12/15 19:55
純粋にxpできるのは
java、c++、c#、delphiってこと?
そのほかは?

479 :仕様書無しさん:03/12/15 20:01
ちょっとまってくれ
>>468
>オブジェクト指向言語で無いと、テストやリファクタリングの実現方法の
>関係で、XPするのは難しい
ってのをもう少し説明してくれないか

480 :仕様書無しさん:03/12/15 20:45
まあ実際に難しいけどな。
XPやRUPはオブジェクト指向前提だし

481 :仕様書無しさん:03/12/15 20:50
ライフサイクルモデルの亜流なの?


482 :仕様書無しさん:03/12/15 22:41
>>481
懐かしい単語が出てきたね。最近はあまり使わないなあ。
XPっていうのは、ウォータフォールの言葉で言うと、要求分析から試験までの新しい開発モデルのことだよ
#ライフサイクルモデルってウォータフォールを前提としているものだと思っていないかい?

483 :仕様書無しさん:03/12/15 23:18
COBOLはある意味Extremeだな。
WebアプリなんかだとCOBOLのCOMMAREAと大差ないけど・・・

484 :仕様書無しさん:03/12/16 01:43
>>478
D言語、Ruby, MixJuiceなども。

しかし、Smalltalkだけは付け忘れてはならない!

あとSmalltalkがXPをもっとも純粋にできる言語。
XPを考え出したSmalltalkerだったケントベックは、
Smalltalk用にXPを実践しやすい開発環境としてVisualWorksというIDEを開発した。
それが、今はオープンソースJava IDE Eclipseに受け継がれている。

さらにケントベックはデザインパターンで有名な
ギャング・オブ・フォオァの一人エリック・ガンマと共に
テスティングフレームワークJUnitを作った男。

テストファーストを実践しやすくするようにJUnitを作った
エリックガンマとケントベックは偉大だ!

SmalltalkなくしてXPは始まらなかったのだ!



485 :仕様書無しさん:03/12/16 07:18
テストファーストなんていまどきはやんないよ

486 :仕様書無しさん:03/12/16 10:12
>>485
そうだな。今はTDDだ。

487 :仕様書無しさん:03/12/16 12:18
テスト駆動開発にはテストファーストが使われてる

488 :仕様書無しさん:03/12/16 12:21
ウォータフォールは死滅!

これからはラーショナルに!


   ス リ ー ア ミ ー ゴ ォ


                    の 時代!

 U M L を使えない奴は死滅!

 いまだにフローチャートしか書けない老人は死滅!

489 :仕様書無しさん:03/12/16 20:31
>>487
TDDはテストファーストじゃないよ

490 :仕様書無しさん:03/12/16 21:06
テストは つ ね に ラストです。みんなそうだろ?

491 :仕様書無しさん:03/12/16 21:31
>>490
いや。俺は自分のコードを信用してないんで常に「書いたらすぐテスト」だよ。

492 :仕様書無しさん:03/12/16 23:15
>>489
レッドフェーズをテストファーストと言わないのか

493 :仕様書無しさん:03/12/16 23:21
>>492
言わない

494 :仕様書無しさん:03/12/17 07:48
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020904/1/

この記事だとテストファースト=TDD扱いだな。
厳密にいえば、テストファースト∈TDDか?

>> 493 は否定するだけじゃなくて、その理由をはっきり示してくれ。

495 :仕様書無しさん:03/12/17 08:04
>>494
その記事は間違っている。
理由を示せって、理由も糞も無い。違うんだから。
自分がまず間違ったとことを言って、違うと指摘したら、指摘した人間に
説明責任が発生する?
笑わせるなよ。そりゃおこちゃまの理論だ。違うと指摘されただけでも
感謝されてもいいんだがな。

496 :仕様書無しさん:03/12/17 10:15
>>494
プロテスタントとカトリックぐらい違う。

497 :仕様書無しさん:03/12/17 13:03
TDDはまずレッドフェーズで先にテストコードを書くやんけ。
んじゃテストファーストやね?


498 :仕様書無しさん:03/12/17 13:05
>>496
キリスト教以外の視点から見れば大してかわらんと思う。

499 :いなむらきよし:03/12/17 17:12
キケー!

500 :仕様書無しさん:03/12/17 23:23
>>499
意味不明なアフォなレスだな


501 :仕様書無しさん:03/12/17 23:48
>>495
> その記事は間違っている。
> 理由を示せって、理由も糞も無い。違うんだから。

あんた、この業界から足洗ったら?向いてないよ。


502 :仕様書無しさん:03/12/18 00:16
ウォータフォールはXPです。
違う?理由を示せよ。

503 :仕様書無しさん:03/12/18 00:26
XPのテストファーストは「テストをまず書き始める」ことではない。
TDDでは確かにテストをまず書くことからはじめるが、XPのそれとは違う。

わかったか、馬鹿共。

504 :仕様書無しさん:03/12/18 00:29
複数の方法論を提唱した香具師は今までいない。Kent Beckも例外ではないと思うが。
該当書籍を読め。

505 :仕様書無しさん:03/12/18 00:34
>>503
つまり、XPのテストファーストと、TDDは「テストをまず書き始める」ことは
共通してるということですね?
それ以外に共通点はありますか?

506 :仕様書無しさん:03/12/18 00:35
Test Firstを「テストファースト」と訳した奴が悪い。

507 :仕様書無しさん:03/12/18 00:36
>>505
xUnit推奨ってことくらいか。方法論としては全然違うものだ。

508 :仕様書無しさん:03/12/18 00:48
開発中に開発者自身がテストしながら作るのはあたりまえじゃないか。
なぬをいっておるのか。

509 :仕様書無しさん:03/12/18 00:52
>>508
そのあたりまえをきちんと方法論として確立したのがTDDだ。

510 :仕様書無しさん:03/12/18 01:57
TDD
・あえて失敗させる
・フェイク
・リファクタリング
の繰り返しでつ

テストファーストとは微妙に違ってまつ
わざと失敗させない、フェイクもしない


511 :仕様書無しさん:03/12/18 02:00
テストファーストもわざと失敗させるよ。

512 :仕様書無しさん:03/12/18 09:09
>>510
そのまんまTestFirstですが、何か?

513 :仕様書無しさん:03/12/18 09:46
XPのサイト読んでると、
テストファーストは最初に失敗する事を確認するのが重要
ってあちこちに書いてあるが・・・
どちらにしろ俺は正式なキュメントは何も読んでないけどさ

514 :仕様書無しさん:03/12/18 13:02
じゃあ説明するよ。

テストファーストはテストを最初にやるというだけ。
実装より先にテストを書くから最初は必ず失敗する。

TDDはテストに開発を駆動させる。
開発の為にテストを書くからテストは必ず最初に書く。

違いはテストを書いている段階で実装を想定するかどうか。
テストファーストでは実装を書くより先にテストを書けば良いが、
次に書く実装を頭で考えていても間違いではない。

TDDではテストを通すために実装を行うので、失敗するテストが
存在しない段階で実装のことを考えてはいけない。


515 :仕様書無しさん:03/12/18 14:36
TDDて何の略?

516 :ヽ(´ー`)ノ:03/12/18 14:52
Test Driven Development では?

517 :仕様書無しさん:03/12/18 22:45
なんか息苦しそうだな

518 :仕様書無しさん:03/12/18 23:38
>>502
それはRUPの間違いではなかろうか

519 :仕様書無しさん:03/12/18 23:39
>>504
ケントベックの書いたあの水色の本

テスト工藤開発入門で十分ええよな?

520 :仕様書無しさん:03/12/18 23:40
>>505
どちらもレッドフェーズから始まる。

521 :仕様書無しさん:03/12/19 00:08
最後までレッドフェーズ・・・

522 :仕様書無しさん:03/12/19 00:18
テストファーストやりませうって提案したらそんなめんどくさい事やってられん
わボケェって言われました。
普及の為のよい手段はないでしょうか

523 :仕様書無しさん:03/12/19 01:00
TDDをやってるとリファクタリングブラウザが必要だと痛感する....

524 :仕様書無しさん:03/12/19 01:14
WF…最後にデスマ
XP…最初からデスマ


525 :仕様書無しさん:03/12/19 01:18
WF…納期が来たら納品(バグあり)
XP…客があきらめたら納品

526 :仕様書無しさん:03/12/19 09:16
WF・・・直進の滑り台
XP・・・螺旋状の滑り台


527 :仕様書無しさん:03/12/19 11:07
WF・・・プロにしかできないので営業が嫌がる
XP・・・素人が昔からやってた危険なことを格好よく言い直しただけなので営業が喜ぶ

528 :仕様書無しさん:03/12/20 13:37
ところでなんでWF以外=XPなんでつか?
重量級 RUP
中間 FDD
とかクリスタルとかその他色々ありまつが?

529 :仕様書無しさん:03/12/20 17:48
じゃ、RUPスレやクリスタルマンセーすれとかをたててくれ

530 :仕様書無しさん:03/12/22 02:08
>>527
そこまでして必死にウォータフォールを弁護しなくても

531 :営業:03/12/22 02:50
いまだにWFなんてやってる会社は負け組

532 :仕様書無しさん:03/12/22 03:19
マ板に来てる営業も負け組

533 :仕様書無しさん:03/12/22 09:04
まあ、言葉だけでXPでとかいってる営業もおしまいだと思うがな。
お前は数年前はITとかいって営業してたんだろ?
その前はダウンサイジングか?
で、その言葉を説明もできやしない。


534 :仕様書無しさん:03/12/22 13:14
スレタイを

ウォータフォールは死滅!これからはXP,RUPで決まり!

にするべきだったな

535 :仕様書無しさん:03/12/23 00:34
RUP は重いよ。


536 :仕様書無しさん:03/12/23 00:36
80kgはあるからな。


537 :仕様書無しさん:03/12/23 01:13
そんなに重いのか。


538 :松井 ◆...VBh.www :03/12/23 01:14
皆さんはじめまして
突然ですがYAHOOのトップにチャットという項目があるのはご存知ですよね?
そちらのチャットのカテゴリの中に「政治」があります
その政治カテゴリのユーザールームに「創価学会YAHOO支部」という部屋があります
そこの部屋に遊びにきてください
ボイスチャットもフル稼働です
みなさんの中にも創価学会に対するご自分の意見をどんどん言ってください
その宣伝でした
尚、人数制限がありますので(50人)すぐに満室になって入れなくなるので
今これを読みまして興味を持たれた方はおはやめのご入室をお勧めします


539 :仕様書無しさん:03/12/23 01:17
>>538お前、何言ってんだ?
層化がいなくなると芸能界が成り立たないだろが!
芸能人の何割が層化だと思ってんだ、このヴぉk(ry


540 :仕様書無しさん:03/12/23 01:20
そうか。


541 :仕様書無しさん:03/12/23 01:37
ウォータフォールは創価のたまもの

542 :仕様書無しさん:03/12/23 03:46
>>541 ネタにマジレス
>>13
新しいものはたいがい米から入って来る。間違いも含めてね

543 :仕様書無しさん:03/12/23 16:21
新しいものって30年前の滝はもう新しくないわな

544 :仕様書無しさん:03/12/23 18:03
>>543
第二次大戦後からずっとそうだってことだ。
「最近覚えた新しいこと」はなんだ?

545 :仕様書無しさん:03/12/25 05:54
外形仕様とかWFというものはIBMが発明したそうだね。

546 :仕様書無しさん:04/01/02 13:33
ペアプロかなんだか知らないが、
ごちゃごちゃ喋りながら作業するんじゃねえよ。
それもくだらない内容で・・・

547 :仕様書無しさん:04/01/13 02:54
こんなのを見つけました。

http://www.fanta.dk/showmovie.asp?mid=3E7C89C1-CA01-47D1-8E11-386CC736E0A0


548 :仕様書無しさん:04/01/13 06:51
>>546
くだらないかどうかはあんたが決めることじゃない。
幼稚園からやりなおせば?

549 :仕様書無しさん:04/01/14 09:18
>>546

無能と無能を組み合わせたときの会話はすごいね

550 :仕様書無しさん:04/01/14 10:25
ペアプロって疲れるね。
コンビでボケ担当だと、どうやって相手に突っ込んでもらうかの隙を作るのが難しい。
単純なボケだけじゃ飽きられるし、あんまりひねってもしょうがないし。


551 :仕様書無しさん:04/01/26 12:14
いまだにウォータフォールモデルしかできない愚か者は即刻クビ
なら説得力あったかも

552 :仕様書無しさん:04/01/29 18:15
パチョンコン組は楽しそうでいいな(´,_ゝ`)

553 :仕様書無しさん:04/02/19 09:40
>>522
これは俺も知りたいなあ。

テストって、どの程度作るの?全部の関数に書くんじゃないよね?
ユーザインターフェースに近い、上位の関数だけ?


554 :仕様書無しさん:04/02/19 13:28
>>553
これはバグ入りそーだなー、と思った奴だけ書いてる。
流石に全部の関数に書くのは負担が…。

555 :仕様書無しさん:04/02/19 20:48
>>553
ユーザインターフェースって対人?ならそこはあきらめます(自動実行テストしません)

それ以外は基本的に全部テストする(ってゆーかテストから先に作ってると、テストが無いものは作られない)

556 :仕様書無しさん:04/02/20 03:08
>>555
UI以外は、すべての関数でテストを作るってこと?
それは少し無駄かなとおもう。
小さい関数はあまり書き換えないし、デバッガでのテストのほうが手間も少ない。

何度もテストを繰り返す、ある程度上位の関数にだけテストを作れば、
それが使っている下位の関数を書き換えた場合も、これでテストできるのでは?

↑を実践してるわけでないので予想だけど・・・


557 :555:04/02/20 03:34
ちょっと違うな
下位の関数のテストを作ってから下位の関数を作るのさ
下位の関数が上位から呼ばれてるかどうかは気にしない
上位の関数のテストは下位の関数のことは気にしてない

んで下位の関数を書き換える場合は、まず下位の関数のテストを作ってからにするって事


558 :仕様書無しさん:04/02/22 12:01
>>556
きみはきみのやり方でやればいいさ。
なぜTDDがいいか説明するのめんどいし。

559 :仕様書無しさん:04/02/22 21:27
>>522
とりあえず、自分の担当分だけでも自動実行テストがあると違うよ。
1)バグってる、とわかた時の修正が早い
2)相手に説明しやすい。「こんな感じで使ってちょ」
3)どうして欲しいかヒアリングして把握しやすい
 「ぢゃこんな感じでいいのかな?」


560 :仕様書無しさん:04/02/22 22:03
>>557
もまえはいわゆるプライベート関数までいちいちテストするのか?すごいな(w


561 :仕様書無しさん:04/02/22 22:43
>>560
さいしょに実装ありきの発想だね、それ。

きみはきみのやり方でやっていいってばさ。
他人のやり方に口ださないでくれる?

562 :仕様書無しさん:04/02/22 22:47
>>560 >>561
TDDじゃ無くて単体テストするだろ。

563 :562:04/02/22 22:48
× TDDじゃ無くて単体テストするだろ。
○ TDDじゃ無くても単体テストするだろ。

564 :仕様書無しさん:04/02/22 23:07
(557ではないが)
どうやってprivateメソッドをテストしますか?
publicにしてテスト?

565 :仕様書無しさん:04/02/23 00:20
>>564
テスト時にも絶対に変更してはいけないの?
そうだったらセルフテストメソッドを追加する。


566 :仕様書無しさん:04/02/23 00:39
>>565
>テスト時にも絶対に変更してはいけないの?
いやほら「本番向けコード」と「テスト向け」で違っちゃうから

>セルフテストメソッドを追加
これやると「使われないメソッドがあります」って怒られるんだよな(w


567 :仕様書無しさん:04/02/23 02:02
>>564
JavaやC#ならリフレクション使うとか、最初からパッケージスコープで定義するとか。

568 :仕様書無しさん:04/02/23 03:21
>最初からパッケージスコープで定義する
それは(w

569 :仕様書無しさん:04/02/23 11:16
>>564
a. もともとpublicなメソッドの一部を抽出して作るprivateメソッド
 →元のpublicメソッドのテストでおけ。
  (抽出後のprivateメソッド単独でテストはしない)

b. 最初からprivateメソッドで作成
 →???なぜ
  そんな状況が思い浮かばないが、だったら別クラスのpublicメソッドにする。


570 :仕様書無しさん:04/02/23 23:15
>>569
全くその通り。

だから実装ありきの人とは話が合わないし、説明しても無駄。

571 :仕様書無しさん:04/02/24 00:43
privateメソッドをテストするときは、
対象クラスを継承して、そこでテストクラスを friend 宣言しておけばいい。


572 :仕様書無しさん:04/02/24 02:28
そう言えば、思い出したけど

573 :仕様書無しさん:04/02/24 07:49
>>571
そんなめんどくさいことやってんの?

574 :仕様書無しさん:04/02/25 00:20
>>569-570
その感覚ってTDDやらないと身に付かないよね。

privateメソッドはクラスの外には、それが存在することすら保証しないし、
いつ無くなったとしても仕様の範囲内。
そしてprivateメソッドをテストしなければいけない規模になったとしたら、
クラス分割に既に失敗していると見なすべきだし、それでも例外的な理由で
クラス分割が不可能であるなら、リフレクションや571、プリプロセッサによる
置換等の例外的な方法を使ってテストするべきだろう。


575 :仕様書無しさん:04/02/25 01:47
>>574
ふむふむ。試験設計時にもクラス設計の妥当性が検証できるってか。
#でもそれって・・・

576 :仕様書無しさん:04/02/25 07:37
>574
テスト駆動っていうより、抽象データ型ってものを理解できれば、感覚はわかるんじゃないかなあ

577 :仕様書無しさん:04/02/27 18:22
>>564
> (557ではないが)
> どうやってprivateメソッドをテストしますか?
> publicにしてテスト?

それなら、もー大丈夫!
JUnitの代わりにJUnitxというのがありますぞ!

これでprivateメソッドもテストできるゥ!

578 :仕様書無しさん:04/02/27 18:22
http://www.extreme-java.de/junitx/

579 :仕様書無しさん:04/02/27 20:19
Java以外は?

580 :仕様書無しさん:04/02/27 22:15
じう゛んで作れ


Javaから移植するなんぞ朝飯前だろ(ワラ

581 :仕様書無しさん:04/02/28 00:55
TDDからみということでDbUnitの話なんですが、なかなか便利ですねこれ。
ただ、そのままだとコネクションの取得とか、
テスト用データのセットやアサージョン用データの取得とかちょっと面倒なので、
DbUnitのテストケースを継承した独自のテストケースを作りそこに任せるようにしました。
だいたいいつぞやのWeb+DB PressだったかJava Pressだったかのパクリですが。
他のプログラマにも使ってもらっていますが、
「テストデータの管理を気にしなくてよくなった」とおおむね好評です。

ただ、私自身の政治力の問題もあり開発手法全体としてはウォータフォールなので、
TDDを実践しようとするとそのギャップに悩みます。ISO9001のプロセスも原因の一つですが。
リファクタリングしようとするとやれドキュメントの修正だの修正レビューだのって感じで。
幸い担当するサブシステムの設計者とプログラマが私一人なので、
こっそりリファクタリングしまくってます。完全に黙認状態。
他のサブシステムはメソッド1個追加するたびにドキュメント修正して手面倒そう。

また、プロジェクトマネージャはコードでテストするという概念になじみがないせいか、
「手順が増えるのは他のプログラマにとって負担ではないか」とか
「プログラミングを終わらせてはやくテスト行程に移ってくれ」とか言うんですよね。
テストケースを残すのって大事なんですが。

「テストの実施記録がコードとして残る」
「テストの実行が簡単になるので、2次開発以降で楽ができる」
という理由を挙げて納得してもらったんですが、なかなか私が思う程度には納得してもらえないです。

そうそう、DbUnit導入以前はテストデータはテスト専用のデータベースに残してました。
このデータ、機能テストで内容変わったり手違いで消えてしまったりと散々でしたが、
DbUnitのおかげでこういうこともなくなりハッピーです。来年度以降は楽ができそう( ´∀`)
以上、長文スマソ

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)