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

いまどき滝モデル使うプロジェクトは負け組み

エクストリームプログラミング(eXtreme Programming = XP)
http://objectclub.esm.co.jp/eXtremeProgramming/

また死滅スレか

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

キゴ猫でわかるXP
http://objectclub.esm.co.jp/eXtremeProgramming/angya/dorama/gikonekoXP_all.pdf

>1にあてはまるのはどれかな〜

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

>>4
万能薬（銀の弾丸）は無い。
ゲーム開発だと、XPでない他の方法論が必要だと思う。

ウォーターフォールモデルって今まで３０年間ほど誤解され続けている。
って知っているかな？

>>8
おまえがな

伝説のアイテム「銀の弾丸」は見つかりませんでした。
でも代わりに、「銀のやっとこ」を入手しました。
定時に帰れて今の私は幸せです。

>>8
詳細きぼんぬ。

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

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

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

>>11
きっと、XとPの間に小文字のoが入ってるに違いない(w
http://www.geocities.co.jp/Technopolis/8931/index24.html

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

6項目を思いつく思いつく>>6が>>6の6項目に全て当てはまりますね。
どうやら抵抗勢力はXPだけを目の敵にしてウォータフォールモデルとXP
以外は目に入らないようだw

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

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

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

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

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

後戻りができなければウォータフォールモデルとは
言わないよな？

自動テストとリファクタリングがあれば、
あとは、
まあ、
いいや。

後戻りを許さない奴を叩いてやりたい。

予算無いからおまえ一人で何とかしろといわれたらどうするンよ。

もちろん予算を優先する。
が、時間が余れば自分のできる範囲で予算がかからない後戻りを提案、実践してみる。

既存の過去の資産には後戻りを適用することは
まず考えず。

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

いずれにせよ「後戻り」はするべきでは無いと思うんだが。

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

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

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

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

>>22
うーん、君は他のレスでも見かけるがちょっとずれているぞ。
ＷＦの最大の問題は設計フェーズが正しく終わらないままに
開発フェーズを始めてしまうことではないぞ。

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

ようするにやり直しに名前を付けてかっこよく言っただけだろ？

コテハンで書き込みまくった甲斐があった。ちょっと嬉しい。
よろしくお願いします。

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

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

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

>>25
うーん、言葉の定義に入ってしまうとそうなんだが、
結局の所何を望んでいるのか？ということを、定義出来る人は
少ないって事なんだな。

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

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

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

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

大規模の場合は、基本設計まではWFでしかできないだろ？
で、各機能分解できた段階からスパイラルしてパーツを構築。
結合フェーズからはまたWF。

XPって携帯電話の開発とか組み込み系向きだと思うよ。
テストツールなんて、DB絡む業務系だと今一有効性にかける。（DB込みのテストツールは知ってるけど。）

>>26-27
話の大筋が出来てきた。

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

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

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

>>30
それは、根底の価値観が人月だからでは？
成果物に対する評価で対価が決まれば、効率よく作業をした人が評価されるっしょ。

本当にわかんないんだけどさ。

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

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

顧客自体がＸＰに賛同して、部分予算、部分納品を認めるなら分かるが。
まずありえない。
ＳＥの自分としては、極力「必要最小限から」を勧めはするものの、
最終的にはどの範囲で納品とするかは顧客の希望次第。
その範囲が決まったなら、その範囲内においては責任を持ってＷＦでやるしかない。
その範囲内の中身を、勝手にＸＰでやるのはＳＥの逃げだ。

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

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

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

やっぱウォーターフォールでしょ。
XPはできる人がやるの！おれのID・・・

ダメな奴は何使ってもだめ

http://www.mars.dti.ne.jp/~hirok/xp/col/013.html

漏れ的には、
お客が鈴木宗男だったり、相方が鈴木宗男だったりする場合は、
ＸＰはやりたくない。
というか、漏れの隣に座ってる馬鹿が鈴木宗男的で、もう、鬱。

>>38
超ウォーターフォールならダメな奴でも
いっぱしの作業員として使える。

>>41
いっぱしはムリ。　熱心なバカほど始末に追えないものはない。

>>36
「デブは例外なく無能」スレに書こうかと思ったけど、うちには
「最近の方法論では８時間以上働いたらいけないことになってる。
俺達は働きすぎだ」とうるさい豚がいたな

>>40
「あのですね、私はですね、ちょっと言わせてもらいたい…」
が口癖とか？

まあ滝を軽やかに泳ぐ俺サマはXPも完璧にこなせるわけだが。

ＸＰの見積もりってどうなってんの？
作りながら客に見せて詳細要望聞くんだよね。
先に見積もりってできるの？

>>46
私が思うに、受託形式では見積不能。

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

>>46
実績ベースで貰うしかないかなあ。
四半期毎に、XX人月かけましたから○○円ですって。

>>48
んー、それじゃ期限が無いのと同じじゃあ？
自分達はミスって時間が掛かっても、人月分の金は貰えるが、
客にしてみれば、時間は掛かるわ金は掛かるわでキレるだろう。

逆ウォータはしょっちゅうある。
最後に外部仕様作ったりとか。

>>50
そりゃー危険だね。外部だけは先に客先承認印もらわんと。
タチの悪いのに当たったらどこまでも吸い取られる。

>>50
それを整理体系化したのがＸＰ（ｗ
ソフトは完成しない！なんつって。

>>52
一理ある。
「ソフトに完成は無く、リリースがあるだけ」は大昔からの格言だったし。

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

おまいら・・・
まずは本でも読んでからにしろ。
何も知らなさ杉だ。

IT業界にアージャイル開発とデザインパターンを広めよう！

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

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

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

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

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

>>56
じゃあためしに、広まるように内容の紹介してよ。
「ここ嫁」はなしだよ。それじゃ広まらない。

>>54
ってことは結局、発注元が人月単位で丸抱えするってこと？
それじゃ話にならんわな。
双方に旨みがない。
発注側　：　予算の確定ができない。
　　　　　　受注側の言い値になるから、サボっていても文句を言えない。
受注側　：　人月レベルの儲けしかない。

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

red/green/refactor--the TDD mantra

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

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

>>61
「半年前までに費用と検収時期が固まっていなければならない」というならば、
顧客側はスコープとプライオリティを調整（譲歩）しなければならないね。
当然だな。

　ハ　ゲ　シ　ク　ワ　ラ　タ

http://www.ne.jp/asahi/e/yamane/software/engineering/xp/daiary/xp_process2.html
# プログラマの見積りに対して、顧客は変更を要求してはいけないということです。
# ストーリーにかかる工数を見積もる権利はプログラマにあり、顧客にはありません。
〜
# 工数を強引に縮めても、プログラマのモチベーションの減退を助長するだけであり、

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

>>63
説明するよ。
「工数見積りは担当者のものが一番精度が高い」
ってのは工学全般の大昔からの常識だもん。
＞やっかいなのが自社の社長
転社したら？

>>64
説明するよと銘打ったわりには…
キミは、サービス残業取り締まりを強化するという共産党に入れた上でそれを言ってるのか？

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

>>66
じゃあ単に世情の分かってないアホってことか。

>>67
そうかもね。
で、あんたは人をアホ呼ばわりする以外に何ができるんだ

>>68
「で、」って何だよ、「で、」って

結論としては、狼男を撃つ銀の弾丸は無いので、XPだろうが何だろうが
お前ら明日からもデスマですよってことで良いのかな？

>>70
おうよ！
銅だか鉛だか知らんがとりあえず撃ちまくるだけ！

>>70 いーわきゃねーだろ
XPは、適切に使えばデスマにはならないという実績を踏まえての手法／方法論だ。
「この適切が何か」が議論の焦点だが。

どんな方法論でも適切に使えばデスマーチにはならないけどな

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

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

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

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

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

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

>>70
んじゃ、お前は狼に食い殺されてくださいね

>>74
おまいさんの発言の元は>>46でいいんだよね?

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

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

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

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

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

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

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

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

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

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

狼なら銀の弾丸は要らない、ふつうのフルメタルジャケットで充分だ

>>73
このスレッドにいる厨房にはそれが分からんのです。

>>76

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

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

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

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

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

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

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


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

>>77
ところがどっこい、
XP否定論者でかつウォーターフォール信者は
フルメタルジャケットも装備できないのです。

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

まあウォーターフォールは死滅したわけだが

>>79
物事をゆがんだ方向に捉え考え方が偏って短絡的だね。

むしろXPこそ竹やりだと思うが。
ただしいXPユーザは戦う相手を選ぶ術は知っている。
>80みたいなソフトウェア工学の基礎も知らない奴は別として。

>>83
なんだただの釣りか。
釣りで無いとしたら
XPを竹やりレベルといっている奴がソフトウェア工学を
理解してるつもりになっていること自体笑える。

>>83
ウォータフォールが竹やりであることを認めたくないなら
もう引き返すことができない特攻隊とでも言ってやろうか？w

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

>>79
> ってことで、その会社で暇な人が見積もるってことでイイか？

よくない。

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

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

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

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

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

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

>>87
さて。ここで問題です。
ＸＰ的考えの見積もりだとどっぷりと顧客要望を分析する必要があります。
見積もり精度、プロジェクトの大きさにもよりますが、1ｗぐらいの
工数が必要でしょう。
（梨がどの程度のプロジェクトやってるかしらんが、私の平均がこのぐらい）
さて。
見積もりから受注につながる可能性。
それはだいたい１〜３割ぐらいでしょう。
そのぐらい低いのです。
まぁ、一番高い３割の確率として。
１個の仕事を取るためには3.3個の見積もりをしなければなりません。
時間でいうと３．３Ｗです。
さて、これはあなたが言うところの
＞見積もりに対して時間を貰えないからだと思う。
というレベルの話でしょうか？


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

>>88
どうい。CMMを持ちだすつもりはないけど、レベルの低すぎる開発組織が大杉。
「金と時間をかけるべきところ」が判断できない香具師が大杉

XPってそういう見積〜受注のやり方を推奨してる訳でわないと思う

>>89
XPの話じゃなくなってきてるぞ。
XPは見積もりに一週間も使わないので。

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

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

>>91
世の中の商習慣に則った話をしましょう。
理想の世界の話をしてもしゃあないだろ。

>>76
> 漏れも建て替える家が途中まで出来てる所に入って家具の配置イメージとかしたし、

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

>>94
作れるなら作ってほしかったけど、XPじゃなかったから、無理だって言われたよ。w

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

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

>>96
あぁ。なるほど。
これは、理想境でのＸＰの適用のスレであって
実世界には関係ないってことだね。
そりゃ失礼。

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

>>97
> >>96
> あぁ。なるほど。
> これは、理想境でのＸＰの適用のスレであって
> 実世界には関係ないってことだね。
お前はオープンソースが幻想だと抜かしている馬鹿か。
M$厨と同じように扱われ恥をかくぞ。

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

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

オープンソース
http://www.geocities.co.jp/SiliconValley/5634/t82A8_0003.html#353

オープンソースソフトウェアのビジネスモデルの大きな勘違いは、
ソフトウェアを作って稼ぐことではないということだ。

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

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

XPって個人の才覚に依存しすぎると思うんだがどうでしょうか？

>>100
ほう。ではIBMは大損をしているわけか。

オープンソースは関係ないでしょ。。

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

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

ソフトで儲からないから丸投げで大儲けしてるのだろ？

>>100はM$に逆らえない頭が固いウォータフォール信者の頑固ジジイ

馬鹿はXPは愚かオープンソースビジネスまで否定しているのでした。

>101
ある程度のレベルを要求される事は確かだけど、個人に依存とは言えないっしょ。
少なくともﾍﾟｱﾌﾟﾛによって技術の伝播を推奨している訳だし。

>>107
ペアプロの欠点は、電波が２人組んで共鳴したときだと思うが。ｗ

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

似たような論議が前のXPｽﾚでもあったな。
「新人を二人組ませても生産性が上がるとは思えない」って。
思えないっていうか、当然だろうと。

>>110 当然というか絶対というべきか。正論だな。

>>110
何ができるか楽しみではある。

>>110
どうせ独りでも生産性は上がらないｗ
XPってPGが無能者ではないという前提でしょ。

たかがライカンスロープ一匹に何をてこずっている？
さっさと頭部を消し飛ばせ。再生する前に焼却しろ。
塵は塵に。灰は灰に。それが化物共の唯一の末路だ。

>>114
お前も早くチリにｶｴﾚ。

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

>>113
そしてSEが無能という前提。

Excise the bug. Before reproduction, Write test for it and refactoring it.

-- How to kill lycanthrope <Nevinyrral>

結論としては、狼男を撃つ銀の弾丸は無いので、XPだろうが何だろうが
お前ら明日からもデスマですよってことで良いのかな？

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

>>119
>>75

このスレで、ＸＰマンセー　っと言ってる香具師って
キーワードを並べるだけで実のあること言ってないよな。
まぁ、聞きかじったカッコよさそうな言葉を理解も
せずに書いてるってのがバレバレで微笑ましいのだが。

>>122
現場で遭遇するとウザくてしょうがない。

うぉーたーふぉーる信者よかはましですけどよ

>>124
あなたはどういう現場で、どういう立場の人で、
なぜウォーターフォールを嫌うのですか？

>>125
入社２〜３年目の現場経験の薄いベンダーのSEで
最近XPを齧ってしまった頭でっかち。

XPは残業禁止ですよ

>>127
そんなことないよ

XPは夢精禁止ですよ

なんでおまいらはウォーターフォールとXPを同列に語れるんだ？

滝の下流でやってるファーストプログラミングでは
中国にもはや勝てません(人月ですよ)

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

>>131
XPのどこがスローだ？
滝に流されるか、鳴門の渦潮に巻かれるかの違いだと思うけど。

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

まあどんな方法論を採用してもカスには意味ないねー。
１にも２にも個人のスキルだろ。

まぁそうだな。

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

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

>>134
そうでもないよ。

>>135
解説ｷﾎﾞﾝ

>>136
つっこみどころが多すぎて解説不能。

>>137
じゃあ、一個でもいいから自分の言葉で突っ込んでみそ。

>>138
なんのために？

>>139=135
ようするにあなたは「つっこみどころが多すぎて解説不能」
ではなくもともと解説不能ということですね。
もう少し勉強しないと一生コーダのままでつよ？

>>140
ﾔﾚﾔﾚ

141の負けだな

>>134
XPはそんな想定はしていないよ。

>>143
どういう想定か解説きぼぉ〜んｗ

>>143
だとすると、外注を何社も使うようなプロジェクトにも
XPは適用できるってこと？

>>144
本よめ、知障

>>145
ﾔﾚﾔﾚ

>>146
結局、解説できる人は一人もいないのですな。
コーダは所詮そのレベルでつな。

俺様に文句を付けようなどとは百年早い

>>149
俺を何様だと思ってるんだ？　俺様だぞ！

お前らのいるようなヘタれな職場じゃ、XPだろうがWFだろうがうまく
いかねーだろ。結局デスマになるんだからなｗ

>>134
総論を支持する。

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

ウォータフォールは死滅！これからはRational Unified Processで決まり！

>>153　おまえ、俺を煽っているな。

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

あ、「商習慣」は　>>152　の発言でした。
スマソ。

>>153
RUP 重すぎ。

>>155
日本以外は
「最初から開発の総予算が決まっている契約」
が少ないのか？

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

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

>>159
> XPで組んだとしても例えば、二人して徹夜して

その時点で XP ではない。

いまのところ、XPが適用できるのって組み込み系、携帯の開発なんかだけだと思うけど。

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

>>161
すまん。
携帯のようなとんでもない規模で、仕様の統一性、
エラーケースの内容等、とんでもなく厳しいシステム
においてＸＰをどのように適用できるのか教えてくれ。
適用事例があるのか？
マジレス希望。

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

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

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

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

まず、携帯って本体側開発ってことでいいんだよね。
そうならば、とんでもない規模ではないだろ？
I/Fが明確でClosedなシステムなんだから、XPの適用ってしやすいと思うが。

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

>165
もしかして「マばん」って読んでる??

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

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

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

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

>>168
「マばん」と読んでいったい何の問題があるというのだろう、この馬鹿は。

１兆円・・・・まぁ、漏れらのごめんなさいとはレベルが違うということで（ｒｙ
不治痛もみかかもいきなり今みたいな巨大企業になった訳じゃないし、とりあず、
最初はＸＰとかでちまちまやってて、その内の１つが大きく育てばいいではないか。
とまとめてみた。オヤヂくせー

>>170
そんな事実は無い。

>>173は不治痛の社員

>>171
最近の世界情勢や世界経済をかんがみるという立場からは、諸般の問題があるのでしょう。

じゃあ、DoCoMoのCORBA基盤についてでも語ろうか。

>165は相手がプロと見て逃げ出したのだろうか

>>175
板と版の単なる誤字から、そんなレスをつけられるとは。ただものではないな。

にちゃんねらなら「いた」だろ「いた」!!

ババンガバンバンバン
あ〜それそれ！

>>177
165??
相手を間違えてませんか？

　 マ　 ぼ　 ー　 ど
　programmer board と読んでいます。




　い け ま せ ん か ？

>>182
久美、そんなこといけないと思う。

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

>>184
しかしアルファ宇宙域ではマ板（まばん）という呼称がすでに定着しつつ
ありますし、カーデシア星系の評議会の結論待ちということで。

ロミュラン帝国ではどうなんですか？

ロミュラン帝国では"まきはん"（マ木反）と読んでいます。

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

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

デスマなんかしていませんが何か？

毎日遅く出勤して帰りは定時ですが何か？

>>190
それはそれで問題が...。
会社傾いてない？

という脳内妄想なわけですが何か？

>>192
ﾌﾟ　能無しの脳内ですかｗ

お前ら奴隷は、文句を言わずに働くのが仕事やろ？

>>187
武器の密売はよくないとおもう。

WFでうまくいってりゃ新しい方法論なぞ出てこないだろうよ。
しかしWFしか知らん人間を説得するのは至難だ。
世代交代が起こるだけの時間がかかるかもシレンな。

計画性のない計画と、無計画ではどっちもどっちだな。
所詮は計画性のある計画をするしかない。

計画を立てて実現できなければ、
それは無計画だったようなものさ。

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

寧ろ最悪。寧ろ罪悪。

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

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

つまり、まずはWF開発によるデスマで顧客＆PMの思考能力を奪い、その隙に自分好みのｵｻﾚな開発手法をねじ込むという戦略でつね。

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

ＷＦだろうがＸＰだろうが
ＰＧは救われないよ

この業界だけだぜ？
こんなぐらだないことで議論できるのって。
そうでもないか・・

例えば建築業界と違って成果が目に見えないからな。

お前ら奴隷は、文句を言わずに働くのが仕事やろ？

えっくすぴ〜〜〜〜〜〜〜えっくすぴ〜〜〜〜〜〜〜
ヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノ
ヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノ
ヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノ
ヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノヾ（＠゜▽゜＠）ノ

WF…仕様変更で大戻りする孤独なデスマ
XP…仕様を小出しにされてペアでもめながらデスマ

WF…たまにデスマ
XP…常にデスマ

WF…よくあるデスマ
XP…まだ未経験のデスマ

WF…デスマになるのがプロジェクト中にわかる
XP…デスマになるのがプロジェクト開始前からわかる

結局デスマかよ

WF…見事なデスマ
XP…悲惨なデスマ

WF…伝統的なデスマ
XP…先進的なデスマ

WF…赤い糸のデスマ
XP…出会い系のデスマ

結局デスマ。
何気に真理

判ってないな、行進の行き先が一方向か循環か、それだけの違いだ。

ウォータフォールは死滅！これからはRational Unified Processで決まり！

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

あらゆる手法をきちんと知った上でデスマ

デザインパターンぐらいアタマいれとけよ！　オメーら！

がむしゃらにコード組んでんじゃねぇよ！

>>217
されど温故知新に固執しすぎるのも発展性が望めず

温故知糞

>>221
知新の部分は？
温故知新って言葉の意味をきちんと理解してるか？

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

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

>>224
そういうことを言う人に限って、まとめて体系立てが出来ないんだよね。ｗ
あんなの簡単だよとかって後だしでいっちゃうのって結構恥ずかしい。
こういうことはある意味やったもん勝ち。

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

>>255
えっ!? やって、勝ったの?

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

どう考えてもおかしい。
ＷＦの方が、ＸＰの目指さんとする仕様修正をもっと高速にできる。
なにしろ実装しないで紙の上で次々にソフトを修正して見せるんだから。
そして全部紙の上で修正し終わってから実装した方が、
実装も総合的に捉えて計画的にできる。
いわゆるＩＴバブル系の詐欺事件とみた。

実父ならまだいいじゃないか
私は義父に見られたぞ。
お風呂あがろうとドア開けたら、義父がちょうど洗面所に入ってきた。
義母に激しく叱られてたけど

>>229
あなたにとっては、机上の空論のほうが現実なんですね。
処置無しです。

>>229
そんなあなたにはRational Unified Processがお勧めです(w

WFの場合：
　仕様がなかなか決まらず、最終的にはっきりしたのが納期の
1週間前。結局デスマーチに。

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

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

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

WF は客の要求が変わらないのが前提。
XP は客の要求が変わるのが前提。
チームは 180 度でも 270 度でもまるっとすりっとごりっとアジャイルに方向転換できる。
どこで終えるかもクライアントが決める。

>>228
ひょっとしてここ数日、誤爆しまくってる？
ツール変えた？

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

>>235
騙されてるよ。
ＷＦは紙の上でいくらでも要求変えていいんだよ。
要求の変化のたびにコーディングして見せ、コーディングし直すのと、
要求の変化のたびに資料を作って見せ、資料を作り直すのと、
どっちが早いかといったら圧倒的に後者だよ。

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

WFとXPを比較していると戦略と戦術を比較しているような感じがする

>>240
どっちも戦術じゃん。

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

>>241
そう？
長い期間で見たらWFだけど短い期間で見ると開発の現場ではXPですすめてる、とか。

>>243
逆じゃないか？「今回はこの範囲にして、これは次期バージョンに回しましょう」
で、今期バージョンの中に関してはＷＦ。長期がＸＰ的で、短期がＷＦ。
その短期が１〜２週間というふざけたものがＸＰ。
その短期を数ヶ月という期間にするとＷＦと言われるものになる。

>>244
逆でもその逆でもない。
つーかネタか？

そんな事はどうでもいいからとにかくコード書け!!

何か最近アジャイルとかXPに関する本が多いな。
中身は見てないが、本当に精通した人が書いたのか疑わしい目で見てしまう。

× アジャイル
○ アジル

>>248
× アジャイル
× アジル
○ アジャ

ＸＰにしろＡｇｉｌｅにしろ、日本語の響きとしてはいまいちだ・・・

>>248
×アジル
○あぁ〜ん汁

…。

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

武富士よりひどいという噂の会社
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

× アジャイル
○ アルジャジーラ

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

以上。ダメな奴のいいわけでした。

XPって何?

>>257 キシリトール配合のガムのことだろ

アージャイル開発もできない愚か者には死を！
http://pc.2ch.net/test/read.cgi/prog/1070781553/

>いくつかの会社が関係するからウォーターフォールで進めるのが一番
>いくつかの会社が関係するからウォーターフォールで進めるのが一番
>いくつかの会社が関係するからウォーターフォールで進めるのが一番

>>255
> ビジネスは契約をともなって遂行されるものだし

XP ってもろそうじゃん。

オブジェクト指向でいうクラスとはプログラマ間の契約を定義するためにあるのだが。

>>262
261 への返事？
XP は顧客が次のイテレーションを決めるから、契約を伴わずにどんどん進んでいくことはない。

オブジェクト指向とは契約を定義するためにある。
契約なくしてオブジェクト指向は語れない。

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

>>264って如何にも読み齧り、誰かの受け売りだよな。
ぜっっっっっったい自分では実務をやったことの無い、メーカーの新卒SE。

>>264
ここでいう契約とは、顧客と開発者との契約のこと。
それに、XP は必ずオブジェクト指向でやるものとあなたは誤解している。

>>264
顧客が次のイテレーションのクラス設計をするわけではない。ストーリーとタスクを
開発者とともに決めるだけ。それが契約。

実際さ、とりあえずXPって自社開発にしか適用できないよ。
自社主導で社員か契約社員なら普通にできる。

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

>>268
そんな顧客は切って捨てればいい。
理解あるお客だけと仕事をすればいい。

おまいらオブジェクト指向のことを勉強したとき「契約」という言葉をマジで聞いたことがないのか？

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

>>270
バカだなあ。ここでは契約による設計の話をしているんじゃなくて、
顧客との契約の話をしているんだよ。
それに、契約による設計は構造化プログラミングでもやんなきゃだめでし。

>>270

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

s/>>255/>>261/ ｽﾏｿ

XP では契約による設計は、テスト・ファーストによるユニット・テストで保証している。

>>269
その種の発注能力がある客はそんなに多くないと思うけど

>>275
勘を信じるな。君が見るべきものはデータだけだ。

あ、つまりビジネスロジック上での契約の話か。そうかそうか。

>269 そんな顧客は切って捨てればいい。

こいつはナニモノだ？

ワイアドロジック

>>278
269の言うとおり、付き合いたくない顧客とは仕事はしない方がいいよ。

でも営業部長が許可してくれない

XP適用を言ってる割には根性がねーよな。
客を教育するぐらいの勢いみせろよ。逃げるだけの負け犬。

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

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

>>283
無料で云々というのは、それを言ったら営業活動が成り立たなくなるよ。
２行目からはいいたいことはわかる。

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

客はね、手法はＸＰでやりたいの。ＸＰの方が打合せ楽だから。
触ってから思いつきで文句言えばいいんだから。頭使わなくていいの。
でも支払いはＷＦで固定したいの。そのためにＷＦの難解な打合せに付き合うの。

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

なんつうか、引きこもりの論理だな。ｗ
自分を理解してくれる人としか付き合えない。

>>287
商売の下手な人が、お客様を神様に祭り上げて、誰とでも取引しないと
儲からないからだね。

うんうん。嫌な客でも呼ばれれば尻尾を振って飛んでいく業者。よくいるよね。
それで儲かっているかといえばそうでもない。

嫌な客、やだよ。くたびれるだけ。
同じ儲けるなら優良顧客の仕事しか受けない。

なんつうか、図星だった？必死だな。

優良顧客と不良顧客ができてしまうのは、SEが無能なんだ罠。
客側にもSEに相当する人間がいないとできないようでは、下請けしかできん罠。

お客を切れば切るほど儲かるのは確かだ。

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

>>294
そんなのに構っていると経営資源のムダだな。

>>287
商売なんだから、ひきこもりだろうとなんだろうと、儲からなくちゃ意味がない。

>>296
まあ、あんたがそういうんならそうでいいんじゃないの？
その主張が何処でも通じるか疑問だけどね。

>>294
その場合切るっつーか、見積が合わず普通にお流れになるだけでは？

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

要は
「この先もずっとウォーターフォールでいい人手ぇ挙げて!!」
って事だろ?

>>299
それって核心を突いてる。
変化を抱擁せよ

変化ってｗ
Windowsのように変わりまくるのがいいとでも思っているのかｗ

>>294
おいお前。これは「ルールを守らない」以外はいけいれても良いだろ。
その顧客がそれなりに金をだしてくれるならな。

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


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

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

>>301
>>2の先のサイトをよく見よ。
その標語がすぐに目に入る。

XPでいう「変化ヲ擁護セヨ」とはWindowsのような変化ではなく。
「簡単に変化させやすものヲ擁護セヨ」に近い。
すなわち「オブジェクト指向ヲ擁護セヨ」だ。

> なぜならオブジェクト指向を無視したAPIが多く、拡張性が低く変化に耐えにくいAPIが多いからだ。
具体的な例を身って見ろよｗ

実際に使って見れ。Javaには適わない。

なんだ。やっぱり具体例を出せないのか。

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

>>309
交渉能力にたけていりゃそんなことイワネ。

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


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

>>308
とりあえずファイルI/O関係とでもいっておこう
あとは自分で調べろ。教えて厨房君(w

>>310
あとで関係が問題になるようなお客は断るね。
関わらない方がいい。

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

あぼーん

>>313
おいおい、武富士みたいなのと一緒にするなよ

>>314
このスレに糞リンクを張るなこの餓鬼！

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

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

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

>>294に示されるようなどんなに嫌な客でもルールをしっかり守り法律も倫理もマナーを守る奴なら
仕事は引き受けろ。

まあ、それでも優先順位は自分でつけてもいいが。

プログラマってのは臆病者がそんなに多いものなのかと

>>317
おまえの言っていることは科学的根拠は無い。

>>321
科学的根拠の無い言い訳をするな

>>322
科学的根拠がないことを指摘されて逆切れかｗ

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

>>324
とりあえず、暗い夜道には気をつけとけよ。

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

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

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

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

>>327
文句言ってくれる人がいなくなると、進歩が無くなるんだよ。

>>328
そういうのはいるね。「クレイジー5%」と言う。
クレイジー5%の言うことは、たいてい至極もっともなことだからありがたく参考にはするが、
客としては切り捨てる。

お前らホモ。
平和ボケしすぎてホモになっているんだよ。お前らは自己防衛能力が低下しすぎて甘えすぎなんだよ。
今だに日本の治安は世界一を信じているのか(ﾜﾗ

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

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

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

なるほど。

>>327
文句をいってくれないと、だれも自分の欠点をいってくれず
あの技術者どもはつかえない。やつらにたのむのはやっぱりやめてほかの会社にしよう。

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

いい顧客がいるのになんでわざわざ茨の道を進むわけよ？
楽にたくさん金を儲ける人が偉いに決まってるじゃん。

>>332
文句を言ってくれないのと、文句を言わないのとは違う。
こっちの売り方が嫌な客とは契約しなければいい。こっちのやり方を気に入った
客とだけ仕事をすればいい。

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


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

>>333
いい顧客がもしいなかったら？
表面上のみいい顧客でも金蔓にもならず契約してから後で嫌な顧客だと発覚したら？

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

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

>>334
最初からそういえよw

>>336
作るか探すかほかの市場に切り替えればいいじゃん。
いまは、めまぐるしくいろいろな市場が成長し消えていくから、どれかにはある。

>>337
つまりお前は顧客の表面上のみを見て判断するDQNなわけだな。
氷山の一角のみを見て「氷山って小さいな」といっている馬鹿と同じだな。

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

>>339
そのほかの市場も感じよさそうないなかったら？
お前らはそういったことを想定していないだろ。
餓鬼の頃に教師に怒鳴られたり説教された経験がないだろ。
本当に忍耐力の無い奴だな。

>>341
もっと具体的にどうぞ

>>342
そういったやつは初めから起業に向いていない。

>>343
たとえばだなあ。「彼氏の見つけ方無料小冊子プレゼント！」とやれば、
彼氏のいる女は募集してこない。

>>341

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

>>344
なんだって？　顧客が起業に向いていないって？
>>342といっていることがかみ合ってないなあ(藁

>>345
徐々に言い訳に必死になってきたなw

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

もしお前らがアメリカ人だったら?
お前らすでにアメリカで射殺されているよ。

機嫌の悪そうな顧客を切るときは逆切れされないように気をつけよう。
逆切れしてあなたが殺されてしまいます。

>>346
バカだなあ、そんなこと言ってないよ。成約してからでも、契約書類上まずくなければ、
いつでも取引を停止する。

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

馬鹿というほうが馬鹿。

>>348

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

1. 説得しないでも、あなたの商品を「それ、ください」といってくれる。
2. 費用がかからず出会え、そして手間がかからない。
3. さらに、他の顧客を連れてきてくれる。

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

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

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

均質化は思考停止から生まれる。まわりの常識を疑わない。顧客からクレームが
来れば、それを受け入れ、社員から文句が来れば、それに従う。哲学がないから、
浮き草のように常識に流されていく。

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

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

>>353-354
趣旨がずれて必死だな。
そんな百も承知なことで自分の無知を隠そうったって無駄だよw

>>355
ほとんどの会社は、理想的な顧客の条件を詰めることもなければ、イメージする
こともない。理想的な顧客がイメージできなければ、アプローチできるはずがない。

>>355
なんでもかんでも契約取っちゃうほうが危ないよ。

確かにね。お客さんを切り捨てれば切り捨てるほど儲かるね。

>>357
嘘つくなよ。嫌な客でも契約取るんだろ。それが君の常識なんだろ。

>>360
それは、こちらの商品、サービスに、より熱狂的な顧客層がつくからだよ。
そういうのはリピーターになってますますファンになってくれる。

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

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

>>363
バカスパイラル、略してバカスパだな。

なんだかサラスパみたいだね。

なるほど。

狐と狸のバカかし合い.。

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

つうか、引き篭もりの自称SEか？
こんなに2chで必死なところを見ると、暇なんだな。ｗ

>>359
馬鹿か。優先順位をつけたうえでやっているんだが。
客がいなくなって収入源確保できなくなって
嫌な客しかいなくても取らないのか(w

日本の景気も徐々に衰退している。
いつまでも安全神話を鵜呑みにするのはそろそろやめたらどうだ？
現状維持ではこれ以上の景気回復は望めない。

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

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

ウォーターフォールかXPか（あるいは別の何か)っていう選択はどうでもいい。

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

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

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

>>375
あなたの考え方では他力本願で、パイの縮小を止められないよ。
受け持ち顧客を自分の好み基準で純化してるだけじゃん。

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

変化ヲ放尿セヨ

>>376
教育なんかに無駄な会社リソースを使うな。
教育にいくらかけるといくらになって戻ってくるんだ？？

>>371
USP がないからだよ。See >>354>>356

>>376
> 受け持ち顧客を自分の好み基準で純化してるだけじゃん。

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

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

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

二重ｶｷｺｽﾏｿ

>>371
> 嫌な客しかいなくても取らないのか(w

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

>>375
君の思っている「悪い顧客」の定義にもよるよ。

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

>>384
お前は何もわかっていない。お前は現実を見ていなさすぎ。
もしお前が飛行機事故でサハラ砂漠の中心に立たされたとき
お前はどうする？

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

>>382
自分の会社がその超勝ち組に常になれると思ったら大間違い。
勝ち組よりも負け組みのほうが多いのが資本主義の世界。
負け組みになったときに対する備えも必要だ。
地震対策をするようにだ。

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






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

勝負師のような厨房にはあきれる

>>387
だから USP を日々高めていく必要があるんだね。

セックスピーって何ですか？

>>386
サバイバルするよ。
あれね、袋を砂の上に置いとくと、飲み水できるよ。
金を増やすのなんか簡単だから、手元の金ぐらいどうってことない。
帰ったらまた増やせばいい。

>>386
コカコーラの自動販売機を探すよ。絶対あるよ。

大体金持ちって手元に大金持ってないだろ。
会社名義で証券や建物などとして管理しているんだよ。所有してるんじゃなくて。

金持ちは「自分名義の財産」ということで調べると、ほとんど貧乏人と
同じらしいね。税務署がきても。

大体、自分が海の上にいようと砂漠の真中にいようと、金持ちは勝手に
金が金を生んで、家に帰ったらもっと金が増えているようになってるんだよ。
生きて帰れればだけど。
せいぜい事故らないようにね。

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

俺も金持ちになりたいな。
俺は金持ちになった。

>>397
よかったね。うん、よかったね。

>>391
おいおい、何もないところでは金は何も役にたたんぞ。

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

>>386
電話する

なんかマジレスしてる人がいるよな、ここ…

>>399
> おいおい、何もないところでは金は何も役にたたんぞ。

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

>>402
>>399のサバイバルは大金がかかるらしい。

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

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

>>404
前半は日本語とは思えないが理解は出来た。
後半は「いい比喩をありがとう」とだけレスしておこう。

>>400
こいつ真性のｱﾌｫだな。
お前はすぐに即死だ。

出直して来い！

http://sports.2ch.net/test/read.cgi/kyozin/1062569486/l50

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

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

ウォータフォールで開発している方々へ質問
仕様凍結日付というのを設定していますか？

>>409
仕様は永遠に凍結されない。
完成したものが仕様だ。

>>406
馬鹿馬鹿しさに気がついた？冗談としてはいい出来だと思うけど。

レス遅くてごめんねー。

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

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

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

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

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

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

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

仕様が決まらなきゃ完成もありえないだろ・・・

>>413
どの程度の仕様変更かによる。
度が過ぎれば断ってもらうことは当然。

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

>>414
仕様は絶えず変わることを前提とする。
完成したと判断したときのものが仕様となる。

>>416
どこが、あるいは誰が「完成したと判断」するのか
を教えてくれ。

検収はどうすんの？

>>417
顧客（自社の場合は責任者）が製品として納得したら完成だろ？
だから受託形式では成り立たない。

>>414
そなたの考え方は
ウォータフォールモデル症候群がもたらした悪しき化石的思考だ。

>420
XPを歪んだ捕らえ方してるいい例だ。
仕様は絶えず変わるが、少なくともその時点での完成（仕様）を明確にせんでどうする。
君はメソッドを実装する前にテストケースを用意しないのか？

負けず嫌いが>>420のレスを勝手に脳内解釈してどうする。

>>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
とか。

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

まずどのレベルの「完成」を語ってるのかはっきりしてくれ。
メソッドの完成か。
機能の完成か。
システムの完成か。
仕事の完成か。

顧客にリリースすることをひとまず完成とすると、

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

>>426
全然理屈になっていない。
バグがあるものを売ることを前提としている時点で、感覚が麻痺している。

あほか。バグの全く無いソフトなどあると思ってんのかこのトンチンカン。

>>423
誤爆？　

ある程度以上の規模のソフトは、バグの存在が確認されていても、
（「出荷判定会議」とかを開いて）リリースされる場合もある。
これは事実

ウィンドウズを搭載した銀行ATMに初のウイルス／Hotwired Japan ��12月11日 17時20分

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

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

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

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

>>432
で？
その半端な状態で客はどうするの？
最初に予算決定があるわけだから。

>>430
ある程度以上の規模のソフトは、バグの存在が確認されていなくても、
バグは存在することが知られている。

>>434
確認されたバグの話をしているのに、確認されていないバグの話を持ち出すとはこれいかに

>>433
半端かどうかは客が判断するわけだから、

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

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

>>435
426では、「潜在的」といっているので、元々確認されていないバグの話だったのだよ。

>>436
では、ある仕事の依頼があって、概算を出せといわれた場合はどう対処するの？
また、それをオーバーした場合の責任の所在は客？

>>408
自販機のボタンを押すまでに悩む過程が設計フェーズ。
押してから出てくるまでが開発フェーズ。
という喩え。

>>426
何か勘違いしてないか？
機能拡張はごく普通に追加発注だよ。
改めて拡張部分の設計をし、確定し、開発するだけ。それがＷＦ。

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

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

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

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

それって所謂終わり無き仕様変更では？

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

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

>>438
開発プロセスとは何の関係もない話。
ウォータフォールはウォータフォールのプロセスに従って見積るし、
XPはXPのプロセスで見積る。
見積り結果が間違っている可能性が高い場合（対象が初めてやるものなら大抵間違う）は
見積り条件に含める。

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

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

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

>>443
人生とはそういうものだ。
勉強は終わらない。生涯学習あるのみ。

>>448
> 既存の開発からXPへの移行に伴うノウハウを聞きたい。

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

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

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

>>447
最終行に激しく同意。

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

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

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

シナリオ。
顧客「私は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ヶ月です」

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

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

梨って自分の日本語がおかしいことに気づいてるのかなぁ

>452
顧客「うーんもっと安くならないの？
営業「すみません、これでギリギリなんです
顧客「じゃあ値引きはいいからこっちの要望をもっと取り込んでよ
営業「わかりました！！

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

どうやらその様デスマ(あげ)

大丈夫です！
これがXpのメリットです。作りながら仕様を追加できるんですよ。
私が開発を上手いこと丸め込んでおきます。ご安心下さい。

>>457
虚露すよ。営業はだぁっとれ！

営業が打合せやってるような会社はそのうち力尽きて派遣会社に成り果てる。

ホントのデスマを知っていてここにいるヤツはいまはデスマとは無縁

『結論』

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

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

じゃ、つまりRUPを適用すればいいってわけね

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

アージャイル様に頼めばウォータフォールを破壊してくださる。

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

　　　　　　　　　　　「「「「ハイル！」」」」

おお！

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

cobolerはxpできまつか？

>>467
オブジェクト指向言語で無いと、テストやリファクタリングの実現方法の
関係で、XPするのは難しいそうです。

>>468
cobolerは逝くしかないようですね。

COBOL2000とかでなんとかかろうじて延命処置をとってXPのさわりがやっとできるといったところだろうか・・・

VBerはxpでき...そうで難しい

営業は喜ぶだろうな。

Delphierだけはxpできそうもないな。

大体どちらかの手法のみに傾倒するってのは、厨の証拠だよな。
良方式の良い部分を上手く抜き出して、程よくブレンドするのが、真のSEってもんだ。

>>473
できんじゃねえの？　オブジェクト指向言語だし

>>474
いっておくが
ウォータフォールの考え方はXPやRUPに包含されているぞ

エンタープライズの受託開発で実際にやってみたことある？

純粋にxpできるのは
java、c++、c#、delphiってこと？
そのほかは？

ちょっとまってくれ
>>468
＞オブジェクト指向言語で無いと、テストやリファクタリングの実現方法の
＞関係で、XPするのは難しい
ってのをもう少し説明してくれないか

まあ実際に難しいけどな。
XPやRUPはオブジェクト指向前提だし

ライフサイクルモデルの亜流なの？

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

COBOLはある意味Extremeだな。
WebアプリなんかだとCOBOLのCOMMAREAと大差ないけど・・・

>>478
D言語、Ruby, MixJuiceなども。

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

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

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

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

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

テストファーストなんていまどきはやんないよ

>>485
そうだな。今はTDDだ。

テスト駆動開発にはテストファーストが使われてる

ウォータフォールは死滅！

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


　　　ス　リ　ー　ア　ミ　ー　ゴ　ォ


　　　　　　　　　　　　　　　　　　　　の　時代！

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

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

>>487
TDDはテストファーストじゃないよ

テストは　つ　ね　に　ラストです。みんなそうだろ？

>>490
いや。俺は自分のコードを信用してないんで常に「書いたらすぐテスト」だよ。

>>489
レッドフェーズをテストファーストと言わないのか

>>492
言わない

http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020904/1/

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

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

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

>>494
プロテスタントとカトリックぐらい違う。

TDDはまずレッドフェーズで先にテストコードを書くやんけ。
んじゃテストファーストやね？

>>496
キリスト教以外の視点から見れば大してかわらんと思う。

キケー！

>>499 ↑
意味不明なアフォなレスだな

>>495
> その記事は間違っている。
> 理由を示せって、理由も糞も無い。違うんだから。

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

ウォータフォールはXPです。
違う？理由を示せよ。

XPのテストファーストは「テストをまず書き始める」ことではない。
TDDでは確かにテストをまず書くことからはじめるが、XPのそれとは違う。

わかったか、馬鹿共。

複数の方法論を提唱した香具師は今までいない。Kent Beckも例外ではないと思うが。
該当書籍を読め。

>>503
つまり、XPのテストファーストと、TDDは「テストをまず書き始める」ことは
共通してるということですね？
それ以外に共通点はありますか？

Test Firstを「テストファースト」と訳した奴が悪い。

>>505
xUnit推奨ってことくらいか。方法論としては全然違うものだ。

開発中に開発者自身がテストしながら作るのはあたりまえじゃないか。
なぬをいっておるのか。

>>508
そのあたりまえをきちんと方法論として確立したのがTDDだ。

TDD
・あえて失敗させる
・フェイク
・リファクタリング
の繰り返しでつ

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

テストファーストもわざと失敗させるよ。

>>510
そのまんまTestFirstですが、何か？

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

じゃあ説明するよ。

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

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

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

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

TDDて何の略？

Test Driven Development では？

なんか息苦しそうだな

>>502
それはRUPの間違いではなかろうか

>>504
ケントベックの書いたあの水色の本

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

>>505
どちらもレッドフェーズから始まる。

最後までレッドフェーズ・・・

テストファーストやりませうって提案したらそんなめんどくさい事やってられん
わﾎﾞｹｪって言われました。
普及の為のよい手段はないでしょうか

TDDをやってるとリファクタリングブラウザが必要だと痛感する....

WF…最後にデスマ
XP…最初からデスマ

WF…納期が来たら納品（バグあり）
XP…客があきらめたら納品

WF・・・直進の滑り台
XP・・・螺旋状の滑り台

WF・・・プロにしかできないので営業が嫌がる
XP・・・素人が昔からやってた危険なことを格好よく言い直しただけなので営業が喜ぶ

ところでなんでWF以外=XPなんでつか?
重量級 RUP
中間 FDD
とかクリスタルとかその他色々ありまつが?

じゃ、RUPスレやクリスタルマンセーすれとかをたててくれ

>>527
そこまでして必死にウォータフォールを弁護しなくても

いまだにWFなんてやってる会社は負け組

マ板に来てる営業も負け組

まあ、言葉だけでＸＰでとかいってる営業もおしまいだと思うがな。
お前は数年前はＩＴとかいって営業してたんだろ？
その前はダウンサイジングか？
で、その言葉を説明もできやしない。

スレタイを

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

にするべきだったな

RUP は重いよ。

80kgはあるからな。

そんなに重いのか。

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

>>538お前、何言ってんだ？
層化がいなくなると芸能界が成り立たないだろが！
芸能人の何割が層化だと思ってんだ、このヴぉｋ（ｒｙ

そうか。

ウォータフォールは創価のたまもの

>>541　ネタにマジレス
>>13
新しいものはたいがい米から入って来る。間違いも含めてね

新しいものって30年前の滝はもう新しくないわな

>>543
第二次大戦後からずっとそうだってことだ。
「最近覚えた新しいこと」はなんだ？

外形仕様とかWFというものはIBMが発明したそうだね。

ペアプロかなんだか知らないが、
ごちゃごちゃ喋りながら作業するんじゃねえよ。
それもくだらない内容で・・・

こんなのを見つけました。

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

>>546
くだらないかどうかはあんたが決めることじゃない。
幼稚園からやりなおせば？

>>546

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

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

いまだにウォータフォールモデルしかできない愚か者は即刻クビ
なら説得力あったかも

ﾊﾟﾁｮﾝｺﾝ組は楽しそうでいいな(´,_ゝ｀)

>>522
これは俺も知りたいなあ。

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

>>553
これはバグ入りそーだなー、と思った奴だけ書いてる。
流石に全部の関数に書くのは負担が…。

>>553
ユーザインターフェースって対人？ならそこはあきらめます(自動実行テストしません)

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

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

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

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

ちょっと違うな
下位の関数のテストを作ってから下位の関数を作るのさ
下位の関数が上位から呼ばれてるかどうかは気にしない
上位の関数のテストは下位の関数のことは気にしてない

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

>>556
きみはきみのやり方でやればいいさ。
なぜTDDがいいか説明するのめんどいし。

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

>>557
もまえはいわゆるプライベート関数までいちいちテストするのか？すごいな(w

>>560
さいしょに実装ありきの発想だね、それ。

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

>>560 >>561
TDDじゃ無くて単体テストするだろ。

× TDDじゃ無くて単体テストするだろ。
○ TDDじゃ無くても単体テストするだろ。

(557ではないが)
どうやってprivateメソッドをテストしますか？
publicにしてテスト？

>>564
テスト時にも絶対に変更してはいけないの？
そうだったらセルフテストメソッドを追加する。

>>565
>テスト時にも絶対に変更してはいけないの？
いやほら「本番向けコード」と「テスト向け」で違っちゃうから

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

>>564
JavaやC#ならリフレクション使うとか、最初からパッケージスコープで定義するとか。

>最初からパッケージスコープで定義する
それは(w

>>564
a. もともとpublicなメソッドの一部を抽出して作るprivateメソッド
　→元のpublicメソッドのテストでおけ。
　　(抽出後のprivateメソッド単独でテストはしない)

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

>>569
全くその通り。

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

privateメソッドをテストするときは、
対象クラスを継承して、そこでテストクラスを friend 宣言しておけばいい。

そう言えば、思い出したけど

>>571
そんなめんどくさいことやってんの？

>>569-570
その感覚ってTDDやらないと身に付かないよね。

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

>>574
ふむふむ。試験設計時にもクラス設計の妥当性が検証できるってか。
#でもそれって・・・

>574
テスト駆動っていうより、抽象データ型ってものを理解できれば、感覚はわかるんじゃないかなあ

>>564
> (557ではないが)
> どうやってprivateメソッドをテストしますか？
> publicにしてテスト？

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

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

http://www.extreme-java.de/junitx/

Java以外は?

じう゛んで作れ


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

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

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

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

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

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

　　　　　 　 　 　 　 ＼　　　 │　　　ＸＰ？ 　 　 .| ./　/(ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ?/
＿＿_　　 　 　 ＿＿_ .＼　　 |　　 　 　 　 　 　 　 |/　/(ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ?/　 /
|ｘｐ？| 　 　 　 |ｘｐ？|　　＼.└――──―──/　/(ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ?/　 /
￣∩( ﾟДﾟ ) 〃￣∩( ﾟДﾟ ）＼　　ヽ(ﾟДﾟ )ﾉ　　./　/(ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ?/　 /
　 ヾ.　　　　）　 　 ヾ.　　　　）　＼∧∧∧∧∧/　/(ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ? (ﾟДﾟ)ｘｐ?/　 /
　　｜ ｜　| 　 　 　│ │　|　 .＜　　　　　激 ＞.|￣￣￣￣￣￣￣￣￣￣￣￣|　 /
　　（＿_）＿）　　 　（＿_）＿）　＜　 　 Ｘ　し ＞.|　　　 (ﾟДﾟ)ｘｐ?　 最　中　　　.| ./
────────────＜ な　Ｐ　 く ＞────────────────
|o ゝ○ノ|　　　　　::／^'ヽヽ:::::::＜ 予　？　 　 ＞ ／　○ 　　＿　○＼　　 ／
.ヽ( )_,,ノ　　　　　 |ゝ○_ノ o|:::::＜ 感　　　　　 ＞（　　　　　 ││　　　）＜　　　＞＜　Ｐ　？
^''　　　　　`‐'　　 ヽ..,,_( )ノ　 ::l＜　!!　　　　　 ＞ ＼　　　　丿　| 　　／ 　 ＼
~~　　 （　/￣￣ヽ　　　 -‐‐‐--l-∨∨∨∨∨.　 ／　　　　￣￣　　 ＼　　　 ＼＿＿＿＿
　,,,,　| 　|||!|||i|||!| |　　　~^'‐..,,_/　 /. _＿＿＿.＼（　　　　　　　　　　　　）
（:::::｝|　:| |ll ll !! !.| |　　 ,,,,　 イ ~''/　 Ю）＿＿）　＼ 　　　　　　　　　 ／
. ~~　|　:|!! || ll|| !!:| |　｛:::::） ::l　./　　 | ﾟДﾟ.|　ｘｐ? . ＼ 　　　｜　　　 |(ﾟДﾟ） ｘｐ？
.　　　|　| ! 　　　　| l　 ~~　　l /　　　 ＾＾＾＾＾　 　 　 　 ＼.　　 ＼　 　 ＼⊂）
　　　　 `ー--― 'ノ　　　　　/　　　　　　　　　 　 　 　 　 ＼.　　 ）　　　 ） |

>>564
> (557ではないが)
> どうやってprivateメソッドをテストしますか？
> publicにしてテスト？

やっぱりJUnitX


JUnitXがあれば>>571みたいなことをしなくても済む。
というか>>571の例はfinalなクラスでは使えない。

JUnitXはリフレクションを使っているのだ。

新人へ
この手紙をもって、僕のＳＥとしての最後の仕事とする。
まず、本プロジェクトの病態を解明するために、Kent Beck氏に病理解剖をお願いしたい。
以下に、開発工程についての愚見を述べる。
大規模な開発工程を考える際、第一選択はあくまでウォーターフォールであるという考えは今も変わらない。
しかしながら、現実には僕自身の場合がそうであるように、仕様変更した時点でデスマーチや致命的バグをきたした進行症例がしばしば見受けられる。
その場合には、大量増員を含む全身治療が必要となるが、残念ながら、未だ満足のいく成果には至っていない。
この先生きのこれるかどうかは、エクストリームプログラミングの発展にかかっている。
僕は、君がその一翼を担える数少ない技術者であると信じている。
能力を持った者には、それを正しく行使する責務がある。
君にはソフトウェア業界の発展に挑んでもらいたい。
遠くない未来に、デスマーチが、この世からなくなることを信じている。
ひいては、本プロジェクトを病理解剖の後、君の研究材料の一石として役立てて欲しい。
屍は生ける師なり。
なお、自らＸＰの第一線にある者が早期発見できず、デスマーチによる過労で死すことを、心より恥じる。

プロジェクトリーダー

>先生きのこれる

きのこれる先生(age

XPを取り入れたところで、設計、画面デザイン専門要員として素人が混入してたらダメですね

要員に素人が混入するようなレベルのプロジェクトは須らくダメですね。

アシスタントとしてなら素人（というか未経験者）もＯＫですね。
経歴の長い素人はダメですね。

ＸＰだと契約が包括契約にせざるを得ない
（基本設計と実装を分けて発注できない）という欠点については
どう考えますか？

今の会社はまず基本設計を発注して基本設計書を作ってもらい、
それをもとに実装部分の発注を別にかけるという契約形態なのですが・・
そうでないとずるずると設計変更が起きてわけがわからなくなるからだそうです。

設計変更がどこから発生するって？

>>590

説明が悪かったですね。すみません。

XPをするってことはイテレーションごとに設計自体を変更するって
ことですよね？　ＸＰならばテストファーストその他デグレを防ぐ
方策があるのでしょうが、ウォーターフォール前提の契約規定なので
実装に入ってからは設計は変えないという方針なのです・・

設計も実装も下請けがやるんだよね
下請けが設計変更したがる？？？

>>592

設計変更というより、基本設計書自体が適当に作られて
実装時に何とかするというパターンを避けたいようです。
ドキュメントが未整備でコードを読まないとわからないという事態は
基本設計書をきちんと作っておけばある程度は防げますよね

よその会社が実装するようなものをまともに設計するわけねー

>>589
それが現実にうまく機能しているのであれば、今まで通りの方法で受注するべ
きなのでは？

よく聞く「XPは顧客が納得しないから非現実的」という批判は、暗黙のうちに
「従来のやり方で、(費用/期間/品質などに対して)顧客は十分に満足してきた」
という前提を置いているんだけど、まず最初に考えるべきは、この前提が本当に
成り立っているかだと思う。

間違いなくこの前提が成り立っていうのであれば、少なくてもその現場におい
ては、安易な理由（なんか流行っているらしいとか）で、うまくいっているや
りかたを変える必要はないし、むしろ考えるべきは、どうすれば今のうまくいっ
ているやりかたを維持できるかという点でしょう。

>>595

えっと・・　うちは発注側なんです。で、正直言って費用も期間も
品質は満足はしていません。

ただ、上の考えとして
「基本設計書をきっちり作らせないと今以上に設計が適当になるに
きまってる」
「SIerは信用できない。出来高払いで包括契約なんて論外」
というのが前提にあるような気がします。
だから
「SIerが進捗をわざと遅らせて少ない労力でお金だけ取ろうとする」
リスクがないことを説明できないと、仕様をイテレーション毎に詳細化していく
XPなんて無理なんですが・・

>>589
変化を抱擁せよ。だが、変化そのものの存在や価値を認めない人間は沢山いる。
他人の考え方や行動を変化させるのは、この世で最も困難な事項の一つだ。
諦めるか、変化するべく不断の努力を行うか（続けるか）の二者択一だ。

リスクがないことを説明できれば、変化するのだろうか。
答えがyesなら「馬鹿なことを言って申し訳なかった」とレスするが。

>>597

まぁ正直言って技術的には新しくても契約とか組織は古い会社なんで
システム開発だけ契約規定をかえるっていうのは難しい気もしますが..

ただ　↓
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FixedPrice
にもあるように、アジャイルとかXPってSIerも顧客も善人という
前提があるんではないかとちょっと思います。
実際にXPやってる人たちって発注側も受注側もどういう意識でいるのか
ちょっと知りたいですが。

「これからは、滝でなくRADだ、OOだ、スパイラルだ、プロトだ、Roseだ」
と言って、破綻したプロジェクトが大半。

採用技術に関わり無く、一定以上の規模のプロジェクトは、
建築でも何でも仕様確定が必須。

そうでないと業務要件同士だけでも、詳細化すると手戻り頻発して、
業務フローもデータストアも、そもそも決まらない泥沼化。

おれ、人にプログラミング画面見られてるとなぜかコーディングできなくなるさ。
きっと根っからのカプセル化人間なんだな。

http://www.shayashi.jp/nistep.html

>>601
プレゼンとしての質が低すぎて、内容を見る気がしない。

>>601

ひでーな
そのへんの紺猿だってもっとましなプレゼンするぞ

>>601
最初の２ページまで見たところで、むかついてウィンドウを閉じた。
もうね、氏ねと。バカかと。

日本人論に持って行くのであれば、「夜這いは日本の文化です」、というところまで行か
ないと嘘になる。実質的な解は、おそらくそれに近い所にあるので、たとえうまい解が
見つかったとしても、それを思いついた過程まではなかなか公にできないのではないか。

>>601
最後まで読んだよ！

……吐き気がした。
おまえ今すぐ書店に走ってプレゼン本買って読め。さもなくばLANケーブルで首(ry

まず、論理的な展開が無い。皆無。これが致命的。間違いない。
個人的な楽観思想の伝達が目的としか思えない時点で、それはプレゼンじゃない。
宗　教　勧　誘　。

さらに、寛大にも一部の考察について反論してやろう。涙を流して感激しろボケ。

「失われた10年」の原因は日本の文化なんかとは関係ない。

原因は馬鹿政府。
未だにCOBOL教えているような教育機関が存在している時点で明白だろ。
見事なまでにITを無視し、パソコン普及の促進など見せ掛けのポーズだけで
実際にはIT業界に対して何の優遇もしてこなかった無能な日本政府。

かたや、技術者教育の重要性を認識し、大学はPascalやC++やJavaを教え、
IT業界の促進のために税制面での優遇措置を確実に行ってきた米政府。

違いは明白だろう。

601を半分くらい読んだけど、何十年も前からあるような
俗っぽい文化論をソフトウエアに当てはめて語ってるだけじゃん。

＞科学技術動向研究センターで、最近のソフトウェア工学と合理性の研究を元に、講演をしました。

↑これってまじかよ。
飲み屋で酔っ払いながら語る程度にしとけよ。。。

ああ、そうか。
なんかに似てると思ったら、飲み屋でたまに聞こえてくるアレか。

多分、本人が URL 貼ったんだろうな。
今頃画面の向こうでﾌﾟﾙﾌﾟﾙしてるに違いない。
「これだから 2ch は」とか言ってみたりとかしてな。

想像するだけでマジウケる。

これプレゼンテーションしたのか。日本人って我慢強いね。

読んでて吐き気がした。>>601

>>601
見づらい。　幼児向け絵本並の情報密度。　絵がないからそれ以下。

みんな手厳しいな。ちょっとだけ面白いとこもあった。

I Love waterfall

学部生の研究室配属発表課題並。

>>614
失礼だなぁ。
並以上の奴ならもっとマシなプレゼン作るよ。

>>589
> 今の会社はまず基本設計を発注して基本設計書を作ってもらい、

XPには基本設計という概念はない。

ＸＰが適するような短期開発なんて、俺やりたくねーよ。
小型案件を繰り返すばかりの仕事なんてＳＥにやらせろよ。

期間は短くても、すぐに運用できるメリットを顧客に理解させれば、金額は大型になるけどな。

>>617
そうでもない大型案件にも適している。

ウォーターフォールは全ての基本。
構造化設計は設計の基本。

環境が変わっているのに、
内部を変えることが出来ない企業は、
淘汰されるということです。


三菱のように。

>>619
大型って１年〜数年くらいかけてやるやつだろ？
そんなもんにＸＰが使えると思ってんの？
7.5時間労働、ペアプログラミング、短期リリース…、できたのか？

三菱自は、内部が変わったから淘汰された。

何を作るのか分からないうちから作り始めるのは無謀。

>>623
内部が変わったのは日産だろ。

>何を作るのか分からないうちから作り始めるのは無謀。

WFだって、顧客が何を作ればいいのか分かってないのに、
無理やり何を作るのかを決めて、作り始めるじゃないか。

現状でもどのみち無謀なんだよ。
頻発するデスマーチがそれを証明している。

>>622
短期リリースが不可能だという前提は、『大型案件は小型案件に分割できない』ということだ。

しかし、現実には『大型案件の多くは強調動作する小型案件に分割できる』のだよ。

これを、プロジェクトの構造化という。プログラムの構造化と概念的には一緒なんだが、
君の様子を見ていると、これに気付いている奴はほんの一握りしかいないようだな。

やれやれ。

>>624
> 内部が変わったのは日産だろ。
両方変わった。よりよく変えなければ成らないという教訓。

> >何を作るのか分からないうちから作り始めるのは無謀。
> WFだって、顧客が何を作ればいいのか分かってないのに、
> 無理やり何を作るのかを決めて、作り始めるじゃないか。
「何を作るのかを決めて」作るのと、何も決めないで作ろうとするのには大きな違いがある。

> 現状でもどのみち無謀なんだよ。
> 頻発するデスマーチがそれを証明している。
求められるものと作ろうとしているものが、かけ離れていることが問題なのか、
作ろうとしているものを、きちんと作れないことが問題なのか、それともその両方なのか。
どこにどういう無謀と無策が存在したのかが見えないものと見えにくいものでは、大きな隔たりがある。

s/強調/協調/;

やれやれ。＞自分

>>626
理想的なステップはこうだ。

１．顧客が本当に望んでいるものが何であるのか、
　　顧客自身に気付かせる。

２．顧客が本当に望んでいるものを知る。

３．顧客が本当に望んでいるものを実装する。

４．顧客が満足する。

WFは１を無視している。だから、失敗する。

１．顧客が本当に望んでいるものが何であるのか、
　　顧客自身は気付いていない。

２．顧客が本当に望んでいるものを知ることは出来ない。
　　様々な憶測、推測が入り乱れ、ソフトウェアの仕様は混沌としていく。

３．混沌とした仕様を実装する。

４．顧客は満足しない。

これがデスマーチの一因だ。これに比べれば、XPのほうが遥かにマシだ。
短期リリースを上手く実施することによって、１を達成できるわけだからな。

構造化とは要素への分割と要素間の関係、インターフェイスの設計のことで、
全体の構造がしっかりできていないと要素ごとにプロジェクトとしてシステム開発・運用しても
別の要素のシステム化の際に、すでに運用している他のシステムの手直しが必要になる。
それを極力回避するためには、全要素と要素間の関係についてしっかり設計しておく必要がある。
これを怠ると強引なつぎはぎだらけの全体像になるので、

いきあたりばったり方式は大規模システム構築には向かない。

>>628
顧客の要望をより正確に把握するだけならプロトタイプを使え。
あとから流用できるようなつくりなら、プロトタイプも役に立つだろう。

ついでに言うと、小規模案件にも向いているかどうか知らん。

>>629
>構造化とは要素への分割と要素間の関係、インターフェイスの設計のことで、
>全体の構造がしっかりできていないと要素ごとにプロジェクトとしてシステム開発・運用しても
>別の要素のシステム化の際に、すでに運用している他のシステムの手直しが必要になる。

たかが人間ごときに、未来を予測したような完璧なシステム開発が出来ると
信仰しているような口ぶりだな。……君は滑稽だ。

君はまるで、空を飛べると信じて腕を羽ばたかせていた過去の人のようだ。

そうじゃない。発想を変えろ。常識の前提を考えろ。天邪鬼に考えるんだ。
『飛ぶために羽ばたきなんて必要ない』と考えるんだ。それが真実かもしれないと気付くんだ。

>それを極力回避するためには、全要素と要素間の関係についてしっかり設計しておく必要がある。
>これを怠ると強引なつぎはぎだらけの全体像になるので、

そのためのテストとリファクタリングだ。自動的に動作検証を行う体制を作り、
改修の影響を完全に局所化しながら設計を継続的に改善していくことで、
WF開発の終盤でも問題とされている『つぎはぎだらけの全体像』を回避する。

>いきあたりばったり方式は大規模システム構築には向かない。

人が飛行機に慣れるのに、どれだけ時間がかかったと思う？

君が慣れていないだけさ。

>>630
それはプロトタイプ開発であって、WFではない。

『WFは間違っている』というのを認めた上で捻り出された、
中途半端な策だ。それは不恰好で、上手くいくかどうかも
わからない。『しかし、WFよりはマシだ』と、そう現場は思っている。

ビジネスでは、中途半端が、一番良くない。
書けたり書けなかったりするようなペンは、売れない。
上手くいったりいかなかったりするようなマネジメント手法では、
市場の要求に対応できない。

今、必要とされているのは『正解』だ。
『これが一番合理的なのだ』と胸を晴れるような、マネジメント手法だ。

それがXPだと言うつもりは無い。だが、WFでないことだけは確かだ。

問題はコーディングを中心に考えているところにある。

全体像を設計し、各要素の機能およびその関係をしっかりと設計し、
その上で「段階的に実装、テストを行う」、でなければ破綻するだろう。
どの段階で、だれが何を何処でどのように実装するか。
これらを戦略的に定める。
それによって段階ごとの設計の手直しに伴うコストを下げる。
無計画に実装していったら、他の部分への影響を抑えつつ機能の追加を行うなど
至難の技。

>>632
いいから、まず社会に出て働け。

>>634
私は会社で働いているよ。

やれやれ。詭弁のガイドラインでも貼り付けようか？

>>633
プロトタイプは要求定義、外部設計のための一手法だ。

システム開発のために有用なものは何でも使え。
ただ、有害なものには決して手を出すな。

>>635
> >>634
> 私は会社で働いているよ。


マジですか！！？

スマン、>>636-637 は私です。名前付け忘れた。

実際問題としてXPを適用する為には営業的な面の問題が多くない？
開発局面に入ってからの事例はWeb上にいくらでもあるんだけど、顧客との交渉(予算とか)の
事例が無いんだよなー
XPがリスクを回避でき品質も高くなる手段である事は内部的には周知できてるけど、それを
実務に適用したくても、いつもそのへんの感覚がわからない。

『プロトタイプは要求定義、外部設計のための一手法だ』

『あとから流用できるようなつくりなら、プロトタイプも役に立つだろう』

矛盾しているな。
あとから流用するならそれはプロトタイプ開発だ。WFではない。

思うに、わざわざ流用できるようなつくりのプロトタイプを作る努力をするより、
プロトタイプを発展させるような開発手法を採り入れたほうが合理的という
ものじゃないかね？

それとも、君たちは中途半端な妥協が一番いいと思っているのかな。
常識に従っていれば失敗しても責められる可能性が少ないという打算のもので、
企業のためにならない開発手法を信じ続けるのかな。

ただ、『それが常識だ』という非合理的な、つまらない理由で。

>>640
> あとから流用するならそれはプロトタイプ開発だ。WFではない。
言葉遊びがしたいだけなのか？
設計文書から切り貼り、自動生成して成果物を作ったらWFじゃないからWFはだめってか。

> 思うに、わざわざ流用できるようなつくりのプロトタイプを作る努力をするより、
> プロトタイプを発展させるような開発手法を採り入れたほうが合理的という
> ものじゃないかね？
わざわざ流用できるようにするために多大な時間を割くべきではない。
時間をかけずに後から流用できるような作りにできるならそうしたほうが得だろうというだけだ。
それに「有効に発展させる」ためには十分に設計を練った上で作ったプロトタイプでなければ
役に立たんと思うがね。

629な。面倒くさいから文脈で判断してくれ。名乗るほどのスレでもないし。

>>641
些細に思える言葉の定義が、問題の本質であることもある。
軽々しく扱うのは非常に危険だよ。

>>639
ああ、営業は制約条件だろうね。
彼らはものを知らなさ過ぎる。まともな提案さえできやしない。

大規模な案件でも、機能名などから、いくつかの機能に分割できる。
これは、小学生でも出来る。問題は、その次だ。

１．各機能を、紙に書き出す。（これをしない奴が多い。何を考えているんだ？）

２．各機能の前提となる機能を、紙に書き出す。線で結んでツリーにする。
　　（これをしない奴も多い。お前は見積もりをしたくないのか？）

３．２で出した機能の下に、さらに機能を書き出していく。
　　これを繰り返して、システムに必要な機能を全て書き出す。

４．優秀なプログラマと、普通のプログラマに、これを与える。
　　最短作業時間で、何日で出来るか、各機能を見積もらせる。
　　二つを比較して、難しい作業はどれなのか、簡単な作業はどれなのか、
　　しっかりと認識する。各機能の平均作業時間も出しておく。
　　（正確な作業時間は、プログラマが知っている。君は知っていない。常識だろう？）

５．仮に、プロジェクトの開発期間が１年だととしよう。
　　６ヶ月分になるまで、各機能の平均作業時間をもとに、機能に優先度をつけていく。
　　（残りの６ヶ月は、プロジェクトを遅らせないために使う。「クリティカルチェーン」を参照のこと）

６．優先度の高い機能は先に完成させて、客がレビューできる状態に
　　しなければならない。そのためには、優先度の高い機能の前提となる機能を、
　　優先して作らなければならない。（この常識が、どれほど守られていないことか！）

７．あとは、ビジネス上の交渉だ。営業がやることは以下の通りだ。

　　各機能のリリースまでの期間を平均すると、リードタイムはWFの比ではなく、
　　早い時期に運用を開始することでシステムのメリットを早めに享受できること。
　　優先度に関しては定期的にミーティングを行い、優先度の高い要求には、
　　優先度の低い要求を保留にすることで積極的に対応すること。プロジェクトが
　　順調に進んだ場合プロジェクトを早期完了という形にして、運用と平行して
　　機能追加プロジェクトを、開発初期のメンバーを残したまま開始すること。
　　これらを約束し、投資収益率の向上はコスト増よりもメリットが大きいということを
　　アピールすればいい。

>>643
なるほど、前工程からの中間生産品をもとに人間が手作りしていたものを、
中間生産品の規格を定めることで手作業を減らして自動生産できるようにすると
WFモデルじゃなくなるので一緒にするのは危険ってことかい。

じゃあ、WFモデルの各工程で作業の改善（ドキュメントフォーマットの統一化や
コメントのつけ方、使用ライブラリの統一による作業効率の向上）を行っても
WFモデルとは呼べなくなるかもしれないので、WFモデルは死に体だね。

これらの説明で、きちんと顧客を納得させることが出来れば、
競合XXX社が五千万で見積もったプロジェクトを、六千万で受注することだって可能だろう。
一度確かな実績を作れば、七千万も可能かもしれない。
（しかし、安易な水増しはしないことだ。金額の増加を納得させられなければ、
　顧客は疑いを持ち始め、信頼関係は崩壊する。今なら品質保証を兼務する
　ITスペシャリストを投入すると言えば、相手も納得するだろう――その実態が、
　単なる優秀なプログラマでも――いや、案外それが正解なのかもしれないが）

結局、選ぶ側は顧客である前に人間なのだ。相手が本当に求めていることを提案すれば、
誰だって喜んでそっちを選んでくれる。
相手は、わざわざ不景気に逆らってまで、システムを作ったほうがいいと判断して、
作ろうとしているのだから。迅速なメリットを約束してくれさえすれば、確実なメリットを
約束してくれさえすれば、コストなんて知ったことではないのである。

XPは共産主義者の手法。
まず自分が何主義者か言えよ。

>>644>>645>>647 って

今後どんな方法論が流行しても使えそうな便利なコピペだね。

上流高低をやる奴が頭が良い思ってる
馬鹿だったらどうしようもないからウォーターフォールはｳﾝｺ
ほんと自分の間違い認めないからな。

>>646
そのとおりだ。

WFモデルの目標は、一度だけ流れることだ。
『途中でやりなおしをしないこと』 これがWFモデルが理想として定めるルールだ。

しかし、現場は純粋なWFモデルの利用を諦め、プロトタイプ開発を採り入れた
開発手法に移行した。何故か？前提が根本的に間違っているからだ。

『途中でやりなおしをしないこと』という理想が間違っているからだ。

規格を定めること自体は正しいが、前工程で全ての規格を定めようとするのは間違いだ。
そんな規格は時間と共に腐敗していき、現実にそぐわない害悪に成り果てるだけだ。

一つ、気付いた点がある。

君の言う、『手作業を減らして自動生産できるようにする』 と、
『WFに基いて開発を行う（テストを最終工程で行う）』 は矛盾している。

WFではテストを最終工程で、（当然テストコードなんてものは書いていないのだから）
手作業、あるいはテストツールを新たに開発して行うわけだが、
これに膨大な時間を取られるのは周知の事実だ。

しかし、前者ではそれを否定している。これはどういうことだろうか？

>>651
> WFモデルの目標は、一度だけ流れることだ。
そうだよ。

> 『途中でやりなおしをしないこと』 これがWFモデルが理想として定めるルールだ。
やりなおしを極限まで減らすこと、な。

> しかし、現場は純粋なWFモデルの利用を諦め、プロトタイプ開発を採り入れた
やりなおしをしたくないからな。

> 『途中でやりなおしをしないこと』という理想が間違っているからだ。
やりなおすと金がかかるじゃねーか。
１．やりなおしを減らす。
２．やりなおしが発生しても低コストで対処できる工夫をする。
３．いっそのこと一期開発、二期開発に分けてリスクを分散させる。

> 規格を定めること自体は正しいが、前工程で全ての規格を定めようとするのは間違いだ。
> そんな規格は時間と共に腐敗していき、現実にそぐわない害悪に成り果てるだけだ。
現実に沿うようにメンテしろよ。現場が混乱するだろ。

> 君の言う、『手作業を減らして自動生産できるようにする』 と、
> 『WFに基いて開発を行う（テストを最終工程で行う）』 は矛盾している。
なんで？

WFはいろんな会社がきっちり契約するためにやるんだよ。
システム開発はアマチュアの日曜プログラミングじゃないんだよﾌﾟ

>>652
>> 君の言う、『手作業を減らして自動生産できるようにする』 と、
>> 『WFに基いて開発を行う（テストを最終工程で行う）』 は矛盾している。
>なんで？

こんな常識も分からないのか。やれやれ。
下の図を見ろ。

君の主張 『WFモデルを使えば、プロジェクトは遅れない』

WFモデルに基づいて、テストを最後に行う
↓
仕様の矛盾、プログラムのバグが早期検出できない
（そんなものは無いと信じたいのなら、それでもいい。どうせ最後には問題は露呈する）
↓
仕様の矛盾、プログラムのバグが残ったまま開発が進む
（矛盾した仕様や、バグのあるモジュールを前提として作ったプログラムは、
完全に無駄となり、作り直しになることもある。これを『やりなおし』ではない
と言い切る馬鹿もいるが、明らかに『やりなおし』であり、無駄な工数がかかる）
↓
テストが予想以上に長引き、なかなか予定した品質に辿りつかない
（FWモデルを採用したプロジェクトのデスマーチ化）
↓
プロジェクトは遅れる

私の主張 『WFモデルを使うから、プロジェクトは遅れる』

さあ、反論をどうぞ。

やっぱりWFが上手にできない人が自分を肯定するための手法ってことだね。

ぼくはいままでもWFできっちりやってきたし、
ダメな人は手法を変えてもダメなものだよ。
職業転換した方が自分のためにも周りのためにもいいよ。

ダメなのは手法がダメなんじゃなくてその人がダメなんだよ。

>>656
ちなみに、こなしてきたプロジェクトの規模（参加人数）は？

>>654
> 君の主張 『WFモデルを使えば、プロジェクトは遅れない』
他人の主張を勝手に騙るな。

何を作るかを決めてから作らないと破綻する。
何をどういう手順で実装し、試験していくかを戦略的に定め、実行しないと
要所要所で発生する設計の手直しにかかるコストがむやみに増大する
いきあたりばったりな実装、機能拡張では、品質の低下を起こさせないことは難しい。

が主張だ。

>>655
>WFを上手くできない人

人間は完璧ではないよ。
故に、完璧か、それに極めて近いことを前提として要求するWFは、
現実にはソフトウェア開発のごく一部にしか適用できない。

お役所用の、結局誰にも使われないような存在価値の無いシステムの開発には、
WFのほうが向いているだろう。

しかし、一方でWFが全く向いていないプロジェクトがある。
そして、そういうプロジェクトはどんどん増えてきている。
そういうプロジェクトには、明らかに合っていないWFやプロトタイプではなく、
XPのほうが合っている可能性がある。

それだけのことだよ。

>>659

>手順、戦略的、要所要所、コスト、いきあたりばったり、実装、機能拡張、品質、低下、難しい

この単語で現実知らなさ杉のお坊ちゃまかコン猿を連想するのは俺だけですか。

完璧を求めているわけではなく、

やらないといけない事は、やはりやらなければならない。

それが手作業であろうが機械化されていようが、というだけ。

>>659
これは失敬。以後気をつけよう。

>何を作るかを決めてから作らないと破綻する。
XPでも決めるよ。作る前に。

>何をどういう手順で実装し、試験していくかを戦略的に定め、実行しないと
>要所要所で発生する設計の手直しにかかるコストがむやみに増大する

ちゃんとテストが書いてあって、ツールなどを利用してリファクタリングを行えば、
設計の手直しにかかる時間（私はなんにでもむやみに「コスト」という言葉を使う
馬鹿を軽蔑することにしている）がむやみに増大することは無い。

>いきあたりばったりな実装、機能拡張では、品質の低下を起こさせないことは難しい。

それは、君がテストをしていないからだ。
いきあたりばったりな実装が理由ではない。実際に、WFの終盤に
品質が地に落ちていることだってあるじゃないか。それはWFが
失敗したという以前に、WFモデルを採用するが故にテストを軽視していたからだ。
開発中にテストをしていないことが、品質低下の理由なんだよ。

>>661
工程表を作った事も、生産管理について勉強したことも無い学生さんなら何連想しても

>>664
工程表を作って、生産管理したらバグはなくなりますか？

>>661
幻滅したかい？ ああ、だが、IT業界の現実なんてそんなものだ。

なんでWF vs XPみたいな構図になるんだろ。
完全にWFなプロジェクトなんて存在しないし、完全にXPなプロジェクトも存在しないんじゃねーの？

>>663
> >何を作るかを決めてから作らないと破綻する。
> XPでも決めるよ。作る前に。
>>624に言ってやってくれ。

> ちゃんとテストが書いてあって、ツールなどを利用してリファクタリングを行えば、
> 設計の手直しにかかる時間（私はなんにでもむやみに「コスト」という言葉を使う
> 馬鹿を軽蔑することにしている）がむやみに増大することは無い。
設計の手直しに伴ってテストの内容も変わるだろ。
その影響範囲も短時間に見極めなきゃならんだろ。
むやみに増大することは無いっていう自身はどこからくるのか。
ツールの使用は賛成だよ。無駄な時間（コスト）が減るから。

> >いきあたりばったりな実装、機能拡張では、品質の低下を起こさせないことは難しい。
> それは、君がテストをしていないからだ。
いきあたりばったりな実装だと、機能を実装する際に単純なコードの追加ではすまなくなるだろうってこと

> いきあたりばったりな実装が理由ではない。実際に、WFの終盤に
> 品質が地に落ちていることだってあるじゃないか。それはWFが
変更管理の不備、改造の規模の増大による品質の低下と、
それ以前の問題としての製造段階での品質の作りこみの失敗は分けて考えたほうがいいと思う。

> 開発中にテストをしていないことが、品質低下の理由なんだよ。
WFモデルが総合試験まで一切のテストを行わないと思ってんの？

>>665
減る

>>669
人間の思考回路の工程表を作ってくれ。
それができたらプロジェクトは上手くいく。

>>670
工程表ってのは、単価いくらの人間の思考回路を何月何日から何月何日まで何のために使うか
って表なんだよ。
作ったら上手くいくのではなくて、上手く作って、上手に管理したら、上手くいく確率が高い。

>>668
>設計の手直しに伴ってテストの内容も変わるだろ。
>その影響範囲も短時間に見極めなきゃならんだろ。
>むやみに増大することは無いっていう自身はどこからくるのか。

実体験

>いきあたりばったりな実装だと、機能を実装する際に単純なコードの追加ではすまなくなるだろうってこと

プロジェクトにプログラマとはとても呼べないコーダーしかいなければ、そうなるだろうね。

しかし実際には、テストコードを書いて、クラスを追加すれば済む話だ。
君の『単純なコードの追加ではすまなくなるだろう』という妄想は、今の開発手法にはあてはまらない。

>変更管理の不備、改造の規模の増大による品質の低下と、
>それ以前の問題としての製造段階での品質の作りこみの失敗は分けて考えたほうがいいと思う。

確かに、コーダーがXPに失敗して死ぬか、SEが管理に失敗して死ぬか、という違いがあるね。
これは非常に重要だ。後工程で挽回できる可能性が低い分、後者のほうが性質が悪い。
WFモデルを採用したプロジェクトでの管理の失敗は、死を意味する。SEは自覚していないようだがね。

実体験じゃあ何の反論もできんな。何しろ実体験なんだから、仕方が無い。

あなたの勝ち。

>設計の手直しに伴ってテストの内容も変わるだろ。
>その影響範囲も短時間に見極めなきゃならんだろ。

面倒くさいんですか？

>設計の手直しに伴ってテストの内容も変わるだろ。
>その影響範囲も短時間に見極めなきゃならんだろ。

それとも、出来ないんですか？

>>634
> 問題はコーディングを中心に考えているところにある。

だからアーキテクトを目指せといっているんだ。
考え方をしがらみだらけのドカタとび職人的な考え方からアーキテクト的な考え方に変えるべきだ。


この時代,programerのことをアーキテクトと呼ぶべき
http://pc5.2ch.net/test/read.cgi/prog/1084897194/

白熱しているところに申し訳無いが、参考情報だ
>>8 と　>>13

>>648
アフォ、ウォーターフォールのほうがよっぽど共産主義的だ。
やることは制限されるし後戻りできんし一方通行でまるで
ブラックホールのようだし反復型開発は許されないしな。

>678

>677を読んだか？

民主的に開発をやられてはかなわん。
民主的に戦闘をやるようなものだ。

この記事についてのみんなの意見を聞いてみたい。

http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040407/1/
http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/1/
http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/2/

　パラダイム・シフトは，単にある特定領域の変化をさすのではなく，周縁も
含めた大きな枠組みの変化を意味する。だから学際研究が重要なのだが，ソフ
トウエアについてはまだ歴史が浅いためか，どうも個々の事象がばらばらに認
識されているように感じる。しかしパラダイム・シフトが起きればプログラミ
ング言語の変化だけではなく開発プロセスの変化も伴うのはある意味当然のこ
となのだ。

ところで、「パラダイム」って言葉をやたらと出す奴って、
トーマス・クーンくらいは読んでるんだろうなぁ？

ＸＰは旧主体性派ウォータフォールを駆逐するために
生まれたプログラマ革命の一つだよ。

http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%BC%E3%83%9E%E3%82%B9%E3%83%BB%E3%82%AF%E3%83%BC%E3%83%B3

トーマス・クーン

出典: フリー百科事典『ウィキペディア（Wikipedia）』

トーマス・クーン（Thomas Samuel Kuhn、1922年7月18日 - 1996年6月17日）
は、アメリカ合衆国の科学史家・科学哲学者。「トマス・クーン」とも表記さ
れることがある。1962年に発表された主著『科学革命の構造』で、科学の歴史
がつねに累積的なものではなく、断続的に革命的変化すなわち「パラダイムシ
フト」が生じると指摘した。クーンのパラダイム概念は、科学史・科学哲学だ
けではなく、社会科学や現代思想に大きな影響を与えている。

(略)

邦訳著書

懼 常石敬一訳『コペルニクス革命促ｭ科学思想史序説』、紀伊國屋書店、1976
年（のち、講談社学術文庫に収録、1989年6月刊。ISBN 4-06-158881-8）
懼 中山茂訳『科学革命の構造』みすず書房、1971年3月。ISBN 4-06-158881-8
懼 安孫子誠也・佐野正博共訳『本質的緊張促ｭ科学における伝統と革新』1、
みすず書房、1987年9月。ISBN 4-622-01691-5
懼 安孫子誠也・佐野正博共訳『本質的緊張促ｭ科学における伝統と革新』2、
みすず書房、1992年7月。ISBN 4-622-01692-3
懼 安孫子誠也・佐野正博共訳『科学革命における本質的緊張促ｭトーマス・クー
ン論文集』、みすず書房、1998年10月。ISBN 4-622-04963-5
---
>>662
どの本がお薦め？

文字化け。ごめん。

>>681
一番目と二番目には、読む価値がある。

ジョン＝カーペンター監督の映画にもあったな＞パラダイム

パラダイム・シフトは常に主流から、それた方向からやってくる。

パラダイムシフトは、これまで常識とされてきた前提の間違いを正すものだ。

結果として、これまでの間違った常識を前提に進んできた業界全体に、
大きな革命のような潮流が発生することになる。それは正しいことで、
より合理的なものであるから、あきらめることだ。抵抗はするだけ無意味だ。

相対性理論が滅びて、万有引力が正しいと言われるようになることはあり得ない。
地動説が滅びて、天動説が正しいと言われるようになることも無い。
一度パラダイムシフトが起こってしまえば、過去の常識はほとんど意味を成さなくなる。

WFがTDDに取って代わられるのも、正当な理由がある。
WFが市場の要求に合わなくなってきたためだ。市場が、低コスト、短納期、高品質を
求めるように変化していく限り、WFの手法に限界がやってくることは確実だろう。

それは確定した未来予想図、賢い者なら誰でも気付く運命の片鱗のようなものだ。
変化に乗り遅れた者は大損をするが、変化に乗ることが出来た者は大きな利益を得る。
逆に考えるんだ。積極的に運命に関わってしまえばいい。関わって、大きなチャンスを掴め。

あほやん

>659
ちょっと待てや
WFとTDDを同列にするな
工程を大まかに
概要設計
　↓
詳細設計
　↓
プログラム設計
　↓
プログラミング
　↓
プログラムテスト
　↓
結合テスト
　↓
システムテスト
で区切った時に
プログラム設計/プログラミング/プログラムテスト
をテスト先行で行うのをTDDと言う

従ってWFの一部工程でTDDも可能

方法論はどうでもいいんで、現実を変えていくためにどうすればいいのかという話ｷﾎﾞｿ

>692
まず、TDD
そこから

現場からﾎﾞﾄﾑｱﾌﾟｰ的に変えていくっつー事っすよね。
テストファーストを定着させて、ＴＤＤに発展させて。
その辺はイメージできるんだが。

俺が面白いと思ったのは、30年前に提唱された開発方法論が今なお高い価値を
持ち続けているのだろうか、という問いなんだが。


30年の間に、ソフトウェア開発を取り巻く状況は大きく変わってきたわけだが、
WF というのはそれらの変化にあまり影響を受けずに、一貫して有効に機能す
る黄金律のようなものなのだろうか。

WF は 30 年前ほど有効には機能しなくなっているし、おそらく 30 年後には
今よりももっと機能しなくなっていくだろう、という視点がこの記事の前提に
あるのだと思う。

俺はせいぜい20人程度でコード書いてる小規模プロジェクトしか経験がないの
だが、大規模でやってる人にとって、WF って昔も今も何の変わりもなくうま
く機能してる、あるいは昔よりも今の方がよりうまく機能している、って実感
はあるの？



この後、どう TDD につながっていくかは、まだよくわからん。連載3回目まで
じゃなんともいえない感じ。

デマルコの古典とか読むとウォーターフォール開発は当時から批判されていたように思える。

で
「SIerが進捗をわざと遅らせて少ない労力でお金だけ取ろうとする」
のはどうすれば防げるのよ

計画ゲームなんて相手の持ち札が見えなければ
絶対騙されるだけやん
相見積もとれないし

俺もそのへん気になってる。
予算も取れないよな。

>SIerが進捗をわざと遅らせて少ない労力でお金だけ取ろうとする

払わない。以上

>>689
パラダイムシフトは別に「正す」わけではないが。
天動説だって計算が大変なだけで間違いではない。

設計手法の変革をパラダイムシフトといっている奴は、そのへんの事をわかっているからこそ
言っているのだと思うけどな。

100%正しい設計はできない & 正しく出来たかは動くものをテストして確認しないとなんとも言えない

からTDDなんだよ。それだけ。

>>699

払わないとシステムもできない　最初から発注もせず
すべて自社でつくれってことかい！

>702
>払わないとシステムもできない
はぁ？もまえSIerって世の中に一つしかないと思ってる？

>最初から発注もせずすべて自社でつくれってことかい！
意味わからん

>>703

会社間で一度契約してしまったらそもそも「払わない」という選択肢はないだろ。

で、仮にＸＰで開発することになったとして「機能は計画ゲームで
決めるからわかりません、コストも決まりません。開発期間だけは
きまってます」　なんて契約をどうやって結べばいいんだ？

>会社間で一度契約してしまったら
はぁ？必ず払わなければならないのが契約と思ってる？

>機能は計画ゲームで決めるからわかりません、コストも決まりません。開発期間だけは
きまってます
意味わからん

はぁ？意味わからん

リードタイムだけの契約が結べない企業は負け組。

頭のいい人は、WFだってちゃんとプロジェクトごとにカスタマイズして使ってただろ。
XPの方が礎石としてはゆるいから、昨今の経験のないPMには辛かろう。

>リードタイムだけ

...そんな契約(w

>現場からﾎﾞﾄﾑｱﾌﾟｰ的に変えていくっつー事っすよね。

まず、次工程の設計に逝く前に対応するテストケースから作る。これ最強。

>705
機能面はなんとなく創造できるのだけれど、コストや期間は契約前にどういう風に決めるの？
俺も>704と同じ疑問を持ってるんで、その辺の話聞かせてくれ。

口だけ達者なXPer

毎日定時退社で、納期が来たら開発は終わり。

・・・素敵だ。

>コストや期間は契約前にどういう風に決める

まずね、おおまかなデザインっちゅーか想像図っちゅーかそーゆーのをすり合わせるよね?
(大抵ここまではロハなんだか、まれにお金がからむ)

んで、それから、
作る方はこんなん作るとだいたいこれぐらいかかりそうです、って提示
そんだけ。

業界にもよるんだろうが俺の周りだと、顧客<->元請け間は、ある程度きっち
りした契約を結んでいるが、元請け<->下請け間は「期間/人数/費用」で契約
を行い、具体的な作業内容については契約に盛りこまれていないことが多い。
人数/期間も状況に応じてある程度流動的に変化する(契約改訂などで対処)。

たぶん XP は、こうゆう作業内容を明確にコミットしない、元請け<->下請け
間の契約形態の方がよりよい方式であるという考えかたな気がする。


発注者と受注者が一定以上存在していて互いに選択の余地がないとうまくいき
そうにないな、とかいくつか無言の前提はある気はするな。
あと、チームの人数規模なんかはどうやって決定するんだろう。

>714
提示したものは契約として守るって事だよね？
それだと今までのやり方と変わらないような気がするんだけど・・・

オブジェクト指向もクラス間の契約を疎にするために生まれたものだ。

XPもプログラマと元請け業者との契約を疎にするために生まれたものだ。

それによってプログラマは奴隷の身から解放され自由の身になって開発効率が高まる。
まさに君主政治、封建政治、社会主義地獄から抜け出した民主主義の世界だ、Extreme Programmingは。
あれこれとくちうるさいことを言う顧客ってのはプログラマの能力を最大限に引き出すことができない。
従来のウォーターフォールを押しつける顧客もだ。

顧客は我儘を言う権利がある、というのが XP の哲学なんだと思うけどなぁ。
自由の身になったのはむしろ顧客であって、プログラマではない。

プログラマは、ペアプログラミング/コーディングスタンダード/TDD/コード共
有などを強制されるので、むしろ自由度は減るはず。

まるで自己啓発セミナーの大流行のような危うさを感じる。

そういえばさ、随分と昔から、具体的に言えば２４年ほど前から、

良い設計とはテストのしやすい設計。
設計する際は、どうやってテストをするか、テストがやりやすいかどうかを考えなさい。

っていわれ続けてきたよね。

>>719

というか科学の名を借りてるだけ自己啓発セミナーより悪質

>716
>提示したものは契約として守るって事だよね？
>それだと今までのやり方と変わらないような気がするんだけど・・・

ちゃうちゃう。今までのは提示なしで契約。だからデスマーチ。

そんな事やってる所あるの？
XPじゃなくても、画面帳票数や、機能概要くらいは決めてから走り出すのが普通では？
作業範囲も決めずに契約だなんて、WFだXPだ以前の問題のような気がする

>>723
>715みたいないわゆる人月契約は結構ある。
契約の基本的な考え方は工数提供でしかなく、工数提供のみが契約履行にあたるはずなのだが、
成功した成果の提供まで要求する発注元も沢山ある。
受注側は更なる受注のために成功成果を目指すわけだ。
まあ人月契約は受託契約では無いことは明白なのだが。

XPを実装機能を明確に決めない受託型開発だと誤解している
恥ずかしい>>715がいるスレはここですか？

>724
ああ、確かに下請けの仕事だとそういう感じ多いですね。
営業的な力関係等が大きく関わるからなかなか難しい・・・
んで、エンドユーザと直接やってる場合って、そういう契約で開発する事って通常は無いよね？
エンドユーザとXPは難しいって事になるんでしょうか。

>725
>715は、実務にＸＰを適用しようとした時、開発が始まる前の見積もりや契約はどうするのか？
という流れで出てきた話題であって、ＸＰがソレであるという指摘では無いと思うのだけど。

オンサイト顧客 が確保できない場合、それをXPと呼べるのだろうか。
また、仮にXPと呼んだとして、それが成功する確率がどれほどあると言うのだろう？

日曜プログラマーは一人だからXPは無理ですよね

>>726
エンドユーザと開発者の距離が短くないと、XPの他のプラクティスの適用が難
しくなる気がする。

そもそも、成果物の定義がきちんとできた後で契約を締結してる？
現在でも要求仕様書や概略設計書が fix した後に契約結んでいるわけではな
くて、でたらめな要求分析と希望的観測に基づく工数予測の元に、なんとかや
りくりしているのが実状だってとこ多いと思うけどなぁ。

>729
>でたらめな要求分析と希望的観測に基づく工数予測の元に、なんとかやりくりしているのが実状

うちも受注段階まではそんなノリ。
ですけど、正式な要件定義後に再度、工数と期間見積の見直しをさせてもらうという前提のもと注文を頂いてます。
それすらやらずに最初の見積のまま突っ走るって事ですか？
マジっすか・・・

>727
それをXPと呼ぶかは人それぞれだと思うけど。
現実にはプラクティスをフルに満たせるケースなんてほとんど無いんじゃ。

>>730
>それすらやらずに最初の見積のまま突っ走るって事ですか？

いや、要件修正、工数再見積り、の無限ループに入りますよ。
ただ、一度契約してしまうと、予算はほとんど動かせなくなるので、その範囲
内で何を実現するかを取捨選択する感じ。ハード同時開発の場合は特に、プロ
ジェクト後半にハードのプロトが出来てきてから、ハードウェアの特殊な制限
事項が明らかになることもあるし、見積り精度がどうしても低くなりがち、と
いう、この業界特有の事情もあるので、一般論としてどうかはよくわからない。

ぬ。なんか XP じゃない話をしてるな。俺。

気をとりなおして、XP の見積りの話。

白本を読んだ印象では、XP 的に理想的な案件は、ある程度のボリュームのあ
るエンタープライズ系の業務システムみたいなもなんだと思う。

まず、半月から一箇月ぐらい小人数で要件分析を行って、改善すべき項目のリ
ストアップとざっくりとした必要時間の見積りを行う。例えば、改善すべき項
目が３つあって、それらすべてに対応するには１年間必要とか。

次に、最初の契約を行う。ただし、1年の仕事に対して1年の契約を結ぶ必要は
ない。例えば、最初の契約はとりあえず3ヶ月、３つの項目のうち顧客の望む
ひとつだけに対象を絞って行う、とか。

1イテレーション2週間として、5から6回ぐらいのスモールリリースを経て、最
初の契約が終わる。チーム規模が適切なら、この段階でテスト的にせよ実運用
可能な何かができることになっているので、顧客は作られたソフトウェアに対
して、まともな評価を下すことができるはず。

このあと、顧客は契約を延長してもいいし、手元に残ったきちんと自動実行可
能なテスト付きのソースコード一式を元に別の開発者を探してもよい。

これを、1年続けたところで３つの問題がきちんと解決できていない可能性は
あるけれど、それはそもそも見積り精度の問題なので、WF でやったからといっ
て1年後の問題解決を保証できるわけではない。

（つづき）

疑問点として、スモールリリースがあまり意味を持たない分野に対してはうま
く機能しそうにないということ。1年後に開催されるイベントで使用する入場
者管理システムなんてものは、1年たった時点で確実に完成している必要があ
るし、それ以前にいくらスモールリリースしたところで、運用テストなんかほ
とんどできないだろう。

あと、業種的に特殊な場合、発注側/受注側の数が限られるので、「他をあたっ
てもよい」とか言われても、選択肢がない場合があるな。


まぁ、銀の弾丸はない、といういつもの話になるんだけど。

「銀の弾丸」「銀の弾丸」としつこいな。

この業界に「銀の弾丸」なんぞ存在しないことは百も承知。
それを偉そうに「この手法は銀の弾丸」ではないとか威張ってる奴は
新しい技術を導入されると自分の立場が危ぶまれるから抵抗勢力と化して
保守的になっているだけじゃねえのか。

それと、「銀の弾丸」でないテクノロジーは使うべきでないと
考えている奴は頭がおかしいとしか言いようがない。
使いもしないで何を言っているんだ？
ただの喰わず嫌いじゃないのか？

>>734
逆じゃネーの?
この業界に「魔法の粉」なんぞ存在しないことは百も承知。
それを偉そうに「この手法こそ魔法の粉」だと威張ってる奴は
新しい技術を導入し騒ぐことで自分の立場を作っているから
保守的で慎重な人たちを抵抗勢力と称しているだけじゃねえのか。
概念ばっかりで実効が示されないのが一番問題なんだよ。

ＸＰを魔法の粉だと思いこんでいるのか。
そりゃおめでたいな。
コンピュータが台頭したときに
PCをオフィスに導入することをためらい最後まで抵抗していた老人みたいだな。

>>736という奴は、仕事で命令するときも必ず電話か口を使い、メールを送ることもできず
他人からの受信メールは一切受け付けないヴァカみたいだな。

簡単なことだよ、実効を示せばいい。
そうすりゃ信用されるだろ。
信用が無いのは自身の問題であって
どんな暴言吐こうが他人様に転嫁できる問題ではないね(w

なんか嫌なことでもあったのか？

新しいテクノロジーを適用するにあたって、その適用範囲を見定めるのはごく
普通のことだと思うけど。全然畑違いの分野に適用して、実効性がないとか、
信用できないとか言ってもしょうがないやん。

そうゆう議論をきちんとできずに、新技術はダメだと、既存技術はダメだとか、
変な宗教論争始めるのはかんべんしてほしい。

欲しいのは有効な対策と方法論であって、妖しげな勧誘ではないし

ギャルプログラマとのペアプロは正直勃起もんだ！

>>730
＞現実にはプラクティスをフルに満たせるケースなんてほとんど無いんじゃ。
そのとおりだね。でも、XPではオンサイト顧客を挙げている。
この人物に要求されるものは、自分たちが何を欲しいかをちゃんとイメージできて、
業務に必要な知識の大部分を把握していて、開発期間との兼ね合いを見て機能の
取捨選択ができて、自分の決定事項を上に認めさせられる政治力も持つこと。
いくら何でも、これは反則だよ。こんな人物がいれば、どんな手法だって成功する。

オンサイト顧客が用意できない場合、作成範囲策定のためやその他仕様提示のために
かなりのドキュメントを用意する必要がある。（よく分かっていない人たちに、
納得してもらうのだから当然のこと）　で、お決まりのレビューが待っている。
ペアプログラムをしようが計画ゲームをしようが構わないが、それなりの時期に
それなりのドキュメントを用意するのは、XPと言えるのか？
もしドキュメントを用意しない場合、どうやって客を納得させるんだ？

ドキュメント作成は、タスクのひとつとして処理しろ、というのが最近の XP
推進者の主張らしい。つまり、ドキュメント作成に対するコスト見積りをして、
計画ゲームで優先順位つけて処理する、と。


わかっていない人を納得させるのに、ドキュメントを作るのがベストなのかと
いう議論はさておく。

>>742

オンサイト顧客が用意できないことの影響は確かにドキュメントの増大もあるけど、
「発注側」と「顧客」が「ドキュメント」でしか合意できなくなるのが最大の問題点だと思う。

オンサイト顧客って要するに顧客と発注側の意思疎通のコストを０にする存在では？
つまりオンサイト顧客がいれば極端な話進捗報告もミーティングもいらず、質問表を
投げなくても疑問点は即座に帰ってきて、しかもその回答は顧客側でオーソライズされてる
という夢の存在..
正直そんなものがあれば他のプラクティスなんてどうでもいいと思われ

こいつを使えばドキュメントの生成が楽になるぞ。
雛形が沢山用意されている上にパッケージの自動アップデート機能、
プラグイン拡張も可能だ。


【玄人】我が名はプロジェクトマネージャーMaven
http://pc5.2ch.net/test/read.cgi/prog/1090129578/

>>744
うまくまとめてくれて、ありがとう。
漏れの言いたかったことも、まあそんな感じ。

XPで オンサイト顧客 が不可能となった場合、他にも以下のプラクティスが難しく
なると思うんだが。（ドキュメントの作成や、顧客側の調整が時間がかなりかかる）
・計画ゲーム、小さなリリース、メタファー、テスティング（機能テスト）

で、残りのプラクティスをかき集めたところで、それがXPと言えるのかと。
ドキュメントが前提となる現実に対して、従来から提唱されてきたウォーターフォール
（一部スパイラル）型の手法よりも成功するのかと。

XPを推している人は、そこんとこどうよ？

XP関連の記事等を読んでいると、オンサイト顧客=現実の顧客である必要は無い、みたいな例が多くね？
仮想顧客となりうる程のSE(そういう人がいればの話だが)を顧客とみなせば不可能では無いか・・・。
で、うちにはそんなｽｰﾊﾟｰSEは居ないので無理ｗ

>>747
顧客proxyってのがあったね。

そのプロジェクトでは、顧客との付き合いが長くて顧客の業務内容についての
知識のあるSEがいたから、それを仮想顧客とみなして作業した、と。顧客
proxy は、簡単な質問に関してはその場で返答するし、proxy で処理しきれない
質問に対しては責任持って顧客に問い合わせをする。

JavaPressかなんかの記事だったけど、うまい落としどころだと思った。


ちゃんとしたオンサイト顧客は、客先に出向して作業するような形態でない限
り現実には難しいと思う。うちもオンサイト顧客はできてない。
でも、以下はできてるし、効果はあると思うよ。

・計画ゲーム、小さなリリース、メタファー、テスティング（機能テスト）

あと、ペアプログラミングも。

>>748
オンライン顧客のいない計画ゲームって、タダのブレインストーミングじゃないの？

>>749

俺が顧客ならぶちきれるな
「開発側で協議した結果この機能とこの機能が重要だと思いますた」
って勝手に決めるな

>>748
専任のオンサイト顧客がいないのに、機能テストをすべて顧客側で用意してもらえるの？
それも小さなリリースのたびに。
小さなリリースのたびに、顧客側がちゃんとテストして評価できてる？

オンサイト顧客がいないんだから、もちろんドキュメントに残しているのだろうけど。
小さなリリースのたびにドキュメント行程を用意しているのは、すごいと思うよ。

>ドキュメント行程

はぁ?意味和姦ね
頭悪い漏れに教えたもれ

千歳飴

高度分断政策：和魂洋才
http://d.hatena.ne.jp/Soreda/20040531

この辺が問題なのはわかってるんだけど…

計画ゲームは、ある程度まとめてやってる。一月毎に打ち合わせして、2イテ
レーション分の計画を優先順位付けて決め、優先順位の高いものから実装して
いく感じ。作業中にひとつのタスクが複数に分割されたり、優先順位の高いタ
スクが割り込むことがあったりもするけど、これは週一の打ち合わせで調整。

機能テストは、こちらで用意したものを顧客に承認してもらう形。従来の慣習
では、最終リリース時に開発側が用意したテストと、テスト実行結果を顧客に
承認してもらうという形式だったものを、リリース毎にアップデートしてく形
にしただけ。（この辺は個人的にどうかとは思う）

余分なドキュメントは特に作っていない。しいていえば、タスク管理表みたい
なものはある。優先順位順にソートされていて、実装済/作業中/未着手がわか
るもの。仕様書の類は作業開始前にラフなものを書いて、プロジェクト後半ま
でアップデートせず放置。

打ち合わせ回数は週1回2時間ぐらい。月一で少し長いものをやる。もちろん、
随時電話や E-mail も使う。

ただし、全プロジェクトでこれを適用しているわけではない。基本的に顧客都
合優先。

このスレは、スレタイで損してる気がするなぁ。

http://www.ne.jp/asahi/e/yamane/software/engineering/xp/daiary/xp_fever.html

>お客さん： そうなんだけど、市場投入タイミングっつぅのもあるからねぇ。

>俺： 確かにそれは、一理ありますね。 ほな、こうしましょ。
>この提案書、私の見積もりでは完成するのに、４２人日必要と書いてますね。
>この中で、最も重要なものから順番に２１人日分選んでください。 それを、３末までに実装しますわ。
>市場投入のタイミングを問題にされているのであれば、特にエンドユーザに見える部分から実装と
>言うことになるんでしょうかね？

>お客さん： そんなことできんの？

>俺： えぇ、XPですから。

疑問１：システムの機能はそんなにうまく直交してるのか？つまり顧客が選んだ部分だけ単体で動く形に
切り出せるのか？

疑問２：だれが昨日ごとに人月計算するんだ？　純粋に科学的にやるのであればファンクションポイント
法等があるだろうが、ベンダーが水増ししない（あるいはダンピングしない）保証はどこにある？

そのサイトの記事は、パイロットじゃないプロジェクトでガンガン適用してるって話だったよな。
XPが実際の現場へ適用されていく事例が追加される事を楽しみにｦﾁしてたんだが・・・
その後さっぱり更新されないって事はやっぱ週40時間は無理だったって事かなぁ。
ホントにそのノリで実現できるのであればそれは素晴らしい事だと思うけど。

顧客からの周期的なフィードバックに破綻なく応えるには、変更を見越した頑丈な基本設計が必要。
「オブジェクト指向だからだいじょうぶ」とかいう奴は世の中を舐めてる。
最悪の場合、次第に回転が遅くなって最後にはにっちもさっちもいかなくなる。

顧客からの要求に対応する作業を秩序だてて行うために、きちんとした変更管理の手順を
確立することは重要だが、その際の作業の優先順位は顧客から見た優先順位そのものではなく、
開発者からみたリスクの大きさを考慮して優先度を判断したほうが良いのではないかと思う。

>>759
>変更を見越した頑丈な基本設計が必要
つまり「こんな事もあろうかと」といった真田さん(まぁ誰でも良いが)的発送こそが重要と。
でもXPって真田さん的プログラミングを戒めているんじゃなかったっけ？

洪水の多い地方なら高床式にし、地震の多い地方なら耐震設計とし、乾燥した風の強い地方なら耐火設計とする、

ようなことを制約の範囲内で行う設計

が行われていないと、誰が何を戒めようが危うい。

>>760
自動テストは当然として、リファクタリングするのに舐めてかかっちゃダメってことでしょ。
デザインパターンくらいは余裕で使いこなせるプログラマがいない現場では、
リファクタリングが疎かになって、いずれ身動きが取れなくなる。

顧客　　「ここをこういうふうに変えて欲しいんだけど」
開発者 「あー。この変更には１ヶ月かかりますねー。
　　　　　 （まいったなー。この変更はシステム全体に影響するんだよなー）」
顧客　　「１ヶ月ですかー（開発初期には2日くらいでやってた変更なのに……こいつ足元見てやがるな）」
開発者 「本当に必要な変更なんですか？（ハッ！どうせアンタの思いつきなんだろ？）」
顧客　　「ユーザが欲しいって言ってるんですよ。何なら電話して聞いてみますか？
　　　　　 （嘘でも吐いてると疑ってんのか？ 舐めんなボケ）」

なんて状況になったら、XPは破綻する。
XPは、プログラマが設計知識を持って常日頃からテストを書き、
リファクタリングしていることが前提となっている手法なのです。

俺には、RDBにおいて表の物理設計がコロコロ変わるような環境下で、
柔軟な対応が取れるアプリケーション群を設計する能力が無い。

XPも全員がPGスキルを有していることが前提なのです。
お宅の会社に必要なのはスキルの高いPGを揃えることです。
XPは失業対策のためにでっち上げられた開発手法ではありませんから。残念。

>>747
> JavaPressかなんかの記事だったけど、うまい落としどころだと思った。

その記事読んでみたい。 雑誌Volumeいくつ？

>>756
ウォータフォール信者が多いから、そういう大部分の信者にとっては損をしている気分なんだろうねえ

PGのスキルというか、良質なテストを設計できることが前提となっている。

>>766
それ以前に皆問題解決に真摯に取組む事が前提になっている。

>>766
皆、誰もテストプログラミングの威力に気づかないんだよな。
テストプログラミングをするのをみんな面倒くさがる。
テストをはやいうちにやっておけばほとんどの多くの不安が解消されるのに。

テストプログラミングはプログラマに対する不安感を減らし、
自分のプログラムに対するテストプログラムを作れば
自分の作ったコードを信頼できる、
それと同時に自分の書いたプログラムには
バグが少ないという絶対の自身をもつことができる。

ちょっとひとつのクラスを改造、拡張、修正、更新ても、その修正が
本当にあっていたのかどうか？　

それともその修正という行為間違で
修正前のコードのほうが正しかったのかかどうかがすぐにわかる。
かれらはなぜそれを実行できないのだろう。

だが皆面倒くさがる。ケントベックのテスト駆動開発入門を読めば
テストの必要性が解るとおもうのだが。XPでテストファーストを謳う理由を
も知ってしまえばテストの重要性がかなりわかるのだが。

うちのバイト先で、納期間際に顧客に突然「JUnitでテストをやれ」
いわれたらしく、JUnitを使って必死にServletのテストをしていた。
しかしJUnitだけではServletをテストするのは無謀だということがわかった。
テストのために既存のコードを修正するという悪循環を起こした。
HttpServletRequestクラスのオブジェクトとHttpServletResponseクラスの
オブジェクトを生成するほうほうがわからなかったためにそんなことをしてしまったのだという。

しかもソースコードをみるとassertと名が付くメソッドがほとんど呼び出されていなかった。
何か呼び出すかとおもったらSystem.out.println()でDBに接続できたかどうかの「接続のテスト」
を目視で確認していただけだった。そこでassertを使うべきでは？　と思ったのだが。
DBのテストにはDbUnitを使うのがお勧めではないだろうか？　と思ったときであった。
中にももっとひどいものでは、assertがつくメソッドが一つもないものだった。
ただSystem.out.println()で表示しているだけ立った。java.logging.Loggerクラスでログも
とっているらしいがテストらしいテストはろくにされていなかった。

テスティングフレームワークJUnitの正しい使い方とはいえなかったのが嘆かわしく、
勿体ない気がした。

Jakarta Cactus、 MockObjectsを使えばいいのにと思ったが、
Cactusは有償だと勘違いして一切Cactusを使いたがらない者もいた。
一人の社員と一人のアルバイトがMockObjectsを使ってテストを始めた。
私もそれを真似することでどうにかテストを作ることができた。
しかし中途半端で急いでいたためテストらしいテストはできなかった。
assertをどこに使うかがわからずとにかく値チェックをするだけにとどまった。
顧客がソースコードの行数の何パーセント分かはテスト項目にしろといういい加減な
目安でしかテストの指示を下すことができなかったようだ。
JavaやCでは無理矢理コードを一行に納めることができるというのに。それを理解できない顧客だったようだ。

いくらテストファーストと唱えたところでそもそも設計の途中じゃ
まともなテストケースを作れないんじゃないのか？
それともカバレッジなんて気にしないのか？

おれはテストファーストよりもテスト駆動開発のほうがいいと思ってる。

どのみち、テストは早めにやっておいたほうがいいと思った出来事だった。
すでにできあがっているクラスパッケージ(MVCアーキテクチャでいえばModelに相当するものに違い)を
使ってServletを作るというのだから。

そのできあがったクラスをServlet側で使うときに不安は大きく増大した。

Servlet側のバグなのかそれとも既存の自作パッケージ側のバグなのか
どちらかわからないからだ。

自作パッケージ側には対応するテストケースクラスがそれぞれのクラスに対して
あったがソースを覗いてもassert系メソッドはほとんど見あたらない。
それだけならまだいいが、DB接続のテストができない環境であることが
大きなネックだったようだ。DBの接続が悪いのかそれともこちらが悪いのか
こちら側で面倒なテストをしなければならなかった。

しかも例外処理は全部Exceptionだけしか投げないものばかりで具体的にどんな例外が投げられているかも
ほとんどわからなかった。例外を投げるところで適切な例外を投げずに
nullを返すようなコードだったようだ。例外を取り扱うのが面倒だから例外はすべてExceptionだけで
キャッチしてしまうという考え方だったようだ。

何か不足の自体が起きたらnullを投げるのではなく
極力それに見合った例外を投げた方が堅牢性が高くなるわな。

nullばかり投げて例外を投げてくれないからどんなバグがあるのか推定しにくくなる。

そのクラスを使う側はわざわざif文でnullチェックをしなければならないとは。
nullを投げるんだったら例外をスローしてくれた方がいい。
そのほうが、投げられた例外で何が間違いかがすぐにわかり
開発効率が上がるというのに。どんな間違いに対してもnullしか投げないなんて困る。
補足できる例外はぬるぽとExceptionだけというのではこちらがどんな間違いを犯したのか
それとも間違いは相手側か他にあるのかもわかりにくく不安になる。


だから、もっと設計をしっかりしてくれ。
もっとオブジェクト指向、デザインパターンを学んでくれ。頼む！

流行らせよう(w
>不足の自体

>>765
JAVA Developer 2003/12 の記事。
(JavaPress は記憶違いだった。ごめん)

PDFで全文が公開されているようだ。
http://www.javadeveloper.jp/static/200312/XP.pdf

おすすめ。

ある本に、「ＸＰを行うと、工数は 2〜3倍に増えて、品質は 1.6倍程度向上する」と書いてあった。

ということは、工数的には XP は採用しない方が良いということですか？

とりあえず、本のタイトルぐらい明記しようよ。

>>776
そんな藻前にはRational Unified Processがお勧め

品質が1.6倍というのは意味不明だけど、ＸＰで工数が膨らむのは事実。
厳しい納期で限られたリソースの場合は、とても採用できない

工数って具体的になによ？

>>780

簡単にいえば人月　
そもそもペアプログラミングで生産性が２倍にならなければ
その時点で稼動が膨らむわけだが
（ペアプログラミングによるメリット等はともかく工程そのものだけを
見た場合）

>>781
聞きたいのは人月の中身なんだけど。まぁいいや。

小さな見なおしを繰り返していく過程で工程を洗練することを推奨してるんだとおもうんだけど。
ちがうかなぁ？

>>782

具体的にどの工程が増えるかはよくわからないけど
どのプラクティスとっても人月的にはふえないか？

とくにテストファーストとペアプログラミング

機能を実装するだけでなく、そのテストプログラムも記述するわけだから、単純に工数は増える。
さらに、仕様が変更になると、テストプログラムも変更する必要があり、とっても工数膨らむ

>>783
テストファーストについては良いと思うよ。
手戻による修正にかかる工数は減るような気がする。
設計ミスもみつけやすいし・・
致命的なことは発生しにくくなると思う。
でも、テスト方法とか考える時間は増えるかもしれないなぁ。

ペアプログラミングはお互いに強い信頼関係が無いと苦い思いをするかも。

災いの芽は小さなうちに摘んでおくということか。

>781
もまえのいう"人月"とは、例えばテスト完了済みの機能数に対しての単位か?
単に人が作業した時間だけ計測しても無意味

ペアプログラミングするときは
フレックスタイム制をそのときだけ無効にしないといけなさそうだ。
お互いに同じ時間に来ないと実現できないからねえ。

片方が徹夜つけでプログラミングして
次の日昼12時になってから仕事をするようでは
朝から相棒がきてもしょうがないってさ。
2003年の春に、青山のDevelopers Conferenceである会社の社長が
そういう話をしていた。「泥沼のJavaなんとか」って話だったかな。
Javaをメインに使っている会社らしいけど、いくらXPといっても、
なにか計画をしっかりとやらないとうまくいかないんだそうだ。

それはどの世界でもあたりまえだけれども。

そんで土曜日も働くようでは
プログラミングは週40時間でいいというXPの原則を破ってしまうのである。
そんなことをいっていたよ。青山でのカンファレンスでは。

>週40時間でいい

あれ?「最適なペースで」って話だろ?

XP のプラクティスはいくつかリファクタリングされていて、
当初「週40時間労働」と呼ばれていたものは、今「最適なペース」と
呼ばれている。

ペアプログラミングで工数が増えるかどうかは、
それまでどのような技術レビューをやっていたかによる。

品質の向上や工数増加のような、一次元の評価だけを
比較しても無意味。

納期遵守率とか、開発期間あたりの機能実装数とか、
プロジェクト開始から終了までの顧客満足度とか。

要するに二次元の評価でないとダメ。
品質や工数を「機能数」や「時間」で割った二次元の評価。
あるいは、継続的な評価方法を使って比較しないと、
正しく評価したことにはならない。

まあ、今までそんなアヴァウトな評価方法で運営されてきた
ような企業は（ｒｙ

>>793

XPに見栄えがいいように評価軸を勝手に増やしただけじゃないのか？
ウォーターフォールに見栄えがいいような評価軸だって増やせることを
忘れるなよ？

やっぱ、このスレはタイトルで損してる気がする。

結局ペアプロは、稼動後の保守や機能拡張の段階に至った時にはじめて効果が出そうだな。
プログラミングの工程だけをやってる零細外注には縁のない事か・・・

> 手戻による修正にかかる工数は減るような気がする。
「気がする」とか主観的であいまいな報告じゃなくて、ちゃんとした研究報告は無いのかのー

>>793
同じ開発リソースであれば、工数が膨らめば
納期遵守率とか、開発期間あたりの機能実装数が下がるのは自明では？

>>793

> まあ、今までそんなアヴァウトな評価方法で運営されてきた
> ような企業は（ｒｙ

いい加減だからなあ。大手企業の某N社の評価方法も。
行数の何割かはテストしろって考え方がねえ。

>>795
しかし、エクストリームプログラミングの考えは
プログラマに大きく影響を与えていることは間違いないよ。
結局精神的な問題なんだよ。

EQ こころの知能指数という本とか、
ポジティブなことばかり書いて読者にやる気を起こさせる本を思い出したよ。
XPも同様に、プログラマにやる気を起こさせ仕事の能率を上げようという
考えに基づいているのだと思う。

>>800
本当にそう思ってるなら、あんた馬鹿だぜ。

XPがプログラマに与えるのはテストファーストくらいかな
ツールや言語仕様に取り込まれたりして、XPという概念そのものは消えていくかと

さびしいからカキコよろ
http://etc3.2ch.net/test/read.cgi/intro/1090568120/l50

>784
遅レスだが・・・
UnitTestはテストプログラムを記述する分だけ工数が増えるっていうのは違うんじゃないか。
非UnitTestでも単体テストってするし、ヘタにドキュメント書いてるともっと工数がかさむ場合も多いような気がする。

製造業では常識だが、PDCAという理論がある。
これは、生産的な作業は Plan→Do→Check→Action のプロセスから成る、という考え方だ。
現実には、一つの計画の実現のために Check→Action のプロセスを一回以上繰り返すことになる。
そして、PDCA理論とテストファーストのプロセスには恐るべき類似がある。
テストコードの実装(Plan)→コードの実装(Do)→テスト(Check)→コードの修正(Action)
テストファーストはXPによって発明されたのではない。製造業の常識が再発見されたに過ぎない。
――故に、その有用性はもはや実証済みなのである。

>>805
ＰＤＣＡでググッていくつか見てみろ
喪前は全然理解できてないぞ

>>802
んなことはない、
プログラミングは週40時間で済む、
ペアプログラミング、お菓子を食べながらプログラミング
するという発想は明らかにプログラマにやる気をおこさせるものだ。

>>784

　>>804の言うとおり、下手なコメントよりもテストケースのほうが信用できる。
一度テストケースを書いてしまえば、新たにプログラムに修正を加えても、
そのテストケースを基準にすることで間違いを見つけやすくなり、
「このやりかたはよくないんだな」ってことがすぐにわかり、無駄なことに時間を
費やすこともなく開発効率は高まる。

おれは、リファクタリングこそＸＰの残した成果だと思うぞ。
テストファーストより。
単体テストは複雑なケースにはあまり適さない。

俺みたいな嫌な奴とペアプロする人の身にもなってやれよ。

つーかテストしてないだけだろｗ
本人たちは単体テストという作業をしてるつもりだが、やってることは機能テストって所、たまに見るよ。

そういう現場じゃ、プログラムをプログラムでテストするって考え自体持ってなかったりする。
未だにUIもビジネスロジックもデータアクセスもごちゃまぜにした馬鹿なコード書いてる。
そもそも単体テストできるレベルのソースですらない場合も多い。
だから、ユニットテスト==めんどくさい・工数膨らむ、みたいなアホな理屈を言う。

>>810
あいつみたいなお前とペアプロしなきゃいかん人の身にもなれ。

>>810
そのときはお前をいい奴に変身させる、鍛えさせる、修行させる、リハビリさせる、矯正治療させ
ればいい。

>>811
JUnitの使い方を教えてやれ

XP 風の単体テストを初めてから、「テストしやすい設計が良い設計だ」と思
うようになったよ。逆に言えば、従来手法で良い設計とされるものの一部（実
装の隠蔽とか）は、単体テストに馴染まないことがある。

人によっては心理的抵抗が大きいだろうなぁ、とは思う。

女の子とペアプログラミングしたいな。

夜のペアプログラミング
夜のINSERT　INTO
夜の結合テスト
ﾊｧﾊｧ

>>816
お前とペアプロしなきゃいかん人の身にもなれ。

テストプログラミングをやり始めると、
なんてもっと早い時期からやっておかなかったんだろう、
って思うようになってくる。

早めにやらないと、コードが肥大化したときに、
なんでもっと早い時期にやらなかったんだろう。
もっとはやめにやっておけばどこに間違い、バグがあるのかすぐにわかったのに、
と後悔するようにもなる。

とにかく、テストファーストとまではいかなくてもテストはしておいたほうが良いに超したことはないよ。

>テストはしておいたほうが良いに超したことはないよ
ちょっとまて
しないこともあるのかYO！

人嫌いだし嫌われてるからペアプロやだ

漏れも漏れも

>>806
PDCAについて調べてみました。確かに正確に理解していなかったかも。
現在の自分の理解を書くので、何が理解できていないのか教えてください。

１．PDCAサイクルは業種に関わらず、経営レベルから現場レベルまで適用可能な
　　継続的改善を推進するためのマネジメント手法である。そのプロセスは、

　　Plan（目標設定）→→→→→Do（実施）
　　　↑　　　　　　　　　　　　　　　　↓
　　Action（変更点の特定）←←Check（評価）

　　から成る。「Plan→Do」のみから成る原始的な手法と比較すると、
　　１．「Check→Action」があることで、継続可能なサイクルとなっている
　　２．「Check→Action」があることで、目標からの乖離を抑制する
　　などの特長がある。

　　参考： http://www.atmarkit.co.jp/aig/04biz/pdca.html

２．　継続的改善と聞くと、なんとなく製品品質の向上や業務改善が目的に思えるかもしれないが、それは誤解。
　　PDCAサイクルは生産性の向上にも大きく貢献する。

　　　「生産性」というものが「目標の達成率」によって計られる。（これに異論は無いと思う。）

　　　PDCAサイクルを導入することにより、「生産能力が目標に沿わない行動に『消費』されずに、
　　目標に沿った行動にだけ『活用』されるようになる」。つまり、生産性が増えるのである。

　　　故に、PDCAサイクルは「品質」と「生産性」を同時に向上させることが可能な手法なのである。
　　50年を経てもPDCAサイクルが滅びない理由が、ここにある。

３．　テスト駆動開発（XPでは、テストファーストのプラクティスのみを指す）は、
　　PDCAサイクルを明らかに実現している。

　　Plan（テスト計画、テスト実装）→→→Do（テスト対象コードの実装）
　　　↑　　　　　　　　　　　　　　　　　　　　　↓
　　Action（変更すべき点の明確化）←←Check（自動テストの実行）

　　　他の業種への適用と比較すると、特に「Check」工程が自動化されていることが
　　大きく評価できる点である。（昼夜を問わず、定期的な自動実行さえ可能である！）
　　　結果として、極めて短い時間でPDCAサイクルを繰り返し適用することが可能であり、
　　これが「品質」と「生産性」の大幅な向上に貢献することは疑うべくもない。

追記：XPの別のプラクティスについても、後で考察してみるつもり。あと、某所に転載する予定。

>>824
× 「生産性」というものが「目標の達成率」によって計られる。
○ 「生産性」というものは「目標の達成率」によって計られる。

誤字った（恥

XPって共産主義者が使うやつでしょ。
エンジニアにも共産主義者とか自覚のない共産主義者たくさんいるんだから、
開発手法もそういう前提明確にして宣伝してもらいたい。

詭弁の特長のガイドライン

４：主観で決め付ける
11：レッテル貼りをする
７：陰謀であると力説する

　　「XPって共産主義者が使うやつでしょ。」

５：資料を示さず自論が支持されていると思わせる

　　「エンジニアにも共産主義者とか自覚のない共産主義者たくさんいるんだから、」

13：勝利宣言をする

　　「開発手法もそういう前提明確にして宣伝してもらいたい。」

それって>>827自身にも全部当て嵌まるじゃん。プ。

テスト駆動は、
簡単で不具合を一切許さない現場でははまるが、
極端に複雑で不具合をある程度許す現場でははまらない
で、上の奴らが必死に利点を言っても、下の奴らには馬耳東風、馬の耳に念仏

>>829
>極端に複雑で

機能分割が上手くいっていない予感。
どんな複雑なシステムでも単純なモジュールの集合として
実装することができるのがソフトウェア。
それが満足に行えていないってことは、SEの設計能力や、
開発者のプログラミングスキルが絶対的に足りていないってこと。

ご愁傷様。

>>830
>どんな複雑なシステムでも単純なモジュールの集合として
うは、いつの時代の人ですか？
829が言ってるのは、恐らくゲームとかタイミングがシビアで
組み合わせが爆発するようなケースのことだろ。
そもそも前提が違いすぎるんでその意味で829は馬鹿なんだよ。

まあ、熟練のテスター何人かが丸一日かけても出せない偶然出た
タイミング系バグをテスト駆動ごときで出せるわけない罠。
あとゲームの場合は、大体はリリースしたらそれで終わりなんで、
保守皆無、比較する方が間違っている

テスト駆動スレになりつつあるな。

おれはxUnitとか使ったことないんだけど、
テストコードの側にバグが入る確率ってどれぐらいなんだろうか？
ドライバやスタブがバグってるケースって結構経験あるし。

ドライバやスタブにバグがあってら大抵そこでテストが通らないので
チェックはされるでしょう。テスト通ってしまうのはしょうがないね。
後工程でバグが検出されたら、その問題の検出をテストコードについか
してさらに後のデグレードなどを防ぐって考えるべきなんじゃないかな

今のシステム、典型的なウォーターフォール。
しかも鯖環境はすべてWindows。DBぐらいOracleにしろよなと思いつつ。
もちろん言語？はASP。
こんなシステムで基本設計からやらされるのは苦痛だ。

>>815
>逆に言えば、従来手法で良い設計とされるものの一部（実
>装の隠蔽とか）は、単体テストに馴染まないことがある。

俺もそう思うときもあるけど、そのときは従来手法の理解が
間違っていたのではないかと疑うことにしている。
たとえば実装の隠蔽のルールでは、なんでもかんでも隠蔽しろとは
言っていないわけで、単体テストに馴染まないほどの隠蔽は
基準を間違っていた証拠なのではないかと。

>>836
なるほど。いい視点な気がする。

ただ、人と議論した時に噛み合わないことってない？

>835
言ってる事がムチャクチャだぞ？

>>835
そんな会社に入るなよ…

>>839
あんな言っていることがめちゃくちゃな奴を信じるのか？
どうせ自分が誤解しているだけだ。

これからの時代はＡｓｐｅｃｔＪで

アスペクト指向プログラミングの時代だ！

これでテストが楽になる！
printf, System.out.println()デバッグや
ログ処理でソースコードを汚すこともない！

最強だ！

リファクタリングだのTDDだのいうが、億単位の案件でそれらを使うことを
前提にできますか？
人員は実装技術だけでなく業務知識など経験も加味して確保するわけですが、
そうするとオブジェクト指向でリファクタリングしながらの開発手法を
適用できる技術水準を確保できることは稀でしょう。
まだ集まってもいない人員に期待してプロジェクト計画を立て受注するなんて
ことは今の自分には出来ません。
ここらへんの問題をクリアして仕事できている人(会社)があるのなら
教えてほしいもんです > 転職してー

顧客に先見性があり、時代遅れのアフォじゃなければできる。

>>842
> そうするとオブジェクト指向でリファクタリングしながらの開発手法を
テスト駆動、テストファーストは実現しにくいが
リファクタリングはしょっちゅーやってるぞ。
ツールで簡単にできるからな。

>人員は実装技術だけでなく業務知識など経験も加味して確保するわけですが、
>そうするとオブジェクト指向でリファクタリングしながらの開発手法を
>適用できる技術水準を確保できることは稀でしょう。

えー、意味がわかりません。

(特に問題なく確保できてるからかな?)

>>544
それは、「実装者の中には質の高いコードを書こうとする人もいる」
というぐらいなもので、時間プレッシャーに晒された多くの開発者は
リファクタリングなど施すこともなく、短時間勢いで書いた「動いた」最初のコードを
テストチームに投げる、そして障害がでたら対応する。時間いくらで
買われた実装者ならこうなりがち。

>>845
問題なく確保できるんだ、うちの会社では考えられない！
それはどっか腕のいいソフトハウスがあってそこから来る人は
みんなほどほどの水準って感じなの？それとも
845の社内に実装に関していい文化があって、実装要因は社内で確保している
ってことなの？

リファクタリングに必要な時間は言語や開発環境によって大きく違うし、さら
に案件によってはユニットテストが作りやすいものとそうでないものがある。
単純にソフトウェア開発といっても、内実はいろいろなので、ごく当り前に実
践している現場もあれば、なかなか浸透しづらい現場もあると思う。

某サイトの記事で
ＸＰを実務で実践してるという例が紹介されているblogがちらほらと出てきた
ってあったんだけど、誰か紹介してｸﾚ

ソフト業の場合、他の製造業と比べて少し複雑で。
言葉の定義からして共通認識が形成されていない。
　目標
目標とは何か？。納期に間に合う事か？売上か？顧客満足度か？
　生産性
単純に「売上と納期とコスト」から計算できるものなのか？
生産性向上という錦の御旗の下にいろいろな施策は行われるが、
果して「時間を短くする事」であるのか「コストを下げる事」であるのか
「品質を向上させること」であるのかを明言した文書は見た事が無い
　品質
品質とは何か？バグが無いことか？保守性の高い事か？操作性の良い事か？etc...
いったい誰にとっての品質なのか？

>850　コピペ乙

>>824
３．において「明らかに実現している」や「疑うべくもない」に危うさを感じる。

学生時代に望ましい結果になるよう実験やレポート作成をやっていた連中の危うさだ。
開発の現場において「作業者の持論 ＞ 製品・業務フローの実際」で問題を発生させ
自身では問題解決できない状態に陥っている連中を多数みてきた。
もっとも、それで処罰された奴はみたことがないがな。

>>852
＞学生時代に望ましい結果になるよう実験やレポート作成をやっていた連中の危うさだ。
これよくあるよな・・・。
新人に限らず、結構上の方にいる人間にもよくいるよ。
べきだ論を展開するも、今目の前にある問題には何の答えも出せない人間。

今目の前にある問題・・・
前の担当者から引き継いだVBのシステム
いちお完成しているという触れ込みだが
構造化すらされていない酷いソース
現場で動いている物とソースがあきらかに違う

>>854
>現場で動いている物とソースがあきらかに違う
これは前半の保守性の問題とはレベルの違う重大な問題だ
君自身がこの問題に善処出来るなら話は違うが
しかるべき人間にただちに報告し、確認してもらえ。

自動テストの網羅って難しくないですか？
特にＤＢアクセス絡む場合、テストデータの構築って自動化出来てますか？
例えばJUnitだったらsetUpメソッドにinsert書くの？tearDownでdelete？
そんな事考えてるうちに作業工程は進み、結局手でテスト。

テストファーストなんて幻想だよ

>>854
>現場で動いている物とソースがあきらかに違う
スマソ、おれが辞める前に仕掛けたトラップだ。。。

XP一度で良いからやってみたい。ペアプロをきれいな娘とやってみたい。

>setUpメソッドにinsert書くの？tearDownでdelete？

テストケースにinsert書いてるYo
deleteは(つーか初期状態に戻すのは)tearDownで

>856
Excelにテストデータ書いておけばその辺を自動でやってくれるようなテスティングツールが無かったっけ？
俺は使った事が無いけど、どっかのblogで読んで印象に残ってる。

ペアプロやりたいけど素人同士を組ませても意味無いから出来ない。
開発チームの半分が高スキルって稀じゃね？

>>860
まあ、その程度のことをやるJUnit用ちっちゃなフレームワークを
自作する、という程度のこともできない馬鹿は、Javaプログラミ
ング技術についてもう少し熟練すべきですな。

JUnitってウンコだよね。。。

>>863
誰でも使えるし、それを便利に実行できるツールがいろいろ揃ってる
ってのは便利。

設計は普通。あの程度のものに工夫の余地なんかねえし。
企画は天才。最初に思いついて作って普及させた奴の勝ち。

>863
じゃあなんで普及したんでしょうね

>>865
ウンコ馬鹿でも使えるから。

馬鹿でも使える、か。
理想的だな。

>>860
DbUnitだね。
ttp://www.dbunit.org
前のバージョン（読み取りがXMLファイルのみ）を使ってたけど、かなり便利。
が、使いこなすにはある程度ノウハウが必要だと思った。

>>856
カバレッジは、jcoverageとかJProbeとか使えば測れるよ。
ttp://www.jcoverage.com/
ちなみに出力はこんな感じ。
ttp://pbsaccounting.sourceforge.net/devel/report/

>>868
下はどう使うの？
というか、そもそも何を基準に測ってるの？
テストの抽出まで自動化の波に乗せるのは、
まだまだ不安でたまらないので教えて下さい。

>>869
基本的にJUnitの使用を前提としていて、
JUnitテストケースを実行した時に通ったコードや分岐を数える、というもの。
上の例なら、これと
ttp://pbsaccounting.sourceforge.net/devel/report/umich.cac.data.NodeField.html
これを見比べると
ttp://pbsaccounting.sourceforge.net/devel/report/umich.cac.data.test.NodeFieldTest.html
わかると思う。

詳しくは無いんだけど、ホワイトボックス・テストでいう命令網羅率は測れそうだが
それより強い網羅率（判定条件/分岐網羅など）が測れているのかどうかは知らない。
xUnit使ってるから、その辺は「テスト駆動でいけ！」ということなのかも。

とりあえず命令網羅でそれなりのカバレッジが出るようにしていけばいいんじゃないかな。
単体テストレベルでそこまで厳密な測定は、
高い厳密さを要求するプロジェクトにかかわったことが無いので
意識したことが無い。

ちなみにjcoverageは、バイトコードに手を入れて計測用のコードを加えるタイプの計測ツール。
JProbeはそういう作業は不要だった。

カバレッジとJUnitを使いたいならお徳セットもあり（DJUnit併用可らしい）
試してるがなかなか難しい
極めた香具師のレポート求ム

ttp://works.dgic.co.jp/djwiki/Viewpage.do?pid=@646A556E6974

XPなんて誰もやってないんでしょ？
ペアプロなんて見たこと無いし。
結局は現実に則していない机上の空論って所か。

上司と一対一で
口頭で簡単な仕様を言われて軽く作り
それを上司に見せて上司からフィードバックをもらう
それを何回か繰り返して
上司が客先に見せてフィードバックをする
それを何回か繰り返してリリース

てのはXP？

>>873
プロトタイピングじゃないの？

あ，そっか