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

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

eXtreme Programming Part.2

1 :デフォルトの名無しさん:02/05/10 14:40
ドキュメント作成よりもコミュニケーションやテスティングを重視する
ライトウェイトな開発手法「XP」について語りましょう。

☆前スレ
eXtreme Programming
http://pc.2ch.net/test/read.cgi/tech/989482113/l50

☆参考URL
eXtreme Programming FAQ
http://objectclub.esm.co.jp/eXtremeProgramming/

2 :デフォルトの名無しさん:02/05/10 15:27

今だ!2ゲットオォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;


3 :デフォルトの名無しさん:02/05/10 15:41
今だ!3ゲットオォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;



4 :デフォルトの名無しさん:02/05/10 16:31
for (i = 3; i < 1000; n++) {
 printf("

今だ!%dゲットオォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
", i + 1);

}

5 :デフォルトの名無しさん:02/05/10 17:30
>>4 数秒で1スレ埋まるな…。

6 :デフォルトの名無しさん:02/05/10 18:01
改行せんでエエの?(w

7 :デフォルトの名無しさん:02/05/10 18:28
>>4
n++って・・・無限ループ

8 :デフォルトの名無しさん:02/05/10 18:38
永遠に4ゲットを続けるコードか

9 :デフォルトの名無しさん:02/05/10 19:53
永遠ループ・・・
(でも1001で例外が飛んでくる罠)

10 :デフォルトの名無しさん:02/05/11 07:17
>>4-9
ワラタ

11 :デフォルトの名無しさん:02/05/11 10:13
>4-9
なるほど、これがペアプロか...

12 :デフォルトの名無しさん:02/05/11 10:15
>>11
言われてみればこれはいい例だ。

13 :デフォルトの名無しさん:02/05/11 10:22
printf("aaaaaaaaaaaaaaa
       bbbbbbbbbbbbbbbbbbbb");
こういう書き方って許されるの?
printf("aaaaaaaaaaaaaaaa"
       "bbbbbbbbbbbbbbbbb");
ならわかるけど。

14 :デフォルトの名無しさん:02/05/11 10:31
>>13
細かいとこに突っ込んじゃダメれす。
4は言語指定してませんし。

15 :デフォルトの名無しさん:02/05/11 12:30
確かにこりゃホノボノするな。うちもXPやろっかな...

16 :デフォルトの名無しさん:02/05/11 12:52
XPを導入してる人に質問。
イテレーションと検収条件はどのように関連付けてますか?
また、分割検収には成功してますか?

17 :4です…:02/05/11 15:24
最初
 今だ!nゲットオォォォォ
とした。nならfor文もnにしとこうかな…
やっぱ%dにしよう。ついでに変数もnはやめて、iに。
で、n++だけ直し忘れた。もう生きてはいけません。氏にます。


18 :デフォルトの名無しさん:02/05/11 21:35
>>17

UnitTestは、しましたか?

19 :デフォルトの名無しさん:02/05/11 23:56
test first


20 :デフォルトの名無しさん:02/05/12 02:05
今回のケースだと、どんなtest関数書けばいいの?

21 :デフォルトの名無しさん:02/05/12 02:21
>>20

今回のバグを防ぐって意味なら、どんなTestCaseでも捕捉するでしょう。
無限ループになるんだから。

そうでなく、一般的にどんなTestCaseがいいかという話なら、printfをその
ままつかっているのがテストしづらいので、fprintfにしてファイル入出力で
テストが可能にするリファクタリングからやるかな?

 俺なら。

22 :デフォルトの名無しさん:02/05/12 14:08
ケント・ベックって絶対にSIでの開発を経験したことがないとおもわれ。

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

23 :Delフサギコ ◆zE1iiRdQ :02/05/12 20:16
            ___________
    ∧,,∧    /80%程度の作業が無意味なSIでの開発経験など
  _ ミ,,゚Д゚彡_<  経験すればするほどバカになるけどね。
.=| |=U=U=| |= \___________
 | | .ミ   ミ | |
 | |ノ∪''∪. | | 俺が孫請けって廃ってた
 | |      | | 東京階乗、住友階乗のシスの開発経験は
         やらなきゃよかったです。
   世の中こんなクズ開発でやっていて
   うまくいってるんだなという社会勉強にはなりますた。

優れた人かチームなら15人でやれる所を
150人でやってるんだから...そりゃもうアンタ。

大規模っては、複数の小規模で成り立たせなきゃいけなくて
(複数の小規模に分割できなきゃ、すでにゴミプロジェクト)
その小規模単位でXPを導入するのがいいんじゃないでしょうか。

24 :デフォルトの名無しさん:02/05/13 02:29
でもXPは仕様が最後まで決まらないでしょ?
となると最後にまとまんないんじゃないの?
小規模のグループを一人の人に見立てて、グループ間でXPが
実施できるなら可能だろうけど、そんなこと可能なのかな。
当然サイクルが長くなるはずだから、よくてスパイラル、悪くすれば
サイクルが1回しか回らない=ウォーターフォールになっちゃうんじゃないかと。

25 :デフォルトの名無しさん:02/05/13 03:01
>>24
(´-`)。o ○ (・・・・・)
関連書籍嫁。

26 :HAMAIタンうおっち:02/05/14 14:43
> ふと思ったんですが。
> 顧客は自分たちの要求をかなえて欲しくて金を払うわけですから、顧客の要求
> を拒否する仕様凍結が当然だというような考え方は何か根本的に間違っている
> と思います。
> もちろん、できること、できないことがありますから顧客の要求をすべて
> 受け入れられるとは限りませんが……。

相変わらず当たり前のことうだうだいってんねー

27 :デフォルトの名無しさん:02/05/14 20:54
>>26
蟲シレ

やっぱりTest Firstって非常にお題目としてはよく聞こえるんだが
実行手順とか考えると、かなり厳しい。

どーしてもコーディング中心になってしまう。今まで大体
設計:コーディング:テスト = 2:3:1で見てたから
コーディングとテストとおなじくらい稼動がかかってかなり工数が
増える。見た目上。

ホントはそのあとのバグ修正とかの稼動とかもカウントしてみると
かなり(・∀・)イイ!!んだろうけど訴求力がない・・・Bugの修正の工数の
管理をしていなかったことに気付かされたけど、何処から
手をつけてよいのやら。

28 :Delフサギコ ◆zE1iiRdQ :02/05/14 22:45

      ∧,,∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ミ   彡  < ユニットテストと受け入れテストが
     (ミ   ミ)    \_______
      ミ   ミ 
      ∪ ∪






      ∧,,∧ サッ  / ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ミ,,゚Д゚ミ  < 混ぜこぜになっていませんか
    ⊂   @m   \_______
     ミ、,, ミ,
      .しヾJ

ピンク本の182Pを見るといいかもね
TestFirstはユニットテスト

29 :デフォルトの名無しさん:02/05/14 22:54
>>26

当たり前のことが出来ないのは何故なんだろうね?

30 :デフォルトの名無しさん:02/05/14 23:07
タコ部屋みたいなとこに入れられてXPさせられてみたいものだ

31 :デフォルトの名無しさん:02/05/15 00:14
>>30
やっぱり異性が(・∀・)イイ!!ね。
でもこのところXPに勢いを感じられない・・
やはり適用事例があまり大規模はないのだろうか。
(考え方を浸透させると言う観点から大規模に適用は厳しいのかも。)

32 :デフォルトの名無しさん:02/05/15 00:21
12畳くらいの部屋にメガネデブオタが8人でXP

33 :デフォルトの名無しさん:02/05/15 00:33
>>31
4人〜12人が適度な規模と聞いたことあるが。

34 :デフォルトの名無しさん:02/05/15 00:44
>>32
そらキツイ(藁

35 :デフォルトの名無しさん:02/05/15 00:52
俺以外はメガネっ娘でXPならサイコーだな

36 :デフォルトの名無しさん:02/05/15 01:10
>>29
はぁ?

>もちろん、できること、できないことがあります

これをあたりまえのことだといったんだが、何かご意見でも?

37 :デフォルトの名無しさん:02/05/15 01:10
メガネっ娘がX人なら、(X+1)Pですか?

38 :デフォルトの名無しさん:02/05/15 01:11
顧客の言う事はじから聞いてったら、キメラが出来あがる場合も多いぞ…

39 :デフォルトの名無しさん:02/05/15 01:20
XPライクにやってると、

設計 = コーディング
テスト = コーディング

で、一日中コーディングです。

ここ半年は、コーディングしかしてない!

40 :デフォルトの名無しさん:02/05/15 01:21
>>36
> はぁ?
> >もちろん、できること、できないことがあります
> これをあたりまえのことだといったんだが、何かご意見でも?
最初から、そこだけ引用するとか、強調するとかしてれば、よかったんじゃないの?
書き方が悪いよ、あんた。

41 :デフォルトの名無しさん:02/05/15 01:25
>>39
コーディングで全てが済むならいいではないか

42 :デフォルトの名無しさん:02/05/15 01:34
>>37 うまいこと言うね

43 :デフォルトの名無しさん:02/05/15 02:41
>>27
>どーしてもコーディング中心になってしまう。今まで大体
>設計:コーディング:テスト = 2:3:1で見てたから
>コーディングとテストとおなじくらい稼動がかかってかなり工数が
>増える。見た目上。

XPとかの話以前に、テストが1ってのはおかしくないか?
ほんとに今までコーディングに丸々3も費やしてたのか?

44 :デフォルトの名無しさん:02/05/15 03:08
>>27
その比率、デスマーチを呼びそう。

45 :デフォルトの名無しさん:02/05/15 03:13
>>29

見もふたもない要約をすれば

顧客は要求をかなえてほしくて金を出す。
プロラマはその金に見合うものを出す。
その範囲でできることもできないこともある。

ってだけのことだ。

>当たり前のことが出来ないのは何故なんだろうね?

出来ない「当たり前のこと」とは何?
まさか顧客の要求をすべてかなえるのが当たり前とでも?

結局濱井の文章は、感情や願望を表面だけ理屈っぽく書いてるだけだ。
思考のレベルが中高生。「青年の主張」かっつーの。

46 :Delフサギコ ◆zE1iiRdQ :02/05/15 09:41
> 結局濱井の文章は、感情や願望を表面だけ理屈っぽく書いてるだけだ。
> 思考のレベルが中高生。「青年の主張」かっつーの。

      ∧,,∧ サッ  / ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ミ,,゚Д゚ミ  < シャベリ場?
    ⊂   Om   \_______
     ミ、,, ミ,
      .しヾJ  

47 :デフォルトの名無しさん:02/05/15 10:31
  /⌒ヽ
 /  ●  ヽ
(●/⌒ヽ●) / ̄ ̄ ̄ ̄ ̄
 ヽ| ´∀` |ノ< しゃぶり場。
  .ゝ___ノ   \_____

48 :デフォルトの名無しさん:02/05/15 20:14
>>44
えぇ、呼ばれまくりです。全稼動の1/3くらいテストにまわしたいですが。

ウニットテスツとウザーテスツごちゃ混ぜに書いてしまいましたが
Design:Coding:Unittest:Usertest=2:3:2:2な感じになりますた。

実感としてBug曲線が変わった気が致しませぬ。
ピンサロでも読もう・・・

49 :デフォルトの名無しさん:02/05/15 21:43
XPとデスマーチ......となりあわせなのかもねー。
ぴょーこたん

50 :29:02/05/15 23:02
>>36

> 顧客は自分たちの要求をかなえて欲しくて金を払うわけですから、顧客の要求
> を拒否する仕様凍結が当然だというような考え方は何か根本的に間違っている
> と思います。

俺は、こっちが当たり前のことだと思ったから、その当たり前のことが
当たり前だと分かっていながら出来ないのは何故だろう?

って意見ですが。

51 :29:02/05/15 23:09
>>45

>出来ない「当たり前のこと」とは何?

>顧客は要求をかなえてほしくて金を出す。
>プロラマはその金に見合うものを出す。

 これかな?
 少なくとも、顧客に対して、金に見合っていると分からせて
満足させることが難しいと思うんだけど。

>結局濱井の文章は、感情や願望を表面だけ理屈っぽく書いてるだけだ。
>思考のレベルが中高生。「青年の主張」かっつーの。

 濱井氏が何を書いているかは、あまり関係ないと思うけど。

 役に立たないと思うなら無視すりゃいいだけだし。

52 :デフォルトの名無しさん:02/05/15 23:37
> 少なくとも、顧客に対して、金に見合っていると分からせて
>満足させることが難しいと思うんだけど。

これが、当たり前なんだろうか?
まず、両者は等価なものを交換してるわけだ。金と成果物。
したがって両者の立場は対等のはず。
どちらかが他方を満足させる、ものなのか?

あえてひねくれた書き方をしたが、何事にたいしても「当たり前」
なんて安直な考え方(分析を放棄しているとしか思えない)で
何か物事が解決したためしはない。

まず、「当たり前だ」という思考停止の呪縛を解く事だよ。

>濱井氏が何を書いているかは、あまり関係ないと思うけど。

俺が濱井の文章にうんざりするのは、本人は問題提起しているつもりなのか
知らんが、結局「当たり前」のことを発言したとこで終わってて、そこから
一歩もでないところだ。


53 :Delフサギコ ◆zE1iiRdQ :02/05/16 00:02
 ________
 | 52タンが     |
 |いい事言っている|
 |気がしますた。  |
 |_______|
      ||∧,,∧
      ||,゚Д゚,,;彡
      ||⊂ ~ヽ

> 役に立たないと思うなら無視すりゃいいだけだし。
うんざりしてXPMLを辞めたくなる罠

おかげでXPMLは読み飛ばしまくり。

54 :デフォルトの名無しさん:02/05/16 02:12
うちらの仕事ってサービス業らしいよ、とか言ってみるテスト。

55 :デフォルトの名無しさん:02/05/16 02:35
つーとあんたのところは何も納品しないのか?といってみるテスト

56 :デフォルトの名無しさん:02/05/16 02:39
>>55
論理の飛躍

57 :デフォルトの名無しさん:02/05/16 02:39
>>56
どこがだ?サービス業ってのを履き違えてないか?

58 :デフォルトの名無しさん:02/05/16 02:43
あとつけくわえるが、サービス業であったとしても等価交換には
わかりないわけだ。そもそもキミは、(自分なりに)物事を考えたうえで人の意見を飛躍とかいっているのか?

59 :デフォルトの名無しさん:02/05/16 02:56
>>55 >>58
>つーとあんたのところは何も納品しないのか?といってみるテスト

>サービス業であったとしても等価交換には
>わかりないわけだ

同一人物だと思うけど矛盾してるよ。
「サービス業」という言葉の定義にずれがあることも認識できないまま
一人で盛り上がってろ。

60 :デフォルトの名無しさん:02/05/16 02:59
>>55-59
プ)

61 :デフォルトの名無しさん:02/05/16 03:02
矛盾してると見えるのはあんたがサービスをその場その場で都合がいい意味で使うからだろ。
客が何にたいして金を払ってるのかといえば、[サービス]であって[満足]に対してではない。

62 :デフォルトの名無しさん:02/05/16 03:08
>>59
こんど見積もりにサービス料も加えたらどうだ(w

63 :デフォルトの名無しさん:02/05/16 07:31
(・∀・)!!スマイル は0円 です (・∀・)!!



64 :デフォルトの名無しさん:02/05/16 08:10
客に向かっては吐けない大口を叩くスレはここですか?

65 :デフォルトの名無しさん:02/05/16 08:25
チミは卑屈に媚を売ってんだろうな

66 :デフォルトの名無しさん:02/05/16 08:33
>>64
大口?そのとらえ方がそもそもおかしい。凡庸な人間だねあんたは。

67 :29:02/05/16 08:49
>>52

>> 少なくとも、顧客に対して、金に見合っていると分からせて
>>満足させることが難しいと思うんだけど。

>これが、当たり前なんだろうか?

 おれは、そう思う。

>まず、両者は等価なものを交換してるわけだ。金と成果物。
>したがって両者の立場は対等のはず。
>どちらかが他方を満足させる、ものなのか?

 いやいや、価値観の違いを利用して、お互いに特になる交換を
行うのが理想的じゃないかな?
 顧客を満足させなければならないのは、競争が働いているためだし。

>まず、「当たり前だ」という思考停止の呪縛を解く事だよ。

 だから、濱井氏は当たり前のことを、わざわざ書いているんじゃないの?
思考停止の呪縛を解こうとしているんじゃないの?
意図としては。

>結局「当たり前」のことを発言したとこで終わってて、そこから
>一歩もでないところだ

 一歩もでないのは、濱井氏の文章/議論が下手なせいもあると
思うけど、コメントを付ける方も当たり前の思考停止の呪縛から
逃れられないせいもあると思うけど。

68 :デフォルトの名無しさん:02/05/16 09:51
> 顧客を満足させなければならないのは、競争が働いているためだし。

満足とは双方が得るものだろ?

>思考停止の呪縛を解こうとしているんじゃないの?

当たり前のことをいうとどういうメカニズムで呪縛が解けるんだ?
逆に強固になりそうな気がするけど。

> 一歩もでないのは、濱井氏の文章/議論が下手なせいもあると

いいや。文章や表現が下手なだけなら、大目に見るよ。俺はね。
(本人も良かれと思って一生懸命書いてるんだろう。)
ところが根本の考え方が腐ってるから、問題なのだよ。
濱井は自分で問題をブレイクダウンしようとしない。
ひたすら問題があるとアジってるだけだ。
そnレベルも幼稚でしらける。

>思うけど、コメントを付ける方も当たり前の思考停止の呪縛から
>逃れられないせいもあると思うけど。

それならコメントをつけるほうも同罪というだけのこと。共犯だから
濱井の責任が軽くなるという理屈なのか?くだらん。

69 :デフォルトの名無しさん:02/05/16 10:22
↑のハマイタンヲチ から派生したやりとり見てて、ポカーン なんですけど、
それは、俺がしょぼいから、ついていけてないだけですか?

70 :デフォルトの名無しさん:02/05/16 13:30
ついていかなくていいんじゃない?どのみち(俺は)たいした話をしてないから。
俺が言いたいのはこーゆー話にしかならないから、濱井はこの手のXPMLで
発言するなってことだ。



71 :デフォルトの名無しさん:02/05/16 13:31
この手のXPMLで → この手の話をXPMLで

72 :デフォルトの名無しさん:02/05/16 14:52
俺が言いたいのはこーゆー話にしかならないから、>>70(とか) はこの手の話をこのスレで発言するなってことだ。

73 :デフォルトの名無しさん:02/05/16 15:51
>>72
だったら無視すればいいんじゃなの?(w

74 :デフォルトの名無しさん:02/05/16 16:16
こう、、、スレ奉行が多いね、ここ。

75 :デフォルトの名無しさん:02/05/16 17:57
Aに対するメタ議論はAダッシュで、ってことだな。

A=XPML、Aダッシュ=このスレ
A=このスレ、Aダッシュ=ここ以外のスレ

>>70はこれにそってるが、>>71はこのスレに対するメタ議論をこのスレで
やった時点で自己矛盾。

76 :75:02/05/16 17:58
71じゃなくて72だったーよ。すまそ。

77 :(・∀・)カエレ!:02/05/16 20:08
以下、引用。

このころまでに、私たちはこう確信しているはずだ。
──「こんな能書きを書くよりは、既存口座の残高
計算のコードを書く方が早く済むだろう。」

78 :デフォルトの名無しさん:02/05/16 20:25
そんなあのコもXP

79 :デフォルトの名無しさん:02/05/16 20:41
>>77
それを濱井にいってやれ。

80 :デフォルトの名無しさん:02/05/16 21:44
ちなみに満足の得られないサービスってナニ?

81 :29:02/05/16 21:51
>>70

>俺が言いたいのはこーゆー話にしかならないから、濱井はこの手のXPMLで
>発言するなってことだ。

俺が言いたいのは、こーゆー話になるのは、本人が良かれと思って
一生懸命やっているのは伝わるんだから、大目に見てやれってことだ。

 受け手によっては、それなりに役に立つと思うぞ。
反面教師って意味じゃなくてね。

82 :29:02/05/16 21:53
>> 顧客を満足させなければならないのは、競争が働いているためだし。

>満足とは双方が得るものだろ?

それはそうだけど、プログラマ側に競争原理が働いているせいで、
他のプログラマより多くの満足を与えなければならない。

当たり前のことだけどさ。


83 :29:02/05/16 21:54
>>思考停止の呪縛を解こうとしているんじゃないの?

>当たり前のことをいうとどういうメカニズムで呪縛が解けるんだ?
>逆に強固になりそうな気がするけど。

 それについて議論することで、思考停止からは逃れられる気が
するけど。
 強固になるか?

84 :デフォルトの名無しさん:02/05/17 07:15
>一生懸命やっているのは伝わるんだから、大目に見てやれってことだ。

うーん…彼なりに一生懸命だってのは認めるよ。でもね、その方法じゃ
だめなんだよ、っていってやらないとね。熱意がなけりゃ何事も出来ないが、
熱意だけじゃだめなんだが(おっさんくさいこといってるが)。

>受け手によっては、それなりに役に立つと思うぞ。

濱井とどうレベルの人間にはそうかもしれない。XPMLをそういった
種類の人間中心のMLにしたいのならね。念のためいうけど
そーゆー人間を蔑視してるわけじゃない。1つのMLに共存するのは、
他のMLをみてても、やっぱ経験的に難しい。

>他のプログラマより多くの満足を与えなければならない。

だからそれをいうなら「より多くのサービス」だってばさ。

> それについて議論することで、思考停止からは逃れられる気が
>するけど。

議論の中で新しい視点が提示されれば、そうなるだろうね。
その見込みがないからこそ、うんざりしてるんだけどね。


85 :HAMAIタンうおっち:02/05/17 10:09
>私が書いたのは、記事の批判というよりもウォーターフォール一般への批判
>になります。
>納期が長かろうと短かろうと、ウォーターフォール型の開発では仕様をある
>時点で固定してそれ以降の要求の追加、変更は拒否することになります。
>仕様通りに開発されても、必須の機能が抜けていて顧客にとっては開発の意味
>が無いというようなケースが起こり得ます。

>必要な機能を要求し損ねた顧客の責任だというような考え方もできますが、
>コミュニケーションの失敗はほとんどの場合双方にそれなりの原因がある
>ことを考えると、顧客だけが責任を負うというのは不公平でしょう。また、
>ビジネス的にもまずいやり方です。
># 現実には、顧客は仕様の全責任を負うほど弱い立場ではありませんが……。

>仕様通りに開発するという観点からは、仕様の固定は早ければ早いほど良い
>でしょうが、顧客の満足を高めるという観点からは、仕様の固定は遅ければ
>遅いほど良いことになります。
>イテレーション型ならウォーターフォール型の失敗が完全に防げるというわけ
>ではありませんが、その確率は下げることができます。

>ウォーターフォール型の開発が生き延びてきたのは、顧客の満足を高めること
>より、仕様通りに開発することが重視されてきたことに一因があるように
>思えます。

相変わらず平々凡々なご意見…
耳たこだよ。

86 :デフォルトの名無しさん:02/05/17 10:18
固定概念に凝り固まってるのは濱井の方。
ガキ並みの幼稚さと老人並みの頭の硬さ。
会社でもウザがられてるんだろうなぁ。


87 :デフォルトの名無しさん:02/05/17 10:21
濱井タンにとって批判とは同じ事を連呼することなんだろうか…

88 :デフォルトの名無しさん:02/05/17 10:25
> 濱井さんはビジネス的視点からウォーターフォール型プロセスを批判なさっていま
>すが,ソフトウェアの不具合に対する法的責任という観点からはどうでしょうか。

そういえば、XPだと仕様のドキュメントはどうなるのかな?
デスマーチだといったいわないの水掛け論があちこちで起きるけど。

89 :デフォルトの名無しさん:02/05/17 10:35
XPとウォーターフォールって社会主義と資本主義みたい。

XP=社会主義
ウォーターフォール=資本主義
※多分普通の感覚と逆の喩え

資本主義の欠点を取り除いた画期的なパラダイムの社会主義は、
結局修正資本主義に勝てなかった。


90 :デフォルトの名無しさん:02/05/17 10:43
>ウォーターフォール型の開発が生き延びてきたのは
クライアントと営業が「じゃ、今回はウォーターフォールで行きますから、よろしく」
って握手してるの想像しちゃったよ。
ウォーターフォールって、結果、だよね?
そういうのが、生き延びてるって言うのかなぁ…

91 :デフォルトの名無しさん:02/05/17 10:45
XPだと顧客が近くにいる、イテレーションが短い、
ユーザストーリーに書いてあることしか実装しない、などの理由で
あまり仕様のミスマッチは起きないんだと思う。

で、立派なドキュメントをほしがる場合は、
<立派なドキュメントを書く> というストーリーを用意して、
顧客に他の機能の実装と選ばせるんじゃなかったかなあ。


92 :デフォルトの名無しさん:02/05/17 11:29
煽りじゃなくて純粋に質問なんだけど、

立派なドキュメントは入らないが後日齟齬がおきないための「もの」が
欲しい、って場合はユーザストーリーで用が足りると考えていいのかな。

識者の意見希望。

93 :デフォルトの名無しさん:02/05/17 12:03
>固定概念に凝り固まってるのは濱井の方。

確かに。

94 :デフォルトの名無しさん:02/05/17 15:08
> だから、濱井氏は当たり前のことを、わざわざ書いているんじゃないの?
>思考停止の呪縛を解こうとしているんじゃないの?
>意図としては。

俺もXPMLの発言の中で濱井さんの意見が一番呪縛にとらわれている思うが。
第一つまらない。

95 :デフォルトの名無しさん:02/05/17 18:10
>開発者側のリスクは、契約次第ではないでしょうか?

>ほとんどのパッケージソフトでは、開発者側はソフトの欠陥に対して何の責任
>も負わないことを謳っています。法的にはこのような契約でもできるという
>ことです。
>パッケージソフトの例は極端すぎますが……。

おいおい、濱井のところはこんな無責任な姿勢で製品作ってんのか?
NECだっけ?ひでーな。顧客への迷惑をぜんぜん考えてないな。
自分に都合がいいときは顧客の満足なんたらといい、支離滅裂だ。
いろいろ理屈をつけてるが、自分のことしか考えてないんだろうな。

96 :デフォルトの名無しさん:02/05/17 18:15
最近思ったんだがデスマーチを発生させるのはプロセスではなく人だな。

結局XPは「見積もりができない人」はいない前提で作成されたプロセス。
見積もりが出きる奴しかいないプロジェクトならば、
どんなプロセスでもデスマーチは発生しにくいだろう。



97 :デフォルトの名無しさん:02/05/17 18:18
>も負わないことを謳っています。法的にはこのような契約でもできるという

そりゃ契約はなんだって出来るだろうね。商売になるかどうかはともかく。
それにしても顧客の満足度はどこにいったんだ?

98 :デフォルトの名無しさん:02/05/17 18:24
>>96
ちと違うな。ちゃんと見積もりをするようになるプロセスだ。
「ソフトウェア職人気質」じゃないが人は育つ土壌が無いと育たないよ。
その土壌を意識的に作っていこうというのが XP だと思う。

99 :デフォルトの名無しさん:02/05/17 18:26
>最近思ったんだがデスマーチを発生させるのはプロセスではなく人だな。

?そりゃ結局どんな問題も「人」に還元可能だが、それじゃ何も改良の検討も
改善の対策も出来ないんじゃないか?

 対策:精神を鍛錬する、とか(w

>結局XPは「見積もりができない人」はいない前提で作成されたプロセス。
>見積もりが出きる奴しかいないプロジェクトならば、
>どんなプロセスでもデスマーチは発生しにくいだろう。

一部同感。だがスパイラルつーかイテレーションつーか、1回の
サイクルを短くすることで見積もりの負担つーか責任を軽減して
いるのは事実。

次に方法論のパラダイムシフトがあるとすれば、プロジェクト
に適したサイクルの決定方法が大きな位置を占めると思うよ。

100 :99:02/05/17 18:35
>>98
>ちと違うな。ちゃんと見積もりをするようになるプロセスだ。

理想的にはそうだが、その割にはX見積もりの困難さにたいして
XPは何も示唆してくれない。その意味でXPは見積もりに関する
方法&責任を突き放している。

仮にXPの発展系がソフト開発の主流になることがあっても(俺はあまり
そう思ってないが)、その時のXPは今とは違う形をとっているはず。

XPを大切だと思うなら、XP自体を育てる方向で考えるべし。
救世主のようにすがり、理想だとあがめたてるようなやつらは好かん。
XPMLはそういうやつらが多い。(多いってのは量が多いんじゃなくて
少なからずいるって意味だよ。念のため。)


101 :99:02/05/17 18:42
>人は育つ土壌が無いと育たないよ。
>その土壌を意識的に作っていこうというのが XP だと思う。

この部分はそうだね。少なくともXPの狙いは。
狙い通りいくかどうかはどうかしらんが。例えば大規模なプロジェクト
を運営する人はXPでは育てられないんじゃない?少なくとも今のXPではね。


102 :デフォルトの名無しさん:02/05/17 19:00
>>100
>理想的にはそうだが、その割にはX見積もりの困難さにたいして
>XPは何も示唆してくれない。その意味でXPは見積もりに関する
>方法&責任を突き放している。
見積もりの流れはこうだな。
タスクを良く読む→コードが脳裏に浮かぶ→大体どのくらいかかるか想像がつく

この前段階のソフトウェア→シナリオ→タスクへの分解に技能がいるのは確か。
こういった分析・設計作業は熟練者が担当すればいい。

タスク単位になれば「やること」がかなり明確かつ限定されているので、
2年目くらいの新人でも大体の見積もりはできると思う。
ふむ。理想的には自分の作業量を把握できるようにするってことかな。

まあ、実地では試してないんだよなまだ。
ユニットテストやリファクタリングのような個人個人で実践できるのは導入しやすいんだが。
導入したつもりともいうが。

103 :デフォルトの名無しさん:02/05/17 19:02
>自分の作業量
自分の作業能力

やはり経験第一だな。

104 :96:02/05/17 19:08
>>99
> それじゃ何も改良の検討も改善の対策も出来ないんじゃないか?
見積もりはプロセスでなく経験が多くを占めるような気がする。
よって、プロセスを改善しても見積もりを正確に行えるようには思わない。

プロセスは「その見積もりが正確だったのかどうか」を判定しやすくして、
次回の見積もりを行いやすくするものだと思う。


105 :96:02/05/17 19:24
>>101
> 例えば大規模なプロジェクト
> を運営する人はXPでは育てられないんじゃない?少なくとも今のXPではね。
あ、それ知りたい。

・なぜ、XPでは大規模なプロジェクトを運営する人を育てられないのか?
・大規模なプロジェクトを運営する人を育てるためには、
 XPのどこを修正すればよいのか?



106 :99:02/05/17 19:25
>見積もりはプロセスでなく経験が多くを占めるような気がする。

そうだね。

>よって、プロセスを改善しても見積もりを正確に行えるようには思わない。
>プロセスは「その見積もりが正確だったのかどうか」を判定しやすくして、
>次回の見積もりを行いやすくするものだと思う。

???「次回の見積もりを行いやすくするもの」なら「プロセスを改善しても
見積もりを正確に行えるようには思わない」というのは?だが。

とはいえ、大筋いいたいことはわかる。同意できるところと同意できない
ところ半々なんだけどね。(ちなみに俺はプロセスを重視する立場だ。)


107 :99:02/05/17 19:30
>>105
>・なぜ、XPでは大規模なプロジェクトを運営する人を育てられないのか?

>>102 がちょうどいい発言しているが、

| この前段階のソフトウェア→シナリオ→タスクへの分解に技能がいるのは確か。
| こういった分析・設計作業は熟練者が担当すればいい。

この辺をどうする?

108 :96:02/05/17 19:41
>>107
> | この前段階のソフトウェア→シナリオ→タスクへの分解に技能がいるのは確か。
> | こういった分析・設計作業は熟練者が担当すればいい。
> この辺をどうする?
大規模になると「ソフトウェア→シナリオ...ではなく」
「システム→サブシステム→ソフトウェア→シナリオ...」となり
「システム→サブシステム→」の設計作業の経験ができない。

という理解でいいかな?


109 :96:02/05/17 19:54
>>106
> ???「次回の見積もりを行いやすくするもの」なら「プロセスを改善しても
> 見積もりを正確に行えるようには思わない」というのは?だが。
変ですね。訂正します。
 ・見積もりを正確に行うためにはプロセスの改善を行うよりも
  人の改善(経験を積む)を行うことが効果的
ではどうでしょう?

> (ちなみに俺はプロセスを重視する立場だ。)
設計、製造、テストの工程トータルで考えると経験よりも
プロセスの改善を行ったほうが効果的だと思います。


110 :99:02/05/17 20:38
>大規模になると「ソフトウェア→シナリオ...ではなく」
>「システム→サブシステム→ソフトウェア→シナリオ...」となり
>「システム→サブシステム→」の設計作業の経験ができない。

>という理解でいいかな?

まあだいたい。そしてイテレーションは困難になるよね。
なにか積極的に工夫をしないと。

> ・見積もりを正確に行うためにはプロセスの改善を行うよりも
>  人の改善(経験を積む)を行うことが効果的

いかに人に経験を積ませるかという視点がこれまでの方法論に欠けてい
たとは俺も思う。ソフトウェアの開発とは

 ソフトウェア
 プロセス
 人

の3つの生産・改良を有機的に連携させなければならないが、その方法は
現場で行き当たりばったりで行われていると思う。結果的にプロセス偏重や
プロセスに対する拒絶など両極端の反応を生む。


111 :デフォルトの名無しさん:02/05/17 21:00
現場レベルでプロセスについての議論ができるようになってきた
というのは XP の効果の一つじゃないかな。

112 :デフォルトの名無しさん:02/05/17 21:26
そうだね。だからよけい安直なXPマンセーやろうが失敗して、
あーやっぱりこいつらにもの考えさせるとろくなことになんねー
ってことにならないように願ってる。


113 :Delフサギコ ◆zE1iiRdQ :02/05/17 21:41
∧,,∧
ミ,,゚Д゚彡

オンサイト顧客もチームの一員だから
相談して、タスク分解お仕事助けてもらうとヨシ>>102>>107

114 :デフォルトの名無しさん:02/05/17 21:53
>>113
タスク単位への分割は実装の話で、オンサイト顧客を加えるべきではない、
と思うんですが。もちろん、分割のさいにストーリーに疑問点が生じて、
意見を求めるのは必要でしょうけど。

115 :Delフサギコ ◆zE1iiRdQ :02/05/17 22:08
  ∧,,∧,,,,,,,,,,,,,,,      / ̄
 ミ゚Д゚,,彡,,,,,,,,,,,,ヾ〜  < まちがっちゃったか…
   U U """"UU     \_
さっさと逃げ トコトコトコトコ

116 :96:02/05/17 22:17
>>110
> まあだいたい。そしてイテレーションは困難になるよね。
> なにか積極的に工夫をしないと。
うーん、積極的な工夫...難しい
# まぁ、俺が簡単に工夫できるような代物だったら他のもっと優秀な人が
# とっくに思いついてるな

> ソフトウェア
> プロセス
> 人
> の3つの生産・改良を有機的に連携させなければならないが
生産・改良にはコストがかかり、特にデスマーチプロジェクトだと
ソフトウェアの生産「だけ」にしか目がいかなくなるね。


117 :デフォルトの名無しさん:02/05/17 22:57
> うーん、積極的な工夫...難しい
> # まぁ、俺が簡単に工夫できるような代物だったら他のもっと優秀な人が
> # とっくに思いついてるな

もちろんすぐに思いつくものじゃないけど、そういうことをmlとかで
意見交換できるといいんだけどね。今のxpmlはすぐに

CMM or ウォータフォール
  vs
XP

みたいな話になって、そういった話が出来ないのが残念。

よくもわるくも題材は従来型のプロジェクトに豊富に転がってるし、まだまだ
XPの経験は豊富とはいい難いんだから、従来型の題材をXPの視点で見つ
めなおしてみる、なんて話を期待してたんだけどね。

(その意味では従来型をすべて悪とする某氏の発言スタンスはいただけない。)

> 生産・改良にはコストがかかり、特にデスマーチプロジェクトだと
> ソフトウェアの生産「だけ」にしか目がいかなくなるね。

デスマーチの最中でも、プロセスや人について考える視点は必要。
どんなに余裕のないときにも、その時の自分の能力の数%ぐらいは
それにかけるべきだと思う。数%ならその分もすべて目の前のプロ
ジェクトにかけても、効果はたかが知れているから。


118 :29:02/05/17 23:29
>濱井とどうレベルの人間にはそうかもしれない。XPMLをそういった
>種類の人間中心のMLにしたいのならね。念のためいうけど
>そーゆー人間を蔑視してるわけじゃない。1つのMLに共存するのは、
>他のMLをみてても、やっぱ経験的に難しい。
 
 でもさ、濱井氏のメールは良くも悪くもXPMLへのネタを提供して
くれているし、濱井氏がメーらなければ今よりマシになるかといえば
疑問だし。

 今のXPMLのスレッドだって、どう育つかは分からないけど、
濱井氏がコメントつけてなければ、そのまま流されていくだけ
じゃないかな?

>議論の中で新しい視点が提示されれば、そうなるだろうね。
>その見込みがないからこそ、うんざりしてるんだけどね。

 それが出来ないなら黙っとけってのは意味がない気がする。
新しい視点が提示されないのは、濱井氏がその能力がないの
が理由じゃなくて、XPML参加者の誰一人としてその能力が
ないからでしょ。

 俺としては、XPMLではXPに関する意見は稚拙だろうが大歓迎
なんだけど。
 うんざりしたときの対処の仕方は分かっているし。

119 :29:02/05/17 23:34
>俺もXPMLの発言の中で濱井さんの意見が一番呪縛にとらわれている思うが。

 俺はそうは思わないけど、べつにどうでもいい。
例え呪縛に囚われた意見でも、自分の呪縛を解く役には立つし。

>第一つまらない。

 2ch的に言えば、その場合、面白くする責任はあなたにあるのです。

120 :29:02/05/17 23:37
>>100

>XPを大切だと思うなら、XP自体を育てる方向で考えるべし。
>救世主のようにすがり、理想だとあがめたてるようなやつらは好かん。

 XPの教義では、XP自体も変化しつづける事が必須です。
最終理想形はXPには存在しないのです。

>XPMLはそういうやつらが多い。(多いってのは量が多いんじゃなくて
>少なからずいるって意味だよ。念のため。)

そういう人は、本物の信者じゃないんでしょう、きっと。

121 :デフォルトの名無しさん:02/05/18 00:28
>でもさ、濱井氏のメールは良くも悪くもXPMLへのネタを提供して
>くれているし、濱井氏がメーらなければ今よりマシになるかといえば
>疑問だし。

XPMLでもまともなスレが濱井がレスすると、その後はくだらん
レスしかつかなくなる。

たとえていえば、外来種の動物や植物が繁殖し、もとからあった
動植物の生態を脅かすようになった時、人間はどうすべきか?
といった問題。自然のままにしておくのがよいのか、もとの種を保護する
ために外来種の繁殖を抑えるべく介入すべきなのか。どっちがよい
といってるわけじゃない。こういった悩みを含めて難しい、といってる。

> 俺としては、XPMLではXPに関する意見は稚拙だろうが大歓迎
>なんだけど。
> うんざりしたときの対処の仕方は分かっているし。

どうするの?教えてくれ。あえてそういうんだから、ありきたりのもの
じゃないんだろうね。ありきたりのものでも有効ならよいけど。

122 :29:02/05/18 00:51
>XPMLでもまともなスレが濱井がレスすると、その後はくだらん
>レスしかつかなくなる。

 そうそう、それはくだらんレスを書く奴が悪いんだろ?

>どうするの?教えてくれ。あえてそういうんだから、ありきたりのもの
>じゃないんだろうね。ありきたりのものでも有効ならよいけど。

 ありきたりのものじゃないものを期待させてしまった?

 べつに読まなきゃいいだけジャン。
 それとも誰かに強制されているのか?


123 :デフォルトの名無しさん:02/05/18 00:56
漏れは29が屁理屈並べて濱井タンを持ち上げる動機の方が知りたい。
まさか濱井タンにならって人の神経逆なですることがスレの活性化につながるなんて
思ってないよね?

124 :29:02/05/18 01:10
>漏れは29が屁理屈並べて濱井タンを持ち上げる動機の方が知りたい。

 なんで、そんなに濱井氏をこきおろすのか理解できないから、かな。

 最近のXPMLって、ただの連絡MLになっている気がしない?

>まさか濱井タンにならって人の神経逆なですることがスレの活性化につながるなんて
>思ってないよね?

 まさか2チャンねらーが、あの程度で神経を逆なでされるとは
思ってないんだけど。

 日下部タンに修行してもらったほうがいいんじゃない?

125 :Kusakabe Youichi:02/05/18 01:20
>>124
>日下部タンに修行してもらったほうがいいんじゃない?

私が修行するとははつみみです。

126 :デフォルトの名無しさん:02/05/18 01:24
>>125

あなたは誰ですか?

127 :Kusakabe Youichi:02/05/18 01:25
>>126
> あなたは誰ですか?

誰ではありません。

128 :Kusakabe Youichi:02/05/18 01:25
>>126

人に問う前にまず名乗ってはどうですか?

129 :判定:02/05/18 01:27
>>128より>>127の方が本物っぽい。

130 :デフォルトの名無しさん:02/05/18 01:38
変なもん召喚しやがって・・・
責任取れよ>29

131 :デフォルトの名無しさん:02/05/18 02:19
おれも29がなんでここまで濱井を擁護するのか不思議だね。
割り込んですまんが、

>>XPMLでもまともなスレが濱井がレスすると、その後はくだらん
>>レスしかつかなくなる。

> そうそう、それはくだらんレスを書く奴が悪いんだろ?

濱井のレスがそもそも下らんのだ。

> べつに読まなきゃいいだけジャン。
> それとも誰かに強制されているのか?

健全なスレの流れが止まるんだよ。みんなそれを嫌がってるわけ。
そんなこともわからんやつはどうこういうしかくない。わかった上で
メリットがあるというならそれを説明するのが、誠意あるレスじゃないのか?

132 :デフォルトの名無しさん:02/05/18 02:20
>>127
そのレス気に入った。今度使わせてもらうよ。

133 :デフォルトの名無しさん:02/05/18 02:23
> 最近のXPMLって、ただの連絡MLになっている気がしない?

下らんレスにうんざりしてみんなが発言を控えるからだ。
その原因は濱井にある。

134 :デフォルトの名無しさん:02/05/18 02:27
>漏れは29が屁理屈並べて濱井タンを持ち上げる動機の方が知りたい。

屁理屈どうしで気が合うんじゃないか、きっと。

135 :デフォルトの名無しさん:02/05/18 02:32
HAMAIあげ

136 :デフォルトの名無しさん:02/05/18 02:41
>>>XPMLでもまともなスレが濱井がレスすると、その後はくだらん
>>>レスしかつかなくなる。
>>
>> そうそう、それはくだらんレスを書く奴が悪いんだろ?

>濱井のレスがそもそも下らんのだ。

29は濱井のレスに対するレスは下らないと認めているようだが、
濱井のレスがくだらないとは認めていないようだね。
俺にはどっちも同質に見えるんだが、違いを説明してくれないか。

137 :デフォルトの名無しさん:02/05/18 02:42
つーか29はXPMLをまともに読んでないだろう?

138 :29:02/05/18 02:43
>健全なスレの流れが止まるんだよ。みんなそれを嫌がってるわけ。
>そんなこともわからんやつはどうこういうしかくない。

それがわからんから、どうこういってるんだけど・・・。

procimprovMLなんか閑古鳥だけど。

139 :29:02/05/18 02:47
>>136

メタ議論や罵倒はくだらないと思うけど、それ以外はくだらないとは思わないよ。

で、メタ議論や罵倒になるのは、濱井氏の文章が下手なせいだと思っていて、
でも悪意があるようにも見えないから大目に見てやればいいと思っている。

136はXPMLで、たとえばどんなスレが良いスレだと思った?

140 :29:02/05/18 02:54
>>138

 補足だけど、わからないのは、
「健全なスレの流れってどんなの?」ってところです。

 「濱井氏の投稿が気に触る」から嫌がっているのなら、理由としては納得が
行くんだけど、もしそうなら読まなきゃいいだけだし・・・。

141 :Delフサギコ ◆zE1iiRdQ :02/05/18 03:19
>もしそうなら読まなきゃいいだけだし・・・。

 ∧,,∧
ミσ゚Д゚ミσ ということにしたいのですね。
         怖がらなくてもいいのにー

  ∧,,∧
((ミミ゚Д゚;ミミ))ガクガクブルブル

あの人にも[読まなきゃいいだけ攻撃]が
有効だったらよかったのにね。

まあ、とりあえず、HAMAIってヘッダにあるメールは振り分け設定したらどうです?
あ、本文の振り分け条件にもHAMAIをいれると
関連スレが全部ゴミ箱逝きになって幸せかも。

142 :デフォルトの名無しさん:02/05/18 03:31
>>141
>あの人にも[読まなきゃいいだけ攻撃]が

この一文で29がだれだかわかったよ。むかしfjで某氏からんで、
もののみごとに叩き返された人だろう?「こんにちは」

>>29
あんたにはこの手の話は無理だよ。都合悪くなると逃げるし。
しょせんあんたはどのmlにも浅くしか関わらないんだろ?


143 :デフォルトの名無しさん:02/05/18 03:40
>まあ、とりあえず、HAMAIってヘッダにあるメールは振り分け設定したらどうです?
>あ、本文の振り分け条件にもHAMAIをいれると
>関連スレが全部ゴミ箱逝きになって幸せかも。

いや、健全なスレの流れが止まるのがいやなのだから、
その方法では解決しない。

>「健全なスレの流れってどんなの?」ってところです。

それをあなたに説明する気はないね。そんなもの簡単に
説明できるものではないことをわかってて聞くわけだろうし。


144 :デフォルトの名無しさん:02/05/18 03:54
>で、メタ議論や罵倒になるのは、濱井氏の文章が下手なせいだと思っていて、
>でも悪意があるようにも見えないから大目に見てやればいいと思っている。

大目に見るのは勝手だけど、腹を立てる人間もいるという認識はないの?
腹を立てるのが正しいのか正しくないのかは多分意見が食い違うと思うけどね。

1.腹を立てる人間が存在する事実がないと思っている。
2.腹を立てる人間が存在しているのは知っているが、なぜ腹を立てるかが理解できない。

どっち?

145 :デフォルトの名無しさん:02/05/18 03:57
29 vs その他 は 濱井 vs その他 の図式とそっくりだな。29と濱井が両方とも
屁理屈っぽいとこまで。そんなに気が合うなら29が濱井の相手してやれよ。

146 :デフォルトの名無しさん:02/05/18 04:00
(´-`).。oO(XPML並につまんないスレだ…)

147 :デフォルトの名無しさん:02/05/18 04:04
もしかして29は濱井の兄では?

148 :デフォルトの名無しさん:02/05/18 04:06
濱井タンの家族はみんなあんなんなんですかハァハァ

149 :デフォルトの名無しさん:02/05/18 04:08
濱井の{母,主治医,家臣,...,飼い主}です。この度は以下略です。

150 :デフォルトの名無しさん:02/05/18 04:10
29って誰よ?説明きぼーん

151 :29:02/05/18 04:13
>大目に見るのは勝手だけど、腹を立てる人間もいるという認識はないの?

 そういう認識はあるよ。あなたがどっちなのかはわからないけど。

>腹を立てるのが正しいのか正しくないのかは多分意見が食い違うと思うけどね。

 腹を立てるのに正しいも正しくないもないでしょう?主観なんだし。

>1.腹を立てる人間が存在する事実がないと思っている。
>2.腹を立てる人間が存在しているのは知っているが、なぜ腹を立てるかが理解できない。

 腹を立ててない人間にとっては、濱井氏の投稿は役にたっていると思っている。

 現にレスをつけている人間はいるわけだし。(まさか、自作自演?)

 腹を立てる人間を優先したら、誰も発言は出来ないと思いませんか?
どっち?


152 :29:02/05/18 04:14
>>150

 おれもー。



153 :29:02/05/18 04:17
>>「健全なスレの流れってどんなの?」ってところです。
>それをあなたに説明する気はないね。そんなもの簡単に
>説明できるものではないことをわかってて聞くわけだろうし。

 仕方ないですね。
 多分、あなたにとっての健全と俺にとっての健全は違うってことは
推測が尽くし、それで十分です。

 みんな(?)は、どうだか知らないけど。

154 :デフォルトの名無しさん:02/05/18 04:26
> 腹を立てるのに正しいも正しくないもないでしょう?主観なんだし。

「嫌がる理由がわからない」と聞いてきたのはそっちだろ。説明するために、何が
わからないか聞き返しているのに、主観なんだから正しいも正しくないも
ない、とはなんなわけ?人を食ったレスに感じれるけど?

腹を立てる人間がいて、一方で腹を立てない人間がいる、なら双方の
意見を聞くのが筋だと思うが、「主観なんだから」でそれ以上の議論を
放棄している。放棄するなら、最初から首をつっこむなよ。

>腹を立ててない人間にとっては、濱井氏の投稿は役にたっていると思っている。

> 現にレスをつけている人間はいるわけだし。(まさか、自作自演?)

> 腹を立てる人間を優先したら、誰も発言は出来ないと思いませんか?
>どっち?

そんな簡単な理屈なら、罵詈雑言誹謗中傷も、腹を立てない人間がいて、
そういった人間が楽しむ役に立っているのだから、発言してもよいんだろうね。
屁理屈に屁理屈で応戦するほどむなしいものはないから、まともな理屈に
もどってくれないか?その気があるなら。

155 :デフォルトの名無しさん:02/05/18 04:52
HAMAIあげ

156 :デフォルトの名無しさん:02/05/18 05:40
延々と激しくスレ違いの実感

157 :ペアプログラミングの予感:02/05/18 06:20
Martin「激しく不吉な匂いのするスレだな」
Beck「禿同。リファクタリングが必要だね」


158 :デフォルトの名無しさん:02/05/18 08:18
閑古鳥の方がまだましだな。
実りある議論がなされてるとは言いがたい。
まさか、この流れで「スレの活性化」とか思ってやしないだろうな?>>29

HAMAI氏がメール投げることでレスはたくさんつくが、それをきっかけに実りある議論が展開されてるか?
俺はされてないと思うが。
だから「黙れ」と言っている。
それで閑古鳥になるのであれば、語るべきことがないというだけでは?
そちらのほうがまだましだ。

159 :29:02/05/18 12:13
>> 腹を立てるのに正しいも正しくないもないでしょう?主観なんだし。
>「嫌がる理由がわからない」と聞いてきたのはそっちだろ。説明するために、何が
>わからないか聞き返しているのに、主観なんだから正しいも正しくないも
>ない、とはなんなわけ?

 正しいか正しくないかには拘ってないって意味です。
 「腹を立てるのは間違っている!!」って言っても仕方ないと思うし。

 正しいか正しくないかではなくて、「何故で腹を立てるのか?」って
理由を遡るほうがまだ興味があるし。

>「主観なんだから」でそれ以上の議論を 放棄している。

 正しいか正しくないかについては議論を放棄します。
腹を立てる人間がいて、一方で腹を立てない人間がいる中で、
双方が幸せになるためにはどうするか、なら継続する気は
あるけど既にスレ違いだし・・・。


160 :29:02/05/18 12:18
>そんな簡単な理屈なら、罵詈雑言誹謗中傷も、腹を立てない人間がいて、
>そういった人間が楽しむ役に立っているのだから、発言してもよいんだろうね。

 だから程度の問題として、罵詈雑言誹謗中傷ほどひどい発言をしてるのか?
 俺はそんな風には思えないけど、ってのがそもそもの考えです。

>屁理屈に屁理屈で応戦するほどむなしいものはないから、まともな理屈に
>もどってくれないか?その気があるなら。

 屁理屈のつもりは全くないけど。

161 :29:02/05/18 12:24
>閑古鳥の方がまだましだな。

 やっぱり、そうなの?

>実りある議論がなされてるとは言いがたい。
>まさか、この流れで「スレの活性化」とか思ってやしないだろうな?>>29

 ここのスレは思わない。スレ違いだし。

>HAMAI氏がメール投げることでレスはたくさんつくが、それをきっかけに実りある議論が展開されてるか?
>俺はされてないと思うが。

[XP-jp:03446] FYI: [NOS] 仕様変更に打ち勝つ
からのスレも、
[XP-jp:03318] ソフトウェア職人気質
からのスレも、ない方がましって思うのかな?


162 :デフォルトの名無しさん:02/05/18 12:35
>>29
>だから程度の問題として、罵詈雑言誹謗中傷ほどひどい発言をしてるのか?
>俺はそんな風には思えないけど、ってのがそもそもの考えです。

俺はそんな風に思えるので罵詈雑言誹謗中傷しますです。
だからと言って、そんな風に思えない君にとやかく言ったりはしない。
わかった?


これは主観だが、言葉遊びしてるだけで本質から離れていってるような感があるなあ。
彼よりタチ悪い。

163 :デフォルトの名無しさん:02/05/18 14:33
>>161
やっとml読んだの?w

どのスレも濱井がレスしなきゃ、また別な方向への展開があった。
濱井のレスは短絡的で底が浅い。XPの話なんてこれじゃ出来ないじゃないか。

164 :デフォルトの名無しさん:02/05/18 14:50
>>> 腹を立てるのに正しいも正しくないもないでしょう?主観なんだし。
>>「嫌がる理由がわからない」と聞いてきたのはそっちだろ。説明するために、何が
>>わからないか聞き返しているのに、主観なんだから正しいも正しくないも
>>ない、とはなんなわけ?

> 正しいか正しくないかには拘ってないって意味です。
> 「腹を立てるのは間違っている!!」って言っても仕方ないと思うし。

一見謙虚に見えるが、結果的にまじめな議論を放棄していることになる。


>正しいか正しくないかではなくて、「何故で腹を立てるのか?」って
>理由を遡るほうがまだ興味があるし。

だからそれを議論するための準備をしていると言ってるだろうが。
まず、相手の意見を正しいと思わなくても、そういう意見があることは
認めるのか、と聞いてるわけだ。

あんたには自分とは異なる意見に対して(同意できなくても)理解
使用とする姿勢が感じられない。

>>「主観なんだから」でそれ以上の議論を 放棄している。

> 正しいか正しくないかについては議論を放棄します。
>腹を立てる人間がいて、一方で腹を立てない人間がいる中で、
>双方が幸せになるためにはどうするか、なら継続する気は
>あるけど既にスレ違いだし・・・。

あのさ、それなら最初から発言しないでくれないかな。

  1.まず、あんたは濱井に対して腹を立ててる人間がいるということは
  わかっているという。

  2.ところが腹を立ててる人間にたいして、それは間違っている(正しくない)
  のではないか、と議論することは放棄している。

  3.意見の相違をそのままにして双方が共存できる(幸せになれる)
  方法の模索はスレ違い(だからここではやらないほうがいい)

それで、あんたは何を言うために出てきたわけ?

濱井の場合表現は過激で直情的だが、その分純粋でいいたいことも
わかりやすいから、正直悪い気持ちはしない。
(健全なスレの展開を妨げるから文句があるが、それは別な話)

あんたの場合表現はソフトだが、無責任にたいした主張もなくふわふわ
と口を挟んでいるだけで、いささか不愉快だ。

1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
するが、どうなん?


165 :デフォルトの名無しさん:02/05/18 14:53
>俺はそんな風に思えるので罵詈雑言誹謗中傷しますです。
>だからと言って、そんな風に思えない君にとやかく言ったりはしない。
>わかった?

>これは主観だが、言葉遊びしてるだけで本質から離れていってるような感があるなあ。
>彼よりタチ悪い。

同意。濱井も29も内容のない言葉遊びが好きなだけだ。mlを暇つぶしの場だと
あまく考えてるんじゃないか?不真面目だ。

166 :デフォルトの名無しさん:02/05/18 15:00
age

167 :デフォルトの名無しさん:02/05/18 15:12
暇つぶしの場に決まってるじゃねーか(ワラ

168 :デフォルトの名無しさん:02/05/18 15:12
>[XP-jp:03446] FYI: [NOS] 仕様変更に打ち勝つ
>からのスレも、
>[XP-jp:03318] ソフトウェア職人気質
>からのスレも、ない方がましって思うのかな?

何度もいうが、スレがある/ないが問題ではない。スレの流れが、
不健全な方向へいく、といってる。

| [XP-jp:03318] ソフトウェア職人気質

のようにほんの紹介はいい。その先もしばらくまともだ。正直、俺は濱井
を見直しかけた。ところが

| [XP-jp:03359] Re: ソフトウェア職人気質

この辺りが言葉遊びでない健全な議論といえるのか?

| [XP-jp:03446] FYI: [NOS] 仕様変更に打ち勝つ

のスレも

| [XP-jp:03450] Re: FYI: [NOS] 仕様変更に打ち勝つ

この程度ならかわいいものだ。実質的に内容がゼロだが、たまにこの程度
の発言をするなら許そう。

| [XP-jp:03462] Re: FYI: [NOS]仕様変更に打ち勝つ

ところがすぐにいつもの同じ話に戻ってしまう。その都度表現は変えてても、
実質的に内容がなく、同じ事の繰り返しで、うんざりだ。

だいたい
| [XP-jp:03451] Re: FYI: [NOS] 仕様変更に打ち勝つ
ですでに指摘されているように、元の記事の内容と濱井の発言内容の
主旨はマッチしない。

別の話をしているところに、ちょっとしたきっかけを見つけて強引に割り
込んで、いつもの持論を展開する場にしてしまう態度が「犯罪的」だというのだ。

こうした濱井の態度のどこが健全なんだ?

169 :デフォルトの名無しさん:02/05/18 15:27
濱井 をNGワードにしますた。

170 :デフォルトの名無しさん:02/05/18 15:46
濱井タンも29も軍事板の某研を見習えばいいのにね。
どんな話題でもレールガンネタに持っていくのに住人からは愛されてるよ。

171 :デフォルトの名無しさん:02/05/18 15:56
浜井氏ねage

172 :デフォルトの名無しさん:02/05/18 16:10
ML の話はどうでもいい。
無駄な議論をしている点であんたらが濱井とどう違うのかわからん。
このスレでも逝ってくれ。

ニュース、MLキチガイリスト
http://pc.2ch.net/test/read.cgi/unix/970678691/

173 :デフォルトの名無しさん:02/05/18 16:26
>>172

ここはXPMLヲチスレですよ。
知らなかったの?

174 :デフォルトの名無しさん:02/05/18 17:10
はまいタンうおっちスレ立てようか(w

175 :デフォルトの名無しさん:02/05/18 17:17
はまいタンがうざい理由は168の最後の記述がもっとも的を射ていると思う。
はまいタンの行為は荒らしと同じだからやめてほしい。

176 :デフォルトの名無しさん:02/05/18 17:38
ガイシュツだが29はmlを読まずに発言してるに256void。

177 :Delフサギコ ◆zE1iiRdQ :02/05/18 17:57
     オーシ   _____________
   ∧,,∧∩  /
  ミ,,゚Д゚彡 < XPMLをヲッチするぞ!
   U  ミ   \____________
 〜ミ  ミ
   ∪''∪ 胸がムカムカムネムネしませんように。

>>168さんのカキコは
とても、鋭い分析ですね。

これからも、168さんの
鋭い分析をヲチだ!

自分がなんとなく感じる不快感の理由が
人の分析によって、明らかになるのは
なかなか気分よさげ。だし勉強になるです。

XPスレ以外にXPMLヲチスレがあってもいいかも。
そっちのが大人気になりそうだが。

178 :29:02/05/18 18:51
>あのさ、それなら最初から発言しないでくれないかな。

>  1.まず、あんたは濱井に対して腹を立ててる人間がいるということは
>  わかっているという。

>  2.ところが腹を立ててる人間にたいして、それは間違っている(正しくない)
>  のではないか、と議論することは放棄している。

>  3.意見の相違をそのままにして双方が共存できる(幸せになれる)
>  方法の模索はスレ違い(だからここではやらないほうがいい)

>それで、あんたは何を言うために出てきたわけ?

 まあ、もともとは>>29で書いているように、当たり前のことをMLに書くと
何故嫌われるのか疑問だったからなんだけど、あなた(名無しだから
一人かどうかは分からないけど)が真面目に相手をしてくれるもんだから
甘えて話を継続してしまいました。

 ここがXPMLウォッチスレならスレ違いじゃないんだろうけど、
そうじゃないんで、終了します。

>あんたの場合表現はソフトだが、無責任にたいした主張もなくふわふわ
>と口を挟んでいるだけで、いささか不愉快だ。

 そうだね。主張がないわけじゃないけど、それを伝えられないのは、
単にスキル不足です。

>1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
>するが、どうなん?

 とりあえず、濱井氏に関してはこれ以上はないです。
 疑問もだいたい解けたし。

1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
するが、どうなん?


179 :29:02/05/18 18:52
>>162
>俺はそんな風に思えるので罵詈雑言誹謗中傷しますです。
>だからと言って、そんな風に思えない君にとやかく言ったりはしない。
>わかった?

 わかりました。

180 :29:02/05/18 18:59
>>168
>別の話をしているところに、ちょっとしたきっかけを見つけて強引に割り
>込んで、いつもの持論を展開する場にしてしまう態度が「犯罪的」だというのだ。
>こうした濱井の態度のどこが健全なんだ?

 そこに拘りがあるんでしょうね。
 で、そこをスタート地点にしたいのに、スタート地点の同意が得られないから、
議論にならない。
 議論にならないから、また別の話題でもスタート地点を持ち出しては議論に
ならない、を繰り返している気がします。

 だれかうまく誘導してあげられる人がいればいいのにな、とは感じます。



181 :デフォルトの名無しさん:02/05/18 19:00
>>152
だったら自分で名乗りなよ。
俺があんたの名前をばらすのはフェアじゃないから、俺はだまってるが。ばらしたとこで、とくに意味ないし。

182 :デフォルトの名無しさん:02/05/18 19:00
>>178

> とりあえず、濱井氏に関してはこれ以上はないです。
> 疑問もだいたい解けたし。

じゃあ、もう消えたら?
ウザイだけだし。

183 :オッサン:02/05/18 19:01
スレ名見て流し読みしたが、損した。

184 :29:02/05/18 19:02
>>182

そうですね。消えます。

185 :デフォルトの名無しさん:02/05/18 20:25
>>184
で、あんたんは何のためにこれだけ書き込んだんだ?
かき回すだけかき回して、何か得るものがあったのか?
口をはさんできてかき回し、これ以上議論する気はないと一方的に宣言して去っていくのが、あんたのルールなのか?

ふざけんじゃねーよ


186 :デフォルトの名無しさん:02/05/18 20:55
>>185
やめとけ。
また出てこられても困る。

187 :デフォルトの名無しさん:02/05/18 21:00
>>178
> まあ、もともとは>>29で書いているように、当たり前のことをMLに書くと
>何故嫌われるのか疑問だったからなんだけど、

つまらんからだろ?壊れたレコードのように同じことの繰り返しだから、
聞いてる方はうんざりする。

>                             あなた(名無しだから
>一人かどうかは分からないけど)が真面目に相手をしてくれるもんだから
>甘えて話を継続してしまいました。

少なくとも俺れ一人じゃないな。何人いるのかは俺もわからんけど。

> ここがXPMLウォッチスレならスレ違いじゃないんだろうけど、
>そうじゃないんで、終了します。

Delフサギコさんの許可が出た。終了せずに存分にやろうじゃないか。
それとも都合が悪くなったから後始末もせずに逃げるのか?

> そうだね。主張がないわけじゃないけど、それを伝えられないのは、
>単にスキル不足です。

伝えたい主張が間違ってるから伝わらないのかもしれないぞ?
俺はあんたの言いたいことがなんとなくわかるよ。けどそれは間違ってると
思う。その溝を埋めるには言葉を交わすしかないだろ?それが面倒だとか
伝わらないからむなしい努力だというなら、最初からでてくるな。

> とりあえず、濱井氏に関してはこれ以上はないです。
> 疑問もだいたい解けたし。

>1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
>するが、どうなん?

1〜3を議論する気があるのだな?しかし1〜3はどれも濱井に関すること
だから、あんたの言ってることは矛盾しているのだが?

よくわからんが、とりあえず

>  2.ところが腹を立ててる人間にたいして、それは間違っている(正しくない)
>  のではないか、と議論することは放棄している。

この2.の議論を続けてもらおうじゃないか。腹を立てることが正しいか否かだ。
俺は正しいと思い、理由はすでに説明した。説明が不足しているなら要求せよ。
そうでなければ反論があるはずだから、反論せよ。それもないなら同意してくれる
のだろ?

まじめに相手をするといったい以上、相手をしてくれ。


188 :187:02/05/18 21:06
>そこに拘りがあるんでしょうね。

こだわりがあるからといってmlを自説を宣伝する場にしてよいわけは
ないだろう。自説を発表するのはよい。が、濱井がやってるのは宣伝だ。
何度も何度も同じ事を繰り返す宣伝だよ。

> で、そこをスタート地点にしたいのに、スタート地点の同意が得られないから、
>議論にならない。

別の話をしているところに割り込んで、自説の宣伝のスタート地点に
する行為に同意するような人はいない。

> 議論にならないから、また別の話題でもスタート地点を持ち出しては議論に
>ならない、を繰り返している気がします。

それが迷惑だといってるのだ。迷惑なのを迷惑というのは「正しいか正しくないのか?」

> だれかうまく誘導してあげられる人がいればいいのにな、とは感じます。

自分でやれよ。なに気取ってるの?

189 :デフォルトの名無しさん:02/05/18 21:45
fjってこれのことか?こいつが29かどうかは知らないけど。なんとなく書き方が似てはいる。
ttp://blade.nagaokaut.ac.jp/~poffice/news2/fj.comp.oops/134

190 :デフォルトの名無しさん:02/05/18 23:11
またえらく古いものを掘り出してきたね。

191 :デフォルトの名無しさん:02/05/18 23:41
190=29?


192 :fe:02/05/18 23:56
>>189
違うとおもいますよ.
彼は,段落の先頭に空白でインデントしないもの.

193 :デフォルトの名無しさん:02/05/19 00:05
ふむ。それに暴いたところで意味ないし。

194 :デフォルトの名無しさん:02/05/19 00:13
影でうざいとか言ってないで、MLで指摘すれば?



195 :デフォルトの名無しさん:02/05/19 00:14
んなことしたら荒れるだろ

196 :デフォルトの名無しさん:02/05/19 00:21
>>180
> で、そこをスタート地点にしたいのに、スタート地点の同意が得られないから、
>議論にならない。

スタート地点?なんだそりゃ。濱井がしたい議論てのは何だ?
濱井の望みどおりの不毛な議論にはなってるぞ。



197 :デフォルトの名無しさん:02/05/19 00:32
>>196

もうその辺で勘弁しといてやれよ。
今ごろ布団噛んで涙流してるよ。

198 :デフォルトの名無しさん:02/05/19 00:34
>>192
そんなこというから、ログから空白でインデントしてるメールを探しちゃったじゃないか(笑

199 :デフォルトの名無しさん:02/05/19 03:22
>1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
>するが、どうなん?

> とりあえず、濱井氏に関してはこれ以上はないです。
> 疑問もだいたい解けたし。

>1〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
>するが、どうなん?

これって前スレの952辺りで反濱井タン側の誰かが使った煽りだよね。

>>この部分,論理が飛躍していますね。
>>彼らが口先だけだという根拠を示さないとこの部分は駄目
>>になりますよ。
>>こういう論理の飛躍をしないように鍛えるためにも長文で
>>あろうと要約文であろうと,もうすこし根性入れて書いた
>>方がよいと思いますよ.

>この部分,論理が飛躍していますね。
>彼らが口先だけ  でない  という根拠を示さないとこの部分は駄目
>になりますよ。
>こういう論理の飛躍をしないように鍛えるためにも長文で
>あろうと要約文であろうと,もうすこし根性入れて書いた
>方がよいと思いますよ.

多分29は自分がやられて煽りをまねたんだと思うけど、そうなると
29=前スレの949だ。


200 :デフォルトの名無しさん:02/05/19 03:38
前スレ949の発言は

>MLは修行の場としてふさわしいです。
>みんな修行しているんですよ。
>貴方のように逃げてばかりだと,彼とどんどん差が出来ます。

とつづく。彼とは濱井タンを指すだろうから、濱井タンに俺たちは
どんどん差をつけられると、29はいいたいわけだ。

さらにさかのぼるとおそらく前スレの949=前スレの940と思われ。
940の発言は

>まず,濱井さんが発言してくれるお陰で話が広がり,時より思わ
>ぬ収穫があるので俺は許容できるんだけどな。
>例えば,みんなが畏まって論理的に賢そうに書いていると,だん
>だん敷居が高くなって,発言する人が減って,得られることがす
>くなくなるんじゃないかなぁ。
(略)
>ンが入るよね。学生の時ってさ議論がしたくてたまらないときだ
>から,ちょっと論理的に書くことを知るとそうでない書き方をし
>ている人を見切った様にいってしまうけど,人間が丸くなってく
>るとそういう見栄を張らなくなるから気軽に意見を言えるように
>なるような気がするだ。最近気が付いたことなんだけど。
>実は,俺の上司がそうなんだ。とっても賢い人なんだけどそうは
>見せないないんだよね。ゆとりがあるというか。

>そういう風に考えるとさ,50歳に満たない人が,恥を恐れずに
>思った事を書けるってそれだけで偉いと俺は思うよ。だって,日
>本中の技術者に知られちゃうんだよ。
>そう思うと,濱井さんもその偉い一人じゃないかな。
>きっと,素直で実直ないい人なんじゃないかな。

普通に見れば、議論がしたくてたまらない学生のようなギスギスの
文章を書くのが濱井タンだ。ところが940はそれをあろうことか、
50を過ぎて丸くなった人間と同じだからすばらしいといっている。
しかも若いにもかかわらず50過ぎの非常に人間が出来た人と
同じ境地に達している(常人にまねできないような)偉い一人だそうだ。

正反対のものを同じだと結びつけるこの論法は見事だが、
いったいこれはなんなの?

本当の恐怖を知らないガキと恐怖を乗り越えて戦う兵士が、同じように
勇敢だといってるのかな。

なんでここまで濱井タンを持ち上げるんだろうか。利害関係者としか思えない。
あるいは濱井の恋人?ここまであばたもえくぼ的な考えをする人って、それ
ぐらいしか想像つかないんだけど。


201 :デフォルトの名無しさん:02/05/19 03:44
こういう組み合わせの場合、ペアプログラミングは破錠します、という見本。

202 :デフォルトの名無しさん:02/05/19 03:46
あ、でもいまきがついたんだけど前スレの940はスペースがないね。
940 != 29なのかなぁ。それとも29はスペースつけたりつけなかったり
するのかなぁ。

203 :デフォルトの名無しさん:02/05/19 03:47
>>201
え?それ何?ネタにしても面白そう。もっと説明きぼん。

204 :デフォルトの名無しさん:02/05/19 03:50
>実は,俺の上司がそうなんだ。とっても賢い人なんだけどそうは
>見せないないんだよね。ゆとりがあるというか。

ほんとに偉い人=ゆとりがあるから偉そうに見せない。
濱井=ゆとりがないから偉そうに見えない。

205 :204:02/05/19 03:52
いったいぜんたい、重箱の隅をつついたり、言葉遊びのような議論をする
濱井のどこに余裕があるんだか(爆笑)

206 :201じゃないが:02/05/19 03:57
>>203
一人があばたもえくぼなほどもう一人にほれ込んでりゃ、ペアプロが機能しないって
ことでは。

207 :衝撃の事実:02/05/19 03:58
もしや…濱井タンが50歳過ぎで29の上司では…

208 :デフォルトの名無しさん:02/05/19 04:05
29の上司です。あげ

209 :デフォルトの名無しさん:02/05/19 05:00
漏れも29は長谷川さんだと思うけど。

210 :デフォルトの名無しさん:02/05/19 11:07
>>209
文体が明らかに違うし,彼はもう少し抽象的な話をするとおもうけど.
想像で実名を出すのはどうかな.


211 :デフォルトの名無しさん:02/05/19 11:10
俺は最近XPMLに入った人で自己紹介している人が先頭にスペースがあって
疑わしいと思うけど


212 :デフォルトの名無しさん:02/05/19 14:27
>>210
同意。意味ないよ。俺はもう少し29と話がしたかったが、これじゃあもう出てこないね…

213 :デフォルトの名無しさん:02/05/19 14:57
XPのスレではなくXPMLのスレでござったか。所詮XPなんてこの程度?

214 :デフォルトの名無しさん:02/05/19 16:21
>>213
違う、違う。
XP自体じゃなくってXPに興味有る人間だって。<この程度

215 :デフォルトの名無しさん:02/05/19 16:30
ふむ。29よりはまだ前スレの940の方が彼らしい。(w

216 :デフォルトの名無しさん:02/05/19 19:56
210はピリオド+カンマの使い方に特徴があるね。

217 :デフォルトの名無しさん:02/05/19 21:18
>>216
論文を書いてる人は”,.”を使う人多いね
わざとそれを使って自慢しているふしもある

218 :デフォルトの名無しさん:02/05/19 21:42
自慢してるわけではないんでは^^;

219 :デフォルトの名無しさん:02/05/19 22:50
>>217
旧スレの938も同じスタイルだね。確かに自慢してるかも。
誰かなのかは各自の想像で。

>>938
> >>932 のような人はコンプレックスの塊と相場は決まっています.
>
> 批判は誰にできもできるんであって,濱井氏よりももっとつまら
> ない発言をしていることに気が付かない所でおつむの程度がわか
> ります.
>
> 仮に言いたいことがはっきりしているならMLで意見すればよい
> のです.
> それができない所にこの人の人間としてのつまらなさが潜んでい
> ますね.
> きっと,こういう人は何をやっても駄目な人です.



220 :デフォルトの名無しさん:02/05/19 23:43
>>217
こういう批判以前から聞くけど、技術系の文章にはそういうルール
があるみたいだよ。ソースは示せないんだけど。

221 :デフォルトの名無しさん:02/05/20 00:10
最近の投稿で>>217の組み合わせって平鍋さんしか思い当たらないんだけど。

222 :デフォルトの名無しさん:02/05/20 00:15
( ´_ゝ`)フーン

223 :デフォルトの名無しさん:02/05/20 01:48
落ち込んだ

224 :デフォルトの名無しさん:02/05/20 02:09
おつむage

225 :結論:02/05/20 03:13
おつむの程度の高い平鍋さんでも>>219がいっちゃんつまらない発言なのはわからないってこった。


226 :デフォルトの名無しさん:02/05/20 04:01
もうXPMLはほっとこうよ。考えるだけ悲しくなるから。
ここでマターリXPを語ろうよ。

227 :デフォルトの名無しさん:02/05/20 11:59
XPMLの人たちとXPやれといわれたらやだな。
まだウォーターフォールの方がマシ。

228 :デフォルトの名無しさん:02/05/20 12:01
>221
MLに投稿している人がこのスレで発言しているとは限らない
と思うのですが??
XPMLで発言している人でまともな人がこのスレで意見を
書くなんて無駄なことをしないと思うけどね。
馬鹿相手にするほど暇じゃないでしょう。



229 :デフォルトの名無しさん:02/05/20 13:18
>>228
いや、彼だよ。(w

230 :デフォルトの名無しさん:02/05/20 13:21
無駄で自分の恥をうっかり晒したってことは確かだけどね。

231 :デフォルトの名無しさん:02/05/20 13:29
相手のおつむの程度を見透かすような人にXPは無理です。

232 :デフォルトの名無しさん:02/05/20 13:32
>>231
だからあ「おつむ」発言も平鍋なの。
平鍋に実践は無理。頭でXPをあれこれ語ってるだけ。

233 :デフォルトの名無しさん:02/05/20 13:36
>>232
氏ね

234 :デフォルトの名無しさん:02/05/20 13:39
思うんだけど理屈っぽい人同士でペアプロって無理なんじゃない?
と振ってみるテスト

235 :デフォルトの名無しさん:02/05/20 14:00
その見本がXPML。

236 :デフォルトの名無しさん:02/05/20 14:17
濱井がうざいというより
いちいち濱井を敵視して馬鹿なコメントをつけるNECの諸氏がうざい
社内で嫌われているのかどうかしらないけど大概にしてほしい

237 :デフォルトの名無しさん:02/05/20 14:23
どこのmlだって浜井ぐらいのの厨房はいるから問題無し。(うざいのは確かだが)

238 :デフォルトの名無しさん:02/05/20 14:25
けど、厨房の相手する人間がこのmlは多い気がする。

239 :デフォルトの名無しさん:02/05/20 14:30
それはXPMLが厨房の集まりだからYO。

240 :デフォルトの名無しさん:02/05/20 14:52
>>239 ← 馬鹿決定

241 :デフォルトの名無しさん:02/05/20 15:19
あながち間違いとも言い切れない…

242 :240:02/05/20 15:21
厨房の集まり<あながち間違いとも


243 :デフォルトの名無しさん:02/05/20 17:17
なんかまだ濱井タンSPAMを送ってきてるね…
もういいから退場してくれ。

244 :デフォルトの名無しさん:02/05/20 18:24
ネタがなくなって、濱井タンを晒し上げるだけのスレはここですか?

245 :デフォルトの名無しさん:02/05/20 18:42
だれか濱井タンとペアプロしてくだちい。

246 :デフォルトの名無しさん:02/05/20 19:10
あんな脊髄反射レスを繰り返すのはデンパとして晒されてもしかたないよ。日下部タンの方がまだ中身があるんじゃないかい。




247 :デフォルトの名無しさん:02/05/20 21:15
濱井は、たかがXPMLみたいに狭い世界でウォーターフォールを感情的に叩いたって意味
ないだろうに。

本気でウォーターフォールを叩きたいなら、XPMLで逆にウォーターフォールの利点(とされて
いること)を積極的に吸い上げて、自分の知識を増やすんだよ。そしてここぞって場面に
控えめに、けれどずばりと出すの。

濱井のは、ありゃ両手をめちゃくちゃぶん回して殴りかかるガキの喧嘩だ。
伝えたいと思う人たちから敬遠しかされていない現状をどう考えているのか。

上の方であたたかい目で見守ってあげようみたいな発言している人がいるが、
それが本人のためになるんだか。この先濱井に転機が訪れるとしたら、それは
太陽のような暖かさによってではなく、北風のような厳しさによってだと思う。
今の濱井には挫折こそが必要で、暖かい心はその後の立ち直りの時に注い
でやるべきだ。これが逆の似非博愛主義者にはへどが出る。

248 :デフォルトの名無しさん:02/05/20 21:25
XPMLってもともとXPに興味がある人が集まってるんだから
ウォーターフォールに対する対比なんてみんな最初にやったことじゃないのか。

249 :デフォルトの名無しさん:02/05/20 21:33
つーかウォーターフォールの欠点なんて、いまさら教わるまでもないんですけど(w

250 :デフォルトの名無しさん:02/05/20 21:36
だね。XPの利点をわかってて、ウォータフォールの欠点もわかってて、その上で
ウォータフォールにもこういう利点があるんじゃないかって、みんないってるのに
濱井の方は、みんなはなんでウォータフォールにはこんなに欠点があるのが
理解できないんだ、ってな調子なのがしらける原因だ。

251 :デフォルトの名無しさん:02/05/20 21:37
>>248
濱井はその最初のまま固まってるのでうざい

252 :デフォルトの名無しさん:02/05/20 21:42
>>もちろん、繰り返し型開発でもXPに代表されるように、イテレーション注でも
>>必要があれば"勇気"をもって対応する(変更する)ものもたくさんあります。

>XPでは、イテレーション中の変更については、変更するとも変更しないとも
>特に言及されていなかったような……。

これ意味がわかんないんだけど、どういう意味なのかな。何も変更しない
イテレーションってのがありえるんだろうか?!

もうとてもじゃないがMLでレスする気にはなれないから、ここに書くけど。

253 :250:02/05/20 21:45
つづきだけど

ウォーターフォールの利点(とされてること)を、XPではどう補っていけばいいのか、
とかが話題に出来ればうれしいんだけど、夢のまた夢だね(泣)

254 :デフォルトの名無しさん:02/05/20 21:46
>>252
よく濱井の文章読む気になるね(w
俺は上から下に目を走らせて終わりだよ。頭には入れない。むかつくから。

255 :デフォルトの名無しさん:02/05/20 21:47
>>252
馬鹿なちみは、MLで聞かないほうがいいよ。
「イテレーション中」とあるだろう。

256 :デフォルトの名無しさん:02/05/20 21:48
>>251
だからXPマンセーのおめでたい単純バカには受けがいいのかもね。平鍋さんもその口かな?

257 :デフォルトの名無しさん:02/05/20 21:48
>>255
252 は 254の間違え

258 :デフォルトの名無しさん:02/05/20 22:01
>>255
イテレーション毎の変更じゃなくて”中”の変更か。なるほどね。バカは余計だが。

しかしそんなのは派手にやったらわざわざイテレーションの単位を
小さくした意味がないし、地味な変更ならどんな開発だってそうだ。
例外的に派手な変更をすることもあるだろうし。

開発なんてものはイレギュラーの扱いこそ腕の見せ所だし。
イレギュラーを少なくすることと、それでも必要なイレギュラーは迷わず
大胆かつ慎重に処理する、が基本だ。


259 :デフォルトの名無しさん:02/05/20 23:02
濱井タンって何やってる人なんだろうね。ちょくちょくグラフィックカードの
ドライバの開発やコンシューマ製品の話を出してくるから、グラフィック
ドライバを一人でしこしこ書いてるのかな。

確かにグラフィックドライバなら一人でじっくり深く深く探求した方が効率も
生産性も最大になるかもしれないね。濱井タンがそういった仕事をしてる
なら適材適所を絵に描いたようなものだから、自分の幸運に感謝すべき
だろうな。

でもその経験と本から得た知識だけで、CMMやウォータフォールを批判する
のは、止めはしないけど無理があるんじゃないかなぁ。プロジェクト運営の
経験も話からはあるように見えないし。

それとも幸せな世界にひたひたと近づいてくるCMMやISOに恐怖を感じて
るのかなぁ。同情するけどXPMLでヒステリックに騒いで何かいいことあるのかなぁ。

260 :デフォルトの名無しさん:02/05/20 23:55
>>258

何が言いたいの?

261 :デフォルトの名無しさん:02/05/21 00:13
>>259 妄想癖でもあるんじゃないの? 馬鹿ばっか

262 :デフォルトの名無しさん:02/05/21 00:23
本人登場か!?

263 :デフォルトの名無しさん:02/05/21 00:26
あんなの開発者じゃねーだろ。
何もわかんねー文系が本だけ読んであれこれ理屈こねてるだけ。

264 :デフォルトの名無しさん:02/05/21 00:28
アスパラ君そろそろやめなさい

265 :デフォルトの名無しさん:02/05/21 00:28
濱井は

開発者
開発者じゃない

どっち?

266 :デフォルトの名無しさん:02/05/21 00:49
>>264
その高圧的な物言い平鍋さんかな?

267 :デフォルトの名無しさん:02/05/21 00:54
なんか両陣営とも疑心暗鬼で危険ですね。しばらくXPMLには近づかないどこ。

268 :デフォルトの名無しさん:02/05/21 02:55
>>266
かもね(笑)

269 :デフォルトの名無しさん:02/05/21 03:30
2chに対して高圧的な姿勢は煽りを助長するだけと思われ。

270 :デフォルトの名無しさん:02/05/21 04:43
高圧的な態度が反発を招くのは2chに限らない罠
XPMLの連中にXPは無理。

271 :デフォルトの名無しさん:02/05/21 23:01
階層型の組織だと機動性や情報の伝達性が悪いけど、
その分悪い情報の緩衝帯にもなってるんじゃないかな…

XPでいままで上司の悪口をいって憂さを晴らしてたのが仲間の
悪口に変わらなきゃいいけど。

272 :デフォルトの名無しさん:02/05/21 23:03
>>271
「悪い情報」と「良い情報」と分けるところががきだな

273 :デフォルトの名無しさん:02/05/21 23:07
>>272 まったく
下に流す情報を選んでよいことなどないですよ。
悪い情報が怖い人は、2chで鍛えなさい。

274 :デフォルトの名無しさん:02/05/21 23:08
分けてはいないよ。分けられるならよい情報だけ風通しよくできる
はずだろ?それは出来ないってことだよ。よい情報の風通しを
よくすれば、悪い情報の風通しもよくなるって事だよ。
読解力がないね。理解力がないのかな?

275 :デフォルトの名無しさん:02/05/21 23:09
>>273
そうなってるのが2chとXPMLだ。キミには理想の姿だろ?

276 :デフォルトの名無しさん:02/05/21 23:10
>274 馬鹿じゃないの
自分で「悪い情報の緩衝帯」と書いて
「悪い情報」という捉え方をしてるじゃない
それを分けているっていうんだよ

277 :デフォルトの名無しさん:02/05/21 23:11
>下に流す情報を選んでよいことなどないですよ。

だいたいそんなことが可能か?よい情報って何だよ?


278 :デフォルトの名無しさん:02/05/21 23:12
>>276
よい情報を妨げると同時に悪い情報も妨げてると書いてるんだが、
どこに文句があるんだ?

279 :デフォルトの名無しさん:02/05/21 23:15
>278 本当に馬鹿だな
そもそも 良い悪いと 分ける意味がないといってんだよ
お前の分は 良い悪い と分けて考えた文章になってんのがわからないの?

280 :デフォルトの名無しさん:02/05/21 23:16
>>279
馬鹿を相手にするのはやめましょう

281 :デフォルトの名無しさん:02/05/21 23:20
図らずも272、273のおかげで

「下に流す情報を選」ぶ

ってことにヒステリックに反応する人間が多いことに気づかされたよ。
やっぱりこういうことって多いのかね。

>お前の分は 良い悪い と分けて考えた文章になってんのがわからないの?

だからよい情報って何よ?悪い情報とは?2つのものは分けられないと
書いてるのだが、日本語がわからないのか?キミだって

>「良い」「悪い」と 分ける意味がないといってんだよ

とわけてるじゃないか。分けられないことを説明するには2つをあげなきゃ
説明できないだろ。わからんやつだ。


282 :デフォルトの名無しさん:02/05/21 23:23
ひょうたんからこまだ。
XPと2chを対比させるのは面白い考えかもしれないな。


283 :デフォルトの名無しさん:02/05/21 23:25
>>281
アホだなーーーー

284 :デフォルトの名無しさん:02/05/21 23:31
>>282
何をもって対比させるか書かんとわからんだろう。
馬鹿ばっか。

285 :デフォルトの名無しさん:02/05/21 23:36
仕事をしていれば当然多かれ少なかれ満足のいかないことがでてくる。
その対象が「上司」や「組織」ではなく、「仲間」になるわけだ。

いままで上司の命令だからと、しぶしぶやってたのが何しろ自分が
参加したミーティングで仲間たちの意見により決まったことなんだから、
心底納得した結果なら何よりだけど、そうでない場合感情が処理できるのかな。

それも一回や二回じゃなくずっとだ。常にあいつの意見はとおり自分の意見が
通らない…

この辺やXPMLにたむろしている連中に、自分の感情がうまくコントロールできる
のかね。



286 :デフォルトの名無しさん:02/05/21 23:37
>>284
うんそうだね。まだそこまで考えが進んでないんだよ。


287 :デフォルトの名無しさん:02/05/21 23:40
ちょっと進んだから書くね。

2chの煽りにたいして、煽り返したり呆れて放り出すようでは、
XPをやる資格はない、とかいう観点はどう?

288 :デフォルトの名無しさん:02/05/21 23:41
>>285
気が振れてるんじゃないの?

289 :デフォルトの名無しさん:02/05/21 23:43
>>287
「観点」の意味知ってる?
いい子は早く寝なさい

290 :デフォルトの名無しさん:02/05/21 23:45
>>288
反論できないだろ?
こーゆう厳しい面を見ないでXPに浮かれられてもね。

そのうちXPでミーティングしてるよりコーディングしてる方が
ずっと効率がいいとかいいだすんじゃないか?

291 :デフォルトの名無しさん:02/05/21 23:50
>>290
論じてない文に、反論はできません。
自分の意見が通らないとだだをこねる、おこちゃまは早く寝ましょう。

292 :デフォルトの名無しさん:02/05/21 23:53
<XP推進プロジェクト : 今月の課題>

1.ミーティングに出てこない引きこもりメンバをどうやって登校もといミーティングに出すか。
2.声の大きい特定のメンバーの意見にだけ耳を傾けないで、みんな平等に発言しましょう。

学級会だな。


293 :デフォルトの名無しさん:02/05/21 23:58
3.自分の意見が通らなくてもみんなで決めたことは、一生懸命がんばりましょう。

294 :デフォルトの名無しさん:02/05/22 00:02
「A君はぁ、先週のミーティングで、〜の部分を仕上げるといいました。」
「でもぉ、それは出来ませんでした。A君はちゃんといったことを実行しないといけないとおもいます。」
「B君はいつもサボってばかりいます。だからその分他の人たちがたいへんになります。B君はずるいとおもいます。」


295 :デフォルトの名無しさん:02/05/22 00:05
ところで291とかは何マメに煽ってんの?まじめな煽りだな…

296 :デフォルトの名無しさん:02/05/22 00:08
>>290

確かに幼稚な人には厳しいとおもうぞ.

297 :デフォルトの名無しさん:02/05/22 00:10
そうだね。XPMLは幼稚は人たちがはしゃぎまわってるけど、キミらには無理だって
いってあげなよ。>xxさん

298 :デフォルトの名無しさん:02/05/22 00:11
アスパラ君そろそろ寝なさい

299 :デフォルトの名無しさん:02/05/22 00:26
アスパラ(?) VS 平鍋(?)/濱井(?)の戦いは今日も続く…XPに明日はあるか?

300 :デフォルトの名無しさん:02/05/22 00:28
アスパラ君のサイトにいけばわかると思いますが,
"…"を使っているものはすべてアスパラ君ですね.
"…"なんてめったに使う人いませんからね.

301 :デフォルトの名無しさん:02/05/22 00:44
>>300
2chじゃピリオドとカンマよりは…の方が使われてると思うよ。

302 :三点リーダー使ってみました:02/05/22 00:55
むなしい戦いだ…

303 :デフォルトの名無しさん:02/05/22 00:58
どっちかつーと300の方が間抜けに見える。

304 :デフォルトの名無しさん:02/05/22 01:22
とうとう平鍋タンは2chで他人のHP批判をはじめました。
もうりっぱな2chねらーだと思いました。
こういうのをミイラ取りがミイラになるというんだよって先生が教えてくれました。

305 :デフォルトの名無しさん:02/05/22 01:28
泥沼age

306 :デフォルトの名無しさん:02/05/22 12:02
XPMLってのはいわば極左だね。

307 :デフォルトの名無しさん:02/05/22 16:13
>300
2chで"," "."使ってる人も少ないよね。

308 :全員,.…を使うスレになりました:02/05/22 16:18
>>306
自分らは革新派と思っちゃいるが,誰からも相手にされない共○党か….

309 :デフォルトの名無しさん:02/05/22 16:35
>>306

じゃあ、2chは?

310 :デフォルトの名無しさん:02/05/22 16:39
XPのメンバーはチームであり、2chのメンバーは烏合の衆

チームでないメンバ同士でペアプロをしても無駄だが、
XPはチームの作り方までは書かれていない。



311 :デフォルトの名無しさん:02/05/22 17:29
>>310
チームの定義は?トートロジーを回避してちゃんと定義できるの?

312 :デフォルトの名無しさん:02/05/22 17:34
>>309
2chは右翼も左翼も中道もいるね。ナチュラルでいいね(w

313 :デフォルトの名無しさん:02/05/22 17:37
>>311
トートロジーの定義は?言葉遊びをやってて楽しい?


314 :デフォルトの名無しさん:02/05/22 17:58
>>313
XPML向きだろ?
トートロジーはわかるだろ?あんたの>>310でいえば、

チームのメンバ同士でなければXPでペアプロ不可能。
チームのメンバとはXPでペアプロ可能な者同士。

つまりあんたの発言自体が言葉遊びにしかなってないわけだよ。

315 :デフォルトの名無しさん:02/05/22 18:05
トートロジーというよりも循環論法といったほうがいいと思われ。
所詮XPは「XPでうまくいくメンバなら他の方法でもうまくいくだろう」の呪縛から
逃れられない。

316 :デフォルトの名無しさん:02/05/22 18:07
そして自分から急所に話を持っていった310の負け。つーか自爆。

317 :デフォルトの名無しさん:02/05/22 18:16
>>314
> XPML向きだろ?
いいや、http://natto.2ch.net/test/read.cgi/denpa/向けだな。

勝手にこんな電波を受信しないで欲しいな。
> チームのメンバ同士でなければXPでペアプロ不可能。
> チームのメンバとはXPでペアプロ可能な者同士。


318 :デフォルトの名無しさん:02/05/22 18:23
>>315
> 所詮XPは「XPでうまくいくメンバなら他の方法でもうまくいくだろう」
でも、メンバが優秀ならば今までの方法よりはXPの方がうまくいく確率は高い。

そして、XPは優秀でないメンバの場合、今までの方法よりうまくいくとは言っていないし、
優秀でないメンバを優秀にする方法も書いていない。


319 :デフォルトの名無しさん:02/05/22 18:37
>でも、メンバが優秀ならば今までの方法よりはXPの方がうまくいく確率は高い。

>そして、XPは優秀でないメンバの場合、今までの方法よりうまくいくとは言っていないし、

つーより、メンバが優秀でないならば今までの方法よりもXPの方がうまくいかない確率が高い。

仕様変更の繰り返しをイテレーションと名前を変えただけになる。顧客が右へいけといえば
右に進んで、いや違った左だったといえば左に進む。右往左往して時間ばかりかかった挙句、
中途半端で実用に耐えない作りかけのソフトが残るだけ。

優秀なメンバはXPで開発させ、優秀でないメンバはウォーターフォールで開発させる?(w
現在でもおおざっぱにはそうなってると思うけどね。それをXPと呼んでいないだけで。


320 :デフォルトの名無しさん:02/05/22 19:27
>>319
> 優秀なメンバはXPで開発させ、優秀でないメンバはウォーターフォールで開発させる?(w
戦争で例えるとXPは「機動力重視」でウォーターフォール「防衛力重視」だろうな。

「機動力重視」の場合、機動力は人数に反比例するために少数精鋭であることが重視され、
「防衛力重視」の場合、防衛力は人数に比例する為に人海戦術が採られることが多い。


321 :デフォルトの名無しさん:02/05/22 19:45
開発メンバが仮に優秀だとして、わけわからん顧客相手にXPは通用するのかね。
顧客も優秀でないといけないんじゃないの?贅沢な方法だ。

322 :デフォルトの名無しさん:02/05/22 20:12
>>321
> 顧客も優秀でないといけないんじゃないの?
少なくとも多くのSEには無いと思われる「ストーリ」を書ける能力と
「受け入れテスト」を行える能力は必要でしょう。
こちらが途中で見積もりの甘さで計画が変更になってもごねたりせず、
仕様変更を行うとリリース期間を変更する必要があること理解できる
物わかりのよい顧客である必要もあるでしょう。

プロジェクト管理以外のSEの仕事を顧客に押しつけ、
プロジェクト管理をPGに押しつける方法を「XP」と呼びます。

> 贅沢な方法だ。
絵に描いた餅って贅沢なんですか?


323 :デフォルトの名無しさん:02/05/22 20:28
>プロジェクト管理以外のSEの仕事を顧客に押しつけ、
>プロジェクト管理をPGに押しつける方法を「XP」と呼びます。

なかなか簡潔でいいね。

>> 贅沢な方法だ。
>絵に描いた餅って贅沢なんですか?

発言の意図がわからないが。
絵に描いた理想のもちを現実に要求するのは贅沢な要求といえるけど?


324 :デフォルトの名無しさん:02/05/22 22:04
SEのみなさん、今度からPGに頼むときは「仕様変更」じゃなくて「イテレーション」といいましょう。

例)
ごめん、ちょっとイテレーションしてくれない?たいしたはなしぢゃないんだけどさぁ」


325 :デフォルトの名無しさん:02/05/22 22:08
応答例)
「えー、先週どうしもってうかこの部分イテレーションしましたよね。
もとに戻すんですかぁ?ほんとにこれが最後のイテレーションなんでしょうねぇ」

326 :誤字修正:02/05/22 22:09
応答例)
「えー、先週どうしもっていうからこの部分イテレーションしましたよねぇ。
元に戻すんですかぁ?ほんとにこれが最後のイテレーションなんでしょうねぇ」

327 :打つ出し脳:02/05/22 22:17
どうしもっていうから → どうしてもっていうから

328 :デフォルトの名無しさん:02/05/22 22:47
>>325-327

とりあえずおちけつ。

329 :デフォルトの名無しさん:02/05/23 05:27
女SE「今日、ワタシにイレテーション?」
男PG「またですか?明日起きれなくなるんで困りますよ。」
(゚∀゚)イイ?

そんなうちの会社はXPを通り越してNPです。

330 :デフォルトの名無しさん:02/05/23 11:42
>>320
防御だと攻撃側の1/3の兵力で何とかなるんだが...

331 :HAMAIタンうぉっち:02/05/23 13:27
脊髄反射レスは続く。アホくさー。
NECはみんなこうなのか?幼稚園児を採用してんのかい?
------------------
「変更する勇気」も必要ですが、「変更しない勇気」も必要です。
顧客の要求する変更が必ずしも顧客にとって益をもたらすとは限りません。
変更が逆効果であった場合のことを考えると、イテレーション毎の開発が完結
しないリスクが大きくなるイテレーション中の変更は避けた方が良いように
思います。

332 :デフォルトの名無しさん:02/05/23 13:32
>>331
うむ、最終的に顧客利益になるようにするのがXPの本質だと思うナリ。

333 :デフォルトの名無しさん:02/05/23 14:33
>>332
自分の会社の利益と衝突したときはどう解決したらよいのでしょうか。教えてください、おながいします。

他の方法は顧客の利益を考えないのでしょうか。これもおながいします。

最後の質問にになりますがあなたは馬鹿ですか。いろいろ失礼な質問かもしれませんが、ご容赦ねがいます。

334 :デフォルトの名無しさん:02/05/23 14:43
XPって全人類の平和を願う宗教みたいなもんだな。
一人一人が相手を思いやる心を持てば平和が実現する、ってか。
平和を構築するノウハウにはいっさいふれず、平和を願う心が大事。
心がけるよりは心がけた方がいいが、それだけの話。XPとCMMを比較するのは経済学と宗教を比べるようなもので、ナンセンス。
さあみんなでマントラを唱えて修行しましょう。

335 :プラクティス1:1日3かいとなえてください:02/05/23 14:54
イテエレーションするぞ。イテレーションするぞ。今週も顧客のためにがんばってイテレーションするぞ。

#オウムの麻原が無罪を主張なんてニュースをみたから。

336 :デフォルトの名無しさん:02/05/23 15:02
>.330
火力重視の攻撃型プロジェクトを作ったつもりが、防衛力重視になってしまう罠。

337 :デフォルトの名無しさん:02/05/23 16:21
>>333>>334には顧客が敵にしか見えないようだ
いつも中国や北朝鮮のようなユーザを相手に仕事しているのだろうか?

338 :デフォルトの名無しさん:02/05/23 16:28
>>334
> XPとCMMを比較するのは経済学と宗教を比べるようなもので、ナンセンス。
え?XPとCMMは両方とも宗教だよ。

CMMも平和を構築するプロセスは規定しているが、
平和を構築するノウハウは規定していない。

# だからXPMLでやっているのは所詮「宗教論争」であり、
# 結論など出るわけない。


339 :デフォルトの名無しさん:02/05/23 16:41
>>337
「敵」ねぇ、キミこそ正義対悪がわかりやすい漫画の見すぎじゃねーの。
「中国」や「北朝鮮」が「敵」にしかみえねーんだろ?
政治が何かわかってないな。

もしかしてキミはXPに政治が不要だと思ってるわけ?
おこちゃまが相手をおこちゃまと呼び合うのがXPMLとこのスレだな。

340 :デフォルトの名無しさん:02/05/23 16:56
> 「敵」ねぇ、キミこそ正義対悪がわかりやすい漫画の見すぎじゃねーの。
「水戸黄門」の見過ぎという説もある。


341 :デフォルトの名無しさん:02/05/23 17:05
>>339は「中国」や「北朝鮮」のような難しいユーザに
ポリティカルスキルを存分に発揮している凄いSEらしい。

> いつも中国や北朝鮮のようなユーザを相手に仕事しているのだろうか?
とりあえず、ここだけは337が当たっていたようだ。

342 :デフォルトの名無しさん:02/05/23 17:42
>>341
相手が理想を掲げたから、理想で対抗しただけだよ。
実際、政治は必要だし。それともXPでやると急に顧客が物分りがよくなるのか?

物分りのよい顧客もいるが、それは顧客側の担当者が自社内に対して
やってくれてるかあであって、誰かがやらなきゃならんことに変わりはないし。

XPとはSEのアウトソーシングってか?効率はよくなるかもしれんが、PGの
負担は増えるだろうな。救いは負荷が効率に結びつく(かもしれない)ところかな。
増えた上に非効率じゃ救いがないから。


343 :デフォルトの名無しさん:02/05/23 18:14
おい、XP信者ども!
XPがけなされてるぞ!
H井イジメとか内ゲバやってないで、
まともな反論でもやってみろ


344 :341:02/05/23 18:16
>>342
> 実際、政治は必要だし。それともXPでやると急に顧客が物分りがよくなるのか?

XPは「物分りのよい顧客」を前提にしていると思う。少なくとも、「政治」を使
わないと、ユーザの中の一番馬鹿な奴の意見がそのまま通ってしまうような状況
は考慮していない。

他にもXPには暗黙の前提がいくつかあって、あなたが攻撃しているのは、その前
提の方だという気がする。前提(適用範囲)が明文化されてないのは、XP側の問
題だけどね。

> 物分りのよい顧客もいるが、それは顧客側の担当者が自社内に対して
> やってくれてるかあであって、誰かがやらなきゃならんことに変わりはないし。

世の中にはこういうことをしなくてよい組織もあって、XPの連中は、そういう環
境で仕事をして来たと俺は思うが、どうだろうか?

XPを批判する側に言いたいのは、「物分りのよい顧客」という前提条件が非現実
的だと言いたいのか、「物分りのよい顧客」という前提をおいてもXPは非効率的
だと言いたいのか、どっちなのかはっきりするべきだということだ。

345 :XPの批判:02/05/23 18:56
>>344
前提(適用範囲)が明文化されてないのが問題
XPは少なくとも以下の前提がある。
 ・顧客は自分の欲しいシステムをストーリとして文章にすることができる。
 ・顧客はシステムが自分の要求どおりであることをテストできる。
 ・顧客が自分の欲しいサブシステムの優先順位を付けることができる。
 ・顧客はプログラマが約束されたイテレーションを完了できなくとも許すことができる。
 ・プログラマはストーリから規模を見積もることができる。
 ・プログラマは規模から理想日で何日費やせばストーリを実装できるかを約束できる。
 ・プログラマは見積もりを過大に申告しない。
 ・プログラマはそのプログラムが「美しい」か「汚い」かの判断ができ、
  その判断はチームで大きなばらつきはない。

この条件を満たさないとXPは適用しても効果はないのに
この条件を満たすプロジェクトはほとんど無い。(少なくとも私の周りには)
耳に心地よい福音だけ述べてそれに救われる条件の人はほとんど無いのは詐欺に近い。
# まぁ、世知辛い世の中 騙すよりも騙される方が悪いんだけど。


346 :デフォルトの名無しさん:02/05/23 19:00
最初からその全てができなければいけないのだろうか。

それを言ったら、
すべてのプロセスはそのプロセスのやり方に従って
開発を完了させることができるのを前提としている、
とも言わねばなるまい。

347 :デフォルトの名無しさん:02/05/23 19:11
>他にもXPには暗黙の前提がいくつかあって、あなたが攻撃しているのは、その前
>提の方だという気がする。

半分当たり。

>前提(適用範囲)が明文化されてないのは、XP側の問
>題だけどね。

これがもう半分。明文化されているされていないってのは問題じゃないけどね。
いいかげん手放しに喜ぶだけの話題は飽きた。MLの連中はXP vs CMM、XP vs ウォーターフォール
なんて馬鹿の一つ覚えはやめてXP自体を見つめてほしいけどね。よいとこもわるいとこも。

>世の中にはこういうことをしなくてよい組織もあって、XPの連中は、そういう環
>境で仕事をして来たと俺は思うが、どうだろうか?

顧客と一体となって開発するプロジェクトは2種類あると思うよ。

一つはすごく斬新なシステムを作る時。こんなものをウォーターフォールで
開発するやつは、そのシステムを手がける資格がない。(ちょっといいすぎか。)

もう一つは派遣と受託の中間みたいなもの。経験があればウォーターフォールで
開発できない話じゃないが、顧客にも自社にも経験がなけりゃウォーターフォールは
簡単に破綻するから。それにこういったのは小規模なのが多いから、ウォーターフォール
がたとえうまくいってもあんまり効率がよくない。

その変形としてパッケージ開発があるかな。気心のしれたお客と改良を
重ねて、外販もしてく。

>XPを批判する側に言いたいのは、「物分りのよい顧客」という前提条件が非現実
>的だと言いたいのか、

なるほど。俺の発言も馬鹿の一つ覚えではあるな(w
「物分りのよい顧客」は非常に厳しい前提条件だと思うよ。

けど俺が言ってるのはあんたの表現を借りれば、前提条件抜きの議論が
むなしいって部分かな。

>「物分りのよい顧客」という前提をおいてもXPは非効率的
>だと言いたいのか、どっちなのかはっきりするべきだということだ。

むむむ、ちょっと考え中だ。


348 :347:02/05/23 19:19
>>345
>前提(適用範囲)が明文化されてないのが問題

そうかもしれない。われながら優柔不断だ。ただ生まれ間もない
赤ん坊(XP)に要求するのは酷かもしれない。

>>346
>最初からその全てができなければいけないのだろうか。

自分たちは精進を繰り返すとして、顧客はどうするのかね。
顧客側にも精進してもらわないとならない。つーとXPは一見さんはお断りってのも
ありかもしれない。

349 :デフォルトの名無しさん:02/05/23 19:22
つづき

>すべてのプロセスはそのプロセスのやり方に従って
>開発を完了させることができるのを前提としている、

顧客側にも努力を要求するプロセスは珍しいからね。
XPはそれを利用&前提としている以上、その税金は払わないと。

350 :デフォルトの名無しさん:02/05/23 19:34
OK、この前提には賛成しよう
・顧客が協力的でないと XP できない

351 :Delフサギコ ◆zE1iiRdQ :02/05/23 20:37
   ______    __________
 /:\.____\ /
 |: ̄\.ミ∩゚Д゚ミ\< 長文読むのダルイ
 |:   |: ̄ ̄ U ̄:| \__________
          XPMLの車輪の再発明すんなよ…

352 :デフォルトの名無しさん:02/05/23 22:04
XPのプラクティスを全部忠実にこなせば幸せになれると思ってる人なんているの?

353 :デフォルトの名無しさん:02/05/23 22:29
いまより幸せになれるって思ってるひとはいるんじゃない?
余計始末が悪いけどさ。さぎでもちょっとだけリアリティがある方が引っかかりやすいし。

354 :デフォルトの名無しさん:02/05/23 22:32
XPMLは幸せを求めてXPの話をするんじゃなくて、現在の不満をXPにあやかってぶつけている
人が多い。というか一人はいる。誰とは言わないが。

355 :デフォルトの名無しさん:02/05/23 22:37
顧客側にもプラクティスが入るんじゃないのかな。どうなんだろ。

356 :デフォルトの名無しさん:02/05/23 22:37
>全てのプラクティスを忠実にこなせば、
ここがポイントだったんだが。
美味しいとこだけつまみ食いすればいいじゃん。
全部忠実にこなすことがXPじゃないはず。
これは勝手な解釈なんだけど、XPというのは方法論ではなく、
単なるきっかけにすぎないと思ってる。

>>354
同意。

357 :デフォルトの名無しさん:02/05/23 22:40
>>354
んだね。だから最近のmlは不快。一生懸命書いてる人には悪いけど。

358 :デフォルトの名無しさん:02/05/23 22:49
>>333

>いろいろ失礼な質問かもしれませんが、ご容赦ねがいます。

失礼な質問だ!!許さないぞ!!

359 :デフォルトの名無しさん:02/05/23 22:50
>>334

何いってんの?
XPは宗教に決まってるジャン?
信者はみんな自覚してるよ。

360 :XP信者:02/05/23 23:00
>>345

>XPは少なくとも以下の前提がある。

これはXPの前提じゃないです。
XP信者は、これがソフトウェア開発を成功させる前提だと考えているのです。

つまり、これらの前提が満たせるように状況をコントロールする必要があり、
そしてどれだけ満たせていないかがはっきりわかるようにプラクティスが構成
されています。

例えば「オンサイト顧客」などは難しいプラクティスに属しますが、このプラクティスが
満たせるか、このプラクティスが満たせたのと同等の効果を顧客から引き出せない
かぎりプロジェクトは失敗する、と考えているのです。

XPが前提としているのは、
・今後のプロジェクトは、より早く、より高い品質と条件が厳しくなってくるであろう
の方であると思います。

361 :偽29:02/05/23 23:01
>>351
読まなきゃいいじゃん.

362 :341:02/05/23 23:53
>  ・顧客は自分の欲しいシステムをストーリとして文章にすることができる。
>  ・顧客はシステムが自分の要求どおりであることをテストできる。
>  ・顧客が自分の欲しいサブシステムの優先順位を付けることができる。
>  ・顧客はプログラマが約束されたイテレーションを完了できなくとも許すことができる。
>  ・プログラマはストーリから規模を見積もることができる。
>  ・プログラマは規模から理想日で何日費やせばストーリを実装できるかを約束できる。
>  ・プログラマは見積もりを過大に申告しない。
>  ・プログラマはそのプログラムが「美しい」か「汚い」かの判断ができ、
>   その判断はチームで大きなばらつきはない。

これはなかなかいいリストだと思う。>>360

> これがソフトウェア開発を成功させる前提だ

ということには大枠で同意するんだよね?(多少の過不足はあろうが)それで、>>345

> この条件を満たすプロジェクトはほとんど無い。(少なくとも私の周りには)

と言っているんだが、そうなると>>345は不可能なことを要求されているように
ならないだろうか?これは煽りやアゲ足取りじゃなくて、実際に日本では多くの
SEが「不可能なことを要求されている」と俺は感じている。

これを「変えるべき悪習」と見る人と「変えられない現実」と見る人の間では、
まともな議論は成り立たないと思うよ。

363 :XP信者:02/05/24 00:15
>>362

>これはなかなかいいリストだと思う。>>360
>> これがソフトウェア開発を成功させる前提だ
>ということには大枠で同意するんだよね?(多少の過不足はあろうが)

同意する。
正確には、前提の「〜できる。」を「〜できなければならない。」と言い換えると、
XPが要求しているものになると思う。
だから逆にいえば、XPはそれらを前提としているのではなくて、それらが現状
出来ていないことを前提としているといえる。
(現状出来ているならば、わざわざXPをする必要はない。)

>> この条件を満たすプロジェクトはほとんど無い。(少なくとも私の周りには)
>と言っているんだが、そうなると>>345は不可能なことを要求されているように
>ならないだろうか?これは煽りやアゲ足取りじゃなくて、実際に日本では多くの
>SEが「不可能なことを要求されている」と俺は感じている。

これは「現在は」という前提がついていると思う。
そこで、XPは宗教だから、勇気をもって変えろ、と伝道しているわけだ。
そのための参考として、成功例の12のプラクティスを指し示した、と解釈している。

>これを「変えるべき悪習」と見る人と「変えられない現実」と見る人の間では、
>まともな議論は成り立たないと思うよ。

それでも勇気をもって論じるのだ。狂信者だから。


364 :デフォルトの名無しさん:02/05/24 00:53
>>363

Agile原理主義者のミサに顔出して解った事が一つある。
俺には狂気が足りない。誰か分けてくれ。

365 :デフォルトの名無しさん:02/05/24 01:11
>>360

(以下はXPの人間重視の側面はあえて除外したとして)

>つまり、これらの前提が満たせるように状況をコントロールする必要があり、
>そしてどれだけ満たせていないかがはっきりわかるようにプラクティスが構成
>されています。

満たすための方法がプラクティスではなくて、プラクティスとは満たされている
かチェックするためにあるってこと?そういわれればそうかもしれないけど。

チェックなら他の方法論でも可能と思うが、XPはそれを「効率よく」できる
ところにXPの利点があるということでよいの?

ちなみに「はっきりわか」ったことを記録し、顧客なり開発者なりの評価(考課
ですな)にもちいるのはXPの考え方に{沿っている、反している、無関係}?

# 考課って言葉にヒステリックに反応するのはやめてね。否定するにしても
# 理性的にね。これは360以外の人にも。

366 :デフォルトの名無しさん:02/05/24 01:39
>SEが「不可能なことを要求されている」と俺は感じている。
>これを「変えるべき悪習」と見る人と「変えられない現実」と見る人の間では、
>まともな議論は成り立たないと思うよ。

変える方向で考えるのはやぶさかではないが、XPはPGに顧客を変えさ
せようとしているように思う(もちろん本当は双方のスキルアップだが)。

あるいは「すでに」十分スキルの高い顧客がいるという前提なのか。
そうすると顧客はそのスキルはどこで磨くのだ?

XPに参加するPGは十分なスキルをもたない顧客にあたっても、
付き合い、相互にスキルを高めあう努力をする、という覚悟が必要という
解釈でよい?

ちなみに旧来の方法では難しくXPなら可能(かもしれない)と考える
理由がわからない。あえて推測すれば

XPは顧客にもPGにも非常に負担を強いるが、その分絶大な効率のよさを誇る。
だから顧客も開発会社も競争原理によりXPを選択することになり、結果的に
顧客も、スキルを高めざるをえないことになる。

これでいい?

367 :デフォルトの名無しさん:02/05/24 02:15
>ちなみに旧来の方法では難しくXPなら可能(かもしれない)と考える
>理由がわからない
ん?そもそも旧来のプロセスでは顧客も開発に参加するという
思想はないんじゃないかな。
何が「可能」って話?

>XPは顧客にもPGにも非常に負担を強いるが、その分絶大な効率のよさを誇る。
>だから顧客も開発会社も競争原理によりXPを選択することになり、結果的に
>顧客も、スキルを高めざるをえないことになる。
順番が逆かと。XP を選択するしないは(名目)自由。
XP のプラクティスを実践すれば、開発チームも顧客もスキルがあがり、
スキルがあがった結果として効率が良くなる、と。
まあ、XP を OOP や CMM に代えても成り立つわけだが。

368 :デフォルトの名無しさん:02/05/24 07:17
>>ちなみに旧来の方法では難しくXPなら可能(かもしれない)と考える
>>理由がわからない
>ん?そもそも旧来のプロセスでは顧客も開発に参加するという
>思想はないんじゃないかな。
>何が「可能」って話?

「顧客も開発に参加」させることが「可能」か否かという話。
顧客にとってXPを選択する大きなメリットがなければならないと思うけど。
それとも宗教だからそれを選択する合理的な理由など存在しない?

>順番が逆かと。XP を選択するしないは(名目)自由。

そりゃそうだが、顧客がXPを選択する理由があるとすれば効率の
高さぐらいしか俺には考えつかないから、それを中心に書くとこうなった。
(実際に効率がよいかどうかはまた別の話)

369 :デフォルトの名無しさん:02/05/24 12:07
>>368
漏れ的には XP 全てにこだわるよりも、取りあえず現状導入できるプラクティスを使えれば可。
XP 全体の議論になると、あまりに話が哲学的になりすぎはせんかい?

370 :356:02/05/24 12:16
>>369
同意。

「オンサイト顧客」に関しても理想的な状況を作るのは難しいから
とりあえず擬似顧客を立てて、本来のメリットの一部を享受するとか。

371 :369:02/05/24 12:30
>>370
元々は、リファクタリングやテスティングについて語るスレだったはずだべよ。
それがどうして宗教紛争に陥ってるんだろうか???

#ありゃりゃ、ついつい擦れ奉行になってしまうたよん。。。

372 :356:02/05/24 12:37
テスティングはそれなりのスキルと習得コストを要するから
(この板見てるような人なら大丈夫だと思うけど)使えねえ、
とかいう一つ一つのプラクティスに関する議論なら分かるけど。

XP全体の批判とか擁護とかって意味ないと思うのです。


373 :デフォルトの名無しさん:02/05/24 12:40
>>365
> ちなみに「はっきりわか」ったことを記録し、顧客なり開発者なりの評価(考課
> ですな)にもちいるのはXPの考え方に{沿っている、反している、無関係}?
XPでは開発者チームの評価は可能かも知れないが、開発者単位の評価は難しいと思う。

特に品質においては「コードの共同所有」「ペアプログラミング」で示すとおり
品質責任は個人ではなくチームが負うことになっている。


374 :Delフサギコ ◆zE1iiRdQ :02/05/24 12:52
個々のプラクティスごとの話は
ためになりそう。
           _____________
   ∧,,∧∩  /
  ミ,,゚Д゚彡 < つことで、しつもそん
   U  ミ   \____________
 〜ミ  ミ
   ∪''∪

最近、プラクティスが13とか14とかに拡張された
とか、聞いたけど、
なんでしたっけ?
ひとつは、机の場所とか家具の配置のことだったと
記憶してるんだけど。


375 :345:02/05/24 13:12
>>363
> >これを「変えるべき悪習」と見る人と「変えられない現実」と見る人の間では、
> >まともな議論は成り立たないと思うよ。
> それでも勇気をもって論じるのだ。狂信者だから。
スマン。さわやかに「狂信者」と自分を断言できるほど俺は純粋ではなくなっている。
そして実は「変えられない現実」と思っていたことを白状する。

でも、「変えられない現実」と諦めるほどにはスレてはいないと自分を信じたい。
「変えるべき悪習」と見るように努力しよう。

# 若さっていいな...特に純粋な若さって...


376 :デフォルトの名無しさん:02/05/24 14:04
>>374
リファクタリングで質問します。
1.コードの整理が付いて可読性が劇的に向上する。
2.再利用可能な汎用クラスが沢山できる。
3.コードの無理・無駄・ムラが減ってコンパイル速度が向上する(?)
等の利点が考えられますが、まだ他にも利点はあるでしょうか?

377 :デフォルトの名無しさん:02/05/24 14:33
>>374
>最近、プラクティスが13とか14とかに拡張された
>とか、聞いたけど、
>なんでしたっけ?
>ひとつは、机の場所とか家具の配置のことだったと
>記憶してるんだけど。

へー。むかし(Smalltalkの)青木さんが似たようなことを書いてたのを
思い出したよ。


378 :デフォルトの名無しさん:02/05/24 14:55
>>369
>漏れ的には XP 全てにこだわるよりも、取りあえず現状導入できるプラクティスを使えれば可。

>>370
>「オンサイト顧客」に関しても理想的な状況を作るのは難しいから
>とりあえず擬似顧客を立てて、本来のメリットの一部を享受するとか。

顧客の協力なしに(=顧客の意識変革なしに)はXPのプラクティスは、
ほとんど機能しないと思うが。

全体がウォーターフォールで最後のデバッグ&テスト工程だけが
XPの真似事ってか?(w
この場合は害がないし益はすくなからずあるから反対しない。

しかし仕様を確定させないなんてことを顧客の理解なしに可能なのか?
よもや顧客とのインターフェイスは従来どおりで、PG仲間だけで
顧客とSE(?)の間でXPごっこなんてものを頭に描いて悦に入ってるんだろうか?


決められた仕様の枠の中で、


379 :スマソ:02/05/24 14:56
顧客とSE(?)の間で決められた仕様の枠の中で、XPごっこなんてものを頭に描いて悦に
入ってるんだろうか?





380 :デフォルトの名無しさん:02/05/24 16:22
>>378
お前、関連書籍読んでないだろ。

381 :デフォルトの名無しさん:02/05/24 16:43
>>380
ほう、大きく出たね。まずキミがどのレベルなのかを示してくれないか?
それがわかればキミに合わせたレベルで話をしよう。


382 :345:02/05/24 17:10
>>376
374ではないので利点ではなく欠点を挙げてみよう。
> まだ他にも利点はあるでしょうか?

・ユニットテストが達成されていないとデグレードやエンバグの温床となる。
・プログラマのスキルに大きな差があるとある人は「改善」しているつもりだが
 他の人から見ると「改悪」しているようにしか見えないということが起こる。
・コードの共同所有が達成されていないと他の人の管理するプログラムに
 手が出せないので効果が低くなる。

よって>>372
> とかいう一つ一つのプラクティスに関する議論なら分かるけど。
XPの多くのプラクティスは他のプラクティスと密接な関係があり
単体で議論しても無駄。

# 単体で議論できるのはユニットテストぐらい


383 :デフォルトの名無しさん:02/05/24 17:27
>>382
反論です。
1.リファクタリングはユニットテストを含んでいるはずですが?

384 :345:02/05/24 17:37
>>383
> 1.リファクタリングはユニットテストを含んでいるはずですが?
では何故XPでは別々のプラクティスなの?
# 含んでいるなら別々ニする必要ないんじゃない?

ちなみに俺の記憶の中ではXP本では
「リファクタリングはユニットテストを含んでいる」とかいう記述はないはず。
もしあったら指摘してくれ。

リファクタリング本の中では
「リファクタリングをするにはユニットテストを行った方がよい」という
記述はあったような記憶があるが。


385 :383:02/05/24 18:06
>>384
> 「リファクタリングをするにはユニットテストを行った方がよい」という
ファウラーは
「堅実なテストはリファクタリングする上での事前条件です・・・リファクタリングにはテストが必須です」
とある。

386 :デフォルトの名無しさん:02/05/24 18:10
>>376
一番の利点はコードの質に対する経験が高まり、次からは一段上の段階から始められること。。。。。。もあるかもしれないなぁと幻想に酔えること(w

387 :デフォルトの名無しさん:02/05/24 18:24
関係者全員が幻想を共有したとき、生産性が向上する。

定説です。

388 :345:02/05/24 18:34
>>385
> ファウラーは
> 「堅実なテストはリファクタリングする上での事前条件です・・・リファクタリングにはテストが必須です」
> とある。
指摘サンクス。俺が思っていたよりかなり強い主張だったみたい。

つまり、XPのプラクティスには前提条件の他に優先順位があるのかな?
ファウラーはそう思っていると読める。


389 :デフォルトの名無しさん:02/05/24 18:47
>>388
> ファウラーはそう思っていると読める。

@ぴぃんぽぉぉ〜ん!!大正解です!!

リファクタリング を効率化させるために、テスティングフレームワーク が誕生し、
リファクタリング テクニック が成熟するにつれ、設計に依存する体質から抜け出せるようになってきた。

これが XPプラクティス の中心部分だと漏れは勝手に推測している。

390 :デフォルトの名無しさん:02/05/24 18:52
>>389
さらに言えば。。。
ファウラーはリファクタリングとコードレビューについて述べているが、
積極的コードレビューの考え方を究極に推し進めたものが XPであると述べている。

391 :383:02/05/24 19:02
プラクティスって一見並列に見えるけど、そこには優先順位が当然あるってこと。
もしプラクティスからリファクタリングを省いたら、XPは音を立てて瓦解します。

392 :345:02/05/24 19:29
ふーむ
>>378
> 顧客の協力なしに(=顧客の意識変革なしに)はXPのプラクティスは、
> ほとんど機能しないと思うが。
とトップダウンからXPを導入した方がよい。と主張している。

一方、>>390
> 積極的コードレビューの考え方を究極に推し進めたものが XPである
とボトムアップからXPを導入した方がよい。と主張している。

# 俺の読み違いだったらスマン。
うーん、どっちがいいのかな?(と煽ってみるテスト)


393 :デフォルトの名無しさん:02/05/24 20:06
>>392
XPの導入過程がスパイラルとかいってみるてすと。

しかしリファクタリングテクニックの成熟で設計依存から抜け出せる、とは思い切った発言。

394 :XP信者:02/05/24 20:55
># 俺の読み違いだったらスマン。
>うーん、どっちがいいのかな?(と煽ってみるテスト)

残念ながら煽りになってません。
XPの教義に従っていれば、どっちから始めても、
そして最終形態がまるで違っていても、XPです。

じゃあ、XPの教義とはなにかというと、XPの4つの価値を認めることです。


395 :XP信者:02/05/24 21:04
>>365

>満たすための方法がプラクティスではなくて、プラクティスとは満たされている
>かチェックするためにあるってこと?そういわれればそうかもしれないけど。

そんな感じ。実際には、チェックするためってよりも、目標を兼ねていると思う。

>チェックなら他の方法論でも可能と思うが、XPはそれを「効率よく」できる
>ところにXPの利点があるということでよいの?

他の方法論では重要視している部分が違うから、自然とXPのチェック内容とは異なります。
XPの利点はXPが重要視している価値に最適化されている、または最適化されうる方向性
をもっている、ってところ。

例えばウォータフォールは、「出来るだけ早く顧客にリリースする」ことをXPほど重要視して
いない。XPのプラクティスは、「出来るだけ早く顧客にリリースする」を満たすために構成
されているし、そのものずばりのプラクティスもある(小規模リリース)。
だから、XPのプラクティスの面から、他の方法論と比較するのは無意味です。

宗教で言えば、キリスト教と仏教を比較するのに、葬式の方法を比べているようなものになる。


396 :デフォルトの名無しさん:02/05/24 21:05
http://pc.2ch.net/test/read.cgi/prog/1000130870/461-463
こんな感じに解り易くメタファで解説きぼんぬ

397 :XP信者:02/05/24 21:12
>>365

>ちなみに「はっきりわか」ったことを記録し、顧客なり開発者なりの評価(考課
>ですな)にもちいるのはXPの考え方に{沿っている、反している、無関係}?

無関係だと思うけど、どうかな?
XPのプラクティスは、プロジェクトのハンドリングに用いるもので、
成績に用いるものじゃないと思うけど。

398 :デフォルトの名無しさん:02/05/24 22:41
>>396
> 行くのじゃ勇者よ!そして変化を抱擁せよ !!!」

ワラタ

XPクエストきぼんぬ。


>しかしムリカイナジョウシとは生理的に合わなかった
>ペアプログラミングの心得は音も無く崩れ去った

ま、ムリカイジョウシがいれば成功しないのは当たり前だが、
いなければ成功するというものでもない。当たり前か>俺。逝くね。

399 :デフォルトの名無しさん:02/05/25 00:13
勇者はプロペラ帽を装備した。

ムリカイジョウシの表情がさらにこわばった。

400 :デフォルトの名無しさん:02/05/25 00:29
どわはは

401 :デフォルトの名無しさん:02/05/25 00:31
はじめまして。XPの初心者です。ひとつ質問をさせてください。
「抱擁」ってなんて読むんですか?

402 :デフォルトの名無しさん:02/05/25 00:38
「ほうよう」です

403 :デフォルトの名無しさん:02/05/25 01:49
モニタ小さいのでよく見えず、擁護だと思ってた

404 :383:02/05/25 09:22
>>393
> しかしリファクタリングテクニックの成熟で設計依存から抜け出せる、とは思い切った発言。

OOP の最大の問題点は 「オブジェクトを発見するのが難しい!」 であるのは通説と思われ。
設計段階での混乱が実装に影響およぼすし、オブジェクトの設計のミスが実装にしわ寄せを及ぼす。
これが リファクタリング によって 「実装しながら設計」 が可能になったのはでかいと思われ。

405 :デフォルトの名無しさん:02/05/25 09:45
>>404

同意。リファクタリングは、シンプルさを保つための必須技術ですな。
リファクタリングとユニットテストの効果を疑問視している人は、自分で
ちいさなツールでも作って試したらいいと思う。


406 :デフォルトの名無しさん:02/05/25 10:11
すっごい大変なプロジェクトで、気付いたらXPみたいになってたことってない?
内部設計なしでコミュニケーションでカバーしてたり・・・。

407 :383:02/05/25 10:22
元々設計段階で完璧にオブジェクトを定義するのは不可能なのよね。
そこに リファクタリング の意義がある。

あと リファクタリング と デザインパターン の関係だが、
「デザインパターンはリファクタリングの提供する」とは GOF 自身も認める所。
ある程度実装が進んだ段階で、始めて効果的なオブジェクトやインターフェイスを
定義できると思われ。
大体 State や Strategy パターンを導入する場合なんかは、
実装段階でないと全然見えてこないだろ。


408 :383:02/05/25 10:23
>「デザインパターンはリファクタリングの提供する」
じゃなくて・・・
>「デザインパターンはリファクタリングの目標を提供する」
だった。スマソ。



409 :デフォルトの名無しさん:02/05/25 12:09
>>408
んんん???どういう意味じゃ???

410 :XP信者:02/05/25 12:50
>>406
>すっごい大変なプロジェクトで、気付いたらXPみたいになってたことってない?

XPのプラクティスは、XPで開発されたわけでなく、それまでで有効と言われた
方法を極端に適用したものだから、当然、XPを意識しなくてもXPみたいになる
ことはある。

「オンサイト顧客」なんて、結局、顧客の張り付きのことだから、納期が守れずに
品質が悪い成果物しか出来ないみこみが高くなり顧客の信用を失いかけたとき
によくやられるんじゃない?

XPでは、それをプロジェクトが暗礁にのりあげてからでなく、
最初からやっておけって考えだと思う。

411 :デフォルトの名無しさん:02/05/25 13:21
>>410
まえからぼんやり思ってたことがひとつ。

実際XPは火を吹いたプロジェクトの末期症状をモデル化したものそのものだ。
XPが要求する前提条件はこういった状況でないと成立しないのではないかと思っている。

言い方を変えると、過去にこうした状況を乗り越えた、顧客-開発者同士ならXPを
やってもいいかと思っているが、見ず知らずの相手い顧客の立場でも開発者の
立場でもXPでやりたいとは思わない。

またXPは本当に効率がよいのだろうか?上のような状況ではメンバが必死だから、
高い効率になるのはいわば当たり前。しかしその状態をXPを用いたからといって
日常的に維持できるとは思えないし、維持すべきだとも思わない。



412 :デフォルトの名無しさん:02/05/25 13:42
火を噴いたプロジェクトの末期症状だと効率は良くならないよ…
ペアプログラミングなんてやってる余裕はないし、テストをしょっ
ちゅうやったりもできない。情報を共有している暇がないのであち
こちで不一致が生じて泥沼にはまっていく。


413 :デフォルトの名無しさん:02/05/25 13:44
>>411
>XPは火を吹いたプロジェクトの末期症状をモデル化したもの

理論に飛躍がありすぎ。
思い込みを吐露する前に関連書籍の一冊でも読んでよ。

414 :デフォルトの名無しさん:02/05/25 13:46
>理論に飛躍がありすぎ。
>思い込みを吐露する前に関連書籍の一冊でも読んでよ。

だからキミのレヴェルを示せば、それにあわせたレヴェルで話すと
いうとろーが。>本嫁厨房

415 :デフォルトの名無しさん:02/05/25 13:57
>ペアプログラミングなんてやってる余裕はないし、テストをしょっ

そりゃそうだろうね。が上級者がリアルタイムで見回って(なんかいい表現が
見つからないが)、要所要所でチェックを入れるってのは多々ある。
対等の関係のペアプロなんてものがあるのかね。

>ちゅうやったりもできない。情報を共有している暇がないのであち

そりゃやり方が悪いんだろ。火を吹いたプロジェクトを収束させるには、
テストは必要。これも要所要所に絞られるのは確かだが。時間をかけて
テストプログラムを作っている暇がないのはそのとおりだね。この場合
人間という便利なテストプログラムを人海戦術で代用することがあるけど、
人間は高価だから、その意味では効率がすごく悪いだろうね。

>こちで不一致が生じて泥沼にはまっていく。

それは火を吹いたプロジェクトから抜け出せずどんどん深みにはまっていく
パターン。火消し人はそういうプロジェクトに投入されると、まっさきに情報の
交通整理からはじめる。


416 :デフォルトの名無しさん:02/05/25 14:02
>XPは火を吹いたプロジェクトの末期症状をモデル化したもの

表現を変えよう(w

XPは火を吹いたプロジェクトから脱出できた状況をモデル化したもの


417 :デフォルトの名無しさん:02/05/25 14:09
>>416
うま!!座布団三枚あげて〜!!
大体 火の付いた C3プロジェクト でやったノウハウをまとめたものが、XP と思われ。

418 :デフォルトの名無しさん:02/05/25 14:15
飛躍というなら

>XPでは、それをプロジェクトが暗礁にのりあげてからでなく、
>最初からやっておけって考えだと思う。

それがうまくいくと考えるのが一番の飛躍だろうな。いわばXP公理
だから、これがただしか否かはXP内では論証できないはず。

XP信者は、かっこのいいお題目じゃなくて、これこそがXPのセントラルドグマ
だって宣伝すべし。

419 :デフォルトの名無しさん:02/05/25 14:24
一応いっとくけど411=416=俺なんだけど。
厨房が誤解するから、書き換えただけ。

411の後半が俺がいいたいことだ。

420 :デフォルトの名無しさん:02/05/25 14:28
>>418の論理の必要条件は、
「最初からXPを導入した事例がまだ存在しない。」
という命題が真であることである。
これには同意する?

421 :デフォルトの名無しさん:02/05/25 14:34
どのXP本か忘れたけど、実装時間の見積もりを各開発メンバに出させてさ、
進捗チェックに使ってたことあったじゃない。
それで、早めにメンバが煮詰まっていることをPLが見つけて、相談してさ。
結局、なにもしないまま手遅れになることを事前に防止できた。

これを、日常的な光景にしたいんだろうね。

上司と部下、開発者と顧客。
「なにもしないまま手遅れになる」ことを否定して、
そうならないために取るべき行動を列挙したもの。
XPってそういうのじゃないかな?
房なんでよくわからないけどね。 :p

422 :デフォルトの名無しさん:02/05/25 14:41
>>420
ん?
「最初からXPを導入した事例がまだ数多くは存在しない。」
なら同意する余地はあるが
「最初からXPを導入した事例が1つも存在しない。」
で同意すれば、否定されるだけだから同意しないけど(w

そんなむちゃな論法なら俺もいえるよ。
「XPを導入して失敗した事例がひとつもない」ことがXPが有効である条件であると。

つまらんよ。

423 :デフォルトの名無しさん:02/05/25 14:49
>それで、早めにメンバが煮詰まっていることをPLが見つけて、相談してさ。
>これを、日常的な光景にしたいんだろうね。

自分の進捗について寡黙な姿勢を好むPGは多い。もちろん
進捗状況の把握面ではもちろん困ったことなんだけど、可能な
範囲で本人の好みを尊重している。(結構見誤りのリスクが高いから
つらいんだけど、やっぱ本人に気持ちよく仕事してもらうのが効率
がいいから。)

XPだと、そういうPGでも気持ちよく語ってくれるのだろうか。
それともそうでないPGは去れと?

>上司と部下、開発者と顧客。
>「なにもしないまま手遅れになる」ことを否定して、
>そうならないために取るべき行動を列挙したもの。
>XPってそういうのじゃないかな?
>房なんでよくわからないけどね。 :p

だからXPに合わないってPGも多く出てくるんじゃないかな。
ま、どんな方法でも相性はあるから当たり前だけどね。

424 :デフォルトの名無しさん:02/05/25 14:52
>>422
422=411として話を進めるけど、結局あんたはXPは役に立たないと言いたいの?
スタンスがハッキリしないのでどうレスしていいか悩むんだけど。
ちなみに俺はXP肯定派です。

425 :デフォルトの名無しさん:02/05/25 14:56
>>404
だからOOPはスパイラルが不可欠ってのがOOPの考えだと思うけど。
スパイラルに比べてXPは急進過ぎ。少なくとも設計面では。


426 :デフォルトの名無しさん:02/05/25 14:59
>自分の進捗について寡黙な姿勢を好むPGは多い。

好んでるわけじゃない。
遅れてると言えば糾弾されるし、進んでいれば仕事を増やされるしで正直者が馬鹿
を見るシステムになってるから。
だからいつも「スケジュール通りです。」って答えざるを得ない。
イテレーション単位でタスクを分割すればPGの心理的負担はかなり減少するよ。

427 :デフォルトの名無しさん:02/05/25 15:04
>>424
>スタンスがハッキリしないのでどうレスしていいか悩むんだけど。

悪かった。ここでは否定派の立場で発言している。

ウォーターフォールが長い歴史をもつ仏教やキリスト教とすれば
XPは新興宗教だから、”売り出す”ための過激な教義に満ち満ちている。
「民衆を惑わず怪しげな宗教」の化けの皮を剥ごうじゃないか、というのが
ここでの俺のスタンスだ。

一方でXPの考え方を評価している部分もあるから、スタンスがわかりにくかった
かもしれないけどね。ここでの基本スタンスは否定派だ。

428 :デフォルトの名無しさん:02/05/25 15:37
>>426
>遅れてると言えば糾弾されるし、進んでいれば仕事を増やされるしで正直者が馬鹿
>を見るシステムになってるから。

これを根底から覆すのがXP。
遅れてると言えば普通に助ける(マイナス評価にはしない)し、
こなしたタスクの合計難易度が評価に直結するから、
やればやるほど得することになるシステムってことになる。

正直者が否定されて開発効率が低下するのが従来の方法なら、
正直者が肯定されるのがXPだね。

429 :ムリカイジョウシ:02/05/25 16:57
(自主的に)増やすか(マネージャーに)増やされるかの違いってことでいいわけ?
この程度を根本的な変革と喜ぶんならお手軽でいいね。どんどん自主的に仕事を片付けてくれたまえ。
もちろん君の努力を正当に評価するよ。ついては正当に評価するためにまめな進捗報告よろしく。
おや、君は今月「助け合い」がすくないようだね。君の助け合いの目標値と達成率をせつめいしてもらえないかな。



430 :デフォルトの名無しさん:02/05/25 17:02
>>411
>実際XPは火を吹いたプロジェクトの末期症状をモデル化したものそのものだ。

これは鋭いと思う。どの会社にも「火消しのエース」とか呼ばれる奴がいるだろ。
そういう奴のすることを「モデル化」したものだ。

> またXPは本当に効率がよいのだろうか?上のような状況ではメンバが必死だから、
> 高い効率になるのはいわば当たり前。しかしその状態をXPを用いたからといって
> 日常的に維持できるとは思えないし、維持すべきだとも思わない。

末期症状で目がつりあがったような状態、よくも悪くも「ハイ」な状態を継続す
ることはできない。しかし、そこで何が起きてるか、何が普段と違うのかを抽出
することはできる。「モデル化」っていうのはそういうことだろ。うまく抽出し
たものなら日常的に維持できる。それがXPなんだと俺は思う。

ただ、それでも非常に疲れることではあるから週40時間になってるんじゃない
の?

431 :デフォルトの名無しさん:02/05/25 17:46
>>430
そうなんだろうね。
でも週40時間のほうが開発効率がいいということが、
理解できない上司も多い。
時間かけりゃいいってわけじゃないことくらい、
何度か徹夜したことあれば、わかるとは思うんだが。

>>429
あえて皮肉を書いたってことは分かるんだが、あえてマジレス。
正当な評価ってのは、(それぞれのタスクの難易度が等しいと仮定するなら、)
10個のタスク終わらせた奴には、
1個しか終わらせない奴の10倍の給料払うってことだぞ。
それと、助け合いにノルマなどない。
あるのは、情報伝達の漏れによって開発が滞ったか、そうでないか、だ。
納品が遅れれば企業はダメージを受けるし、
納品が早ければ企業は優位に立てるわけだからな。

432 :デフォルトの名無しさん:02/05/25 19:01
>>431
> でも週40時間のほうが開発効率がいいということが、
> 理解できない上司も多い。

理解はしてるけど、開発効率を上げる(納期どおりに開発する)ことより優先す
べきことがあるんだよ。そして、週40時間でさっさか帰るってことがそれに反
してるんだろ。

433 :デフォルトの名無しさん:02/05/25 19:09
>>431
> 10個・・・10倍の給料

ほお、それでは0個の月は給料ゼロでいいわけだな。そんなんで落ち着いて作業できるのか知らんが、それが君の理想ってことでいいな?

434 :デフォルトの名無しさん:02/05/25 19:11
結局、作業量と給料の問題が解決しない限りは、
すなわち、残業やるー>一生懸命な出来るプログラマという
大嘘に傾きがちな一般人を再教育するシステムが必要なのだ。

XPマンセー。週40時間マンセー。
「その日程ではできません。」
こういう勇気をもとうよ。>PG諸君。
これをいえない環境で仕事しているから、
みんな不幸なのだ。

ボッタクリ価格マンセー。
それが余裕を生むのだ。

どの道結局、余裕のないプロジェクトは火を吹いて、
結局は払わされるんだぜ。>顧客の皆さん。

値切れば、安くなるという教育ループをまわしているから、
ウォーターフォールな発想はいかんのだ。

実際、マージンの部分はいくらでも削る見積もりだせるわけだし、
火を吹いたら、そこで交渉に持ち込めばよいというのが、
ひとつの知恵なわけだし。

でも、それをやってるから、PG側が嘘つきに見えるんで、
余計に厳しい価格と日程を指示するほうに学習しているんだよ。

ということで、オーダーメードなソフトウェアの値段は高いのだ。
それを受容しないから失敗する。

SUIT’Sカンパニーのスーツと、
一流オーダーメードと二流オーダーメードと、
近くのテーラーのオーダースーツと一緒に考えるのが
一般人。違いを認識させてやれー(爆)。





435 :デフォルトの名無しさん:02/05/25 19:14
>>431
> 情報伝達・・・

そういってくるやつは多い。そいつには望みどおりすべての情報を渡してやる。
たいてい次にくる文句は情報を整理して渡せだ。




436 :デフォルトの名無しさん:02/05/25 19:17
>>433
勝手に解釈すんなや。
一月で終わったタスクが0個なんてありえないよ。
実装作業の小さな単位としてタスクという概念があるんだから。
結局、0タスクしかこなせないってのは、
一ヶ月まるまる休んだ場合くらいにしかあてはまらない。

437 :デフォルトの名無しさん:02/05/25 19:27
>>436
あまり賢くないね。完全歩合性の給料こそが望みってことでいいのか聞いてるんだが?

438 :デフォルトの名無しさん:02/05/25 19:49
>>434
>「その日程ではできません。」
と言う以前に、客の求めるものがいつできるのか・どこまでできるのか
XPだと事前には何も言えないと思うのだが。

それでちゃんと「金を払おうと」言ってくれる客って一体どんな客なの
かが俺にとってXPの一番の謎。XPは確かに魅力的だが、顧客にはこれを
理解する洞察力と非常な勇気がいるように思う。

439 :ゴクアクジョウシ:02/05/25 19:55
>>431
>でも週40時間のほうが開発効率がいいということが、
>理解できない上司も多い。

最大化しようとしているのが「効率」ではなく「総仕事量」だから
なだけだろ。残業費なんてのは会社としてそんなにプライオリティ
は高くない。火を吹いているようなプロジェクトでは特にね。
いくら人件費がかかって破綻だけはさせたくないってのが、
正直なところ。破綻なんてさせたら次から仕事の受注に差し障る
からね。

PG諸君は気兼ねなく残業して、多少効率が悪くても
作業時間でカバーしてくれたまい。(w

一応形だけは残業時間削減を指示することはあるが、あくまで
仕事量を維持した上だってことを肝に銘じて置くように。



440 :デフォルトの名無しさん:02/05/25 20:05
たまに残業する分には効率が上がるにしろ、
残業が常態化すると定時内はだらだらやるようになって
仕事量は残業をしなかったころと変わらなくなってしまう、
とは「ゆとりの法則」だっけ?

441 :デフォルトの名無しさん:02/05/25 20:10
>>438
例えば2社でコンペさせて、作業もしてもらう。最終的によい方を採用。
それぞれの会社に払う金額は従来の1/2(採用した方には多少色をつける)。

顧客が払う金額は従来とかわらない。XPがそんなに効率がいいなら1/2の
金で十分だろう。(w

どうよ?

442 :教えてほしいです!:02/05/25 20:14
HTMLのことなんですけど、
ページを開くと他にも次々にページがでるようにしたいんですけど
どうやるかわかる人いますか?
いたらおしえてほしいです!お願いします!!

443 :デフォルトの名無しさん:02/05/25 20:25
ちょっとだけムリカイジョウシを返上してマジレスするが

火を吹いた状態だと、作業時間を抑えようとしても、PG自身が
プレッシャーから、作業をやめようとしないことが多々。
「いまそんな余裕はありません!」って逆に怒られてしまう。
そんな状態になった時点で現場が十分不健康になった証拠なんだけどね。

考えようによっちゃ、残業する/しないの文句がでる間はまだ健全。(苦笑)

444 :XP信者:02/05/25 20:35
>顧客が払う金額は従来とかわらない。XPがそんなに効率がいいなら1/2の
>金で十分だろう。(w

でも品質が2倍いいから、料金は変わりません。

445 :デフォルトの名無しさん:02/05/25 20:49
ほんじゃ、品質は1倍でいいから、料金を1/2にしてちょ。

446 :デフォルトの名無しさん:02/05/25 20:57
最後までコンペってのは難しくても、早いリリースを利用して途中まで
コンペ。期待できそうな会社の方を採用ってのはありかも。
なんにせよ顧客に目に見えるメリットがないとね。

447 :デフォルトの名無しさん:02/05/25 21:04
>>438
営業が「できますできます」と言うのを
話 8 分目くらいに顧客が聞くという現状と比べて大して変わらないと思うね。

448 :XP信者:02/05/25 21:06
>>445

それはメニューにありません。

品質が1/2で料金が1/2はどうです?

449 :446:02/05/25 21:06
XPでは顧客はいつでもプロジェクトを中断できるはずだし、コンペも禁止してないはずだし、
結構XPの精神に沿った上で現実に取り組んでもらうにはよい方法って気がする。
よもや短期のリリースだけで評価されるのが不満だとは言わないだろうしね。

450 :デフォルトの名無しさん:02/05/25 21:10
勘違いしてる奴はいないだろうけど、一応確認させてくれ。

●XPでは開発速度が上がり、顧客に高品質な製品を、納期通りに納品できるメリットがある
●PGの評価は労働時間ではなく、こなしたタスクの総難易度によって決定される

適正なスキル評価と、速い納品サイクル
これが大前提ってことでいいんだよね?

451 :XP信者:02/05/25 21:10
>よもや短期のリリースだけで評価されるのが不満だとは言わないだろうしね。

言わないに決まってます。
一つ一つのリリースが真剣勝負ですから。

452 :デフォルトの名無しさん:02/05/25 21:15
各機能が本当に必要なのかイテレーションごとに現実的に交渉し、削減できることは重要でんな

453 :445じゃないけど:02/05/25 21:16
>>448
それを望むと、どんなもんが出てくるの?

454 :デフォルトの名無しさん:02/05/25 21:21
客が交渉の結果、納得して削った半分の機能は実装されないまま納品されます

455 :XP信者:02/05/25 21:22
>>453

全日程のうちで顧客が重要だと考えている機能の上位半分が完成したものです。
つまり、XPでは顧客の重要度順に小規模リリースするから、半分いったところで
プロジェクトを終了させれば、半分の品質(コストで半分の機能のみ実装)の製品
を納めて完了します。

顧客は、もっと金をだしてもっと続けたければ続けられるし、もう十分だと考えれば
それで終了できます。

456 :デフォルトの名無しさん:02/05/25 21:35
XPの本じゃないけど、「the Goal」って本の内容はまさにXPの実践そのものだよ。
かなりおすすめ。

457 :デフォルトの名無しさん:02/05/25 21:41
機能と品質を混同してるような。
半分の品質を提示するためには品質を定量化できる必要があるけど
どうすればいいのか。バグの数を倍残すのか?

458 :デフォルトの名無しさん:02/05/25 22:07
XPの目指すところは承知しているつもりだしなるほどと
思う点も多々ある。

しかし、俺が今まで受けてきた仕事は、最初に期間と金額
と機能が決定するものがほとんどだ。

実際にXPを使う場合、「月々いくらで、翌月継続するかど
うかは前々月に決める」とかいう契約になるのか?

顧客の方に理解があったとしても、それで上司に支払いを
決済してもらうのは大変だろうと思うんだが。


459 :デフォルトの名無しさん:02/05/25 23:24
>458
そうだよ。
だから日本でブレイクしないんじゃないか。
ソースコードの行数アップなんてのはXPの狙いじゃない。
その意味で最大最高効率のソフト開発なるものをXPは狙っては射ない。
機能が決定しているなら、ウォーターフォールでよかろうさ。

ただ、機能の概要は決定していても、詳細まですでに決定しているというのは
普通ありえないだろう?だから、機能の詳細を検討する必要がある。

問題は、ソフトウェアの機能が非常に難しくなってきていて、
ユーザ側にも、必要なんだかいらないんだか、わからない機能が増えすぎているのが
本当の意味では金の無駄だというのが、XPの前提のひとつだ。
Wordの資格、MOUSとか持っているだけで就職有利になるのが、
パンピーの世界らしいぜ(苦笑)。
だから、ソフトウェアの仕様を学習するための期間が必要で、
それには、小規模リリースされたソフトウェアを使えないと
学習できないのさ。
そういう問題領域のときにXPが有効。

ソフトウェアの機能の80%は無駄。
これが、XPの前提としている20−80ルールだ。

まぁ、しかし、
3ヶ月ぐらいの試験プロジェクトとして開始して、
3人*100万円*3ヶ月=1000万円ぐらいの予算規模で
開始する約束でスタートして、
一ヶ月ごとに真剣勝負するスタイルなら別に問題なかろうさ。
機能が作りきれなかったら、ごめんなさい。
だけど、でもまぁ、多少ない機能があるぐらいのことなら、
よくある話じゃないか。許容しようぜ。大した機能じゃないんだから。

品質が安定していることと、
仕事を引き継ぐときのストレスがないのがXPのいいところだ。

3万行以上のソフトウェアのメンテナンスで、
100行毎に、なんじゃこりゃという驚かざるおえない事実を
発見するハメにかかわるなら、
おれはXPスタイルのもののメンテやりたいね。
だって楽だもん。
ゴミ仕様書なんていらないさぁ。





460 :デフォルトの名無しさん:02/05/25 23:26
>>457
>機能と品質を混同してるような。

そうだよな。
そもそもXPでちゃんとテスティングとリファクタリングの過程を経て作られたプロ
グラムに品質1/2なんてあり得んのだが。


461 :デフォルトの名無しさん:02/05/25 23:43
>>459

無駄な機能で思い出したんで最近やった仕事の例を紹介しておく。

顧客はある大手電機メーカー。
品質管理のためのデータウェアハウス系システム構築での事。
顧客側では製造ラインから品質管理部門まで多岐にわたる部署から上がってくる要
求をシステム部門が一手に引き受けてうちのチームと仕様を決めていた。
しかし、ご多分に漏れずシステム部門の担当者がオーバーフローして仕様を絞りき
れなくなった。結局は各部門からの要求をほとんどそのまま仕様に載せてしまい開
発工数もうなぎ上り。
そしたらシステム部門は経営層から相当叩かれたらしく、「機能ごとの使用頻度統
計をとるためのログ機能」なるものを追加しようとした。しかしそんな物を実装す
る時間も予算もあるはずが無く、当然のごとく却下。
そろそろ客もウォーターフォール型に嫌気が差してきた様子なので、次の仕事では
XPを提案してみようかと思う。

462 :デフォルトの名無しさん:02/05/25 23:55
>>457>>460よく言った!!

XP批判をすると宣言しながら俺はまだまだだな(w

いや、ちょっとね。某信者のXPに関する造詣に気負いして、突っ込み損ねた。
深く深く反省してもっとXPを叩くぞ(爆

463 :デフォルトの名無しさん:02/05/26 00:15
>>458
期間と金額と大雑把な機能は決めるけど、詳細はプロジェクトを
進めながら検討ってものもある。この種のプロジェクトははっきり
いって面白いが難しい。

お互い最善を尽くすという信頼関係がないとできない。信頼にこた
えられなくても打ち切られることは(よほどのことがない限り)ない
けど、おそらく次のプロジェクトはこないと覚悟する必要がある。

うまく工程表に当てはまらないので、外見上はウォーターフォールを
多段に繰り返すような形にし、さらに1つの段階内でも設計をわざと
あいまいにしてコーディング段階の自由度を増して対処している。

もちろん顧客とはどの段階でも頻繁に打ち合わせを行う。だいたい
プロジェクトの期間は半年〜2年ぐらい。

ウォーターフォール型で一番XPに近い形になるのかな。でもこれ以上は
歩み寄れないと思う。

んで、なまじこの手のプロジェクトの厳しさを知っているので、お気楽に
XPマンセーしてるのが許せないってのが俺の心情。(我ながら鼻持ち
ならない書き方スマソ。)

464 :デフォルトの名無しさん:02/05/26 00:22
>>461
相手のシステム担当者がそのレベルだと、XPにしてもやっぱ破綻するんじゃない?

465 :デフォルトの名無しさん:02/05/26 00:36
>3人*100万円*3ヶ月=1000万円ぐらいの予算規模で
>開始する約束でスタートして、

まあ確かに1000万ぐらいのプロジェクトだとXPはいいかもね。
もうひとつ桁が上がると無理だと思う。

466 :461:02/05/26 01:03
>>464

担当者自身は無駄な機能を実装しているという自覚や問題意識を持っているからこ
そ「ログ機能」を実装したいと言ってきたわけで、無能なのではない。
XPを導入することになれば当然顧客社内の意思決定プロセスも見直す必要が有るの
で、担当には相当汗をかいてもらう事になるだろうけど、それを補って余りあるほ
ど改善のメリットは大きいと思う。

467 :デフォルトの名無しさん:02/05/26 01:42
>485
ん?勘違いしていないか?
1000万円ぐらいからスタートして、
結局うん億円ふんだくるんだぞ?
ただ、そんな約束は最初にはしないだけ。

XPでは、長い約束はしない。
所詮、お互い気分が変わるからな。
だけど、軌道に乗り出せば、安定した開発になるので、
外側から見ると管理しやすい。

無能ならクビ切るだけだし、有能ならそのままキープしとけばよい。
判断が早くできる。

XPにすれば管理しやすくはなるんだが、
それで儲かるかどうか?本当に他社より安く良いものを
作っているかは別のことだからな。

ただいずれにせよ、納品後メンテナンスを発注側がやるなら、
XPで納品してもらったほうが断然良い。
コードが一定規則で書かれていて、
コードが一定の品質に保たれていて、
自分がもし機能拡張しようとして、
ミスをしても、ソフトのほうが教えてくれるんだぜ?

受け取るソフトとしてほぼ期待以上の水準だわな。



468 :デフォルトの名無しさん:02/05/26 01:53
>>466
煽りじゃなくてマジな質問なんだけど、XPだとどの辺が改善されると考えてるの?
例えば最初に実装する機能をどの部署の意見に基づいてどう決めるの?
XPといえども顧客側に分析力は必要だと思うけど。

ウォーターフォールで仕様が膨らむのは顧客側が積み残しを恐れるあまり、
いらないかもしれないけど、いるかもしれない機能を全部突っ込むから。

一度で分析できないような複雑かつ大規模なものは2段階とかに普通分けるはず。
ものの道理がわかった顧客+SEならね。それを一段階で済まそうと考えた人たちは、
その点やはり無能だと俺は思うんだけど?


469 :デフォルトの名無しさん:02/05/26 01:56
ということでだな。

おれとしては、
元請のほうは、旧来の基準で受注しといて、
次の下請けにおろすときに、
XPのユーザの役割を元請けのほうでやれば良いと思うぞ。
これが現実的な解決策さ。

元請様なんだから、当然受け入れテストぐらいは書けるわけだし。
仕様書沢山書いてお客をケムリにまくのも得意じゃろ。

ついでに、XPスタイルで発注しとけば、
別の下請けに引き継ぐのも容易だ。

元請けーRUP&CMMで、権威づけして高くふんだくる。
下請けーXPで楽々に開発。高速に学習できるプロセスを採用しているので、
技術力があがって、いずれは単価アップでハッピーだ。






470 :デフォルトの名無しさん:02/05/26 01:57
このスレなんだかものすごく面白くなってきた。


471 :468:02/05/26 02:06
ただ2段階に分けたときの落とし穴として、1段階目の稼動が遅れに遅れ、
当初予定した2段階目の開発開始時期を追い抜いてしまう場合。
この時2段階目の開始の延期を押し通せないと、1段階目のメンテをしつつ
2段階目の開発を開始するという地獄の苦しみを味わう。

472 :デフォルトの名無しさん:02/05/26 02:11
>>469
元請が顧客に出す「仕様書」はごまかしきれるものなのか?
XPなら仕様は確定しないわけだから、顧客にはでっち上げの仕様書を
渡して、元請の責任でつじつまを合わせることになると思うが、大丈夫?

逆につじつまが合わせられるような仕様書が作れるなら、ようは仕様が
最初から読みきれるわけで、ウォーターフォールでいいんじゃないの?


473 :461:02/05/26 02:27
>>466

まず機能の優先順位についてだけど、顧客側担当者もうちもどの機能が最優先かに
ついては実はちゃんと解っている。
それは製造ラインからDBへデータをストアする機能。
問題はそこからデータ参照系をどう作るかという部分で仕様作成が紛糾する事なん
だよ。
製造ラインから上がってくるデータは検査装置のハード的な制約が大きいからER図
が大きく変わることなんかまず無いし、変更が有ったとしてもせいぜいカラムのサ
イズがちょっと変わるぐらい。
ところが参照系となると、現場の人間ですらどのようなデータが見たいかを把握し
ていない。そんな状態で無理やり仕様をFIXしようとするもんだから機能てんこも
りのゴテゴテ画面がたくさんできてしまう。
というわけで、契約の段階ではデータ登録系の着手だけを確約しておいて、参照系
についてはイテレーションを使ってはどうかと考えている。

ちなみに、

>複雑かつ大規模なものは2段階とかに普通分けるはず

に関して言うと、今までも複数フェーズに分割してたんだよ。
ところが分割した各フェーズで仕様が膨らむといういたちごっこに陥ってしまって
いるとうわけ。
各フェーズは3ヶ月程度の期間があるのだけれど、そのうち1ヶ月は仕様作成に費や
されているんだよな。しかもFIXしたはずなのに変更が多発するし・・・

474 :デフォルトの名無しさん:02/05/26 02:33
仕様は確定しない?
そんなことはないぞ。
XPだって、作っている最中は仕様は確定している。
最初に全部の仕様をガチガチにしないだけだ。
開発項目になるものに関しては、外部仕様(受け入れテスト項目)
事態は確定しなくてはならん。

少なくとも、その項目の開発のイテレーションの終了までには、
受け入れテストという形で仕様は確定せねばならんのだ。

仕様が読みきれると見積もりが正確に出せるというのか?
それは本当なのか?

ソフトウェア職人気質によれば、
仕様があいまいな初期の見積もりは4倍の誤差がある。
20%設計作業が進行して、2倍の誤差になる。

ということで、シンプルにいえば、
元請けがきっちり4倍から5倍の費用を請求しておけば、
基本的には大丈夫のだよ。
だから、ボッタクレと言っているんだ。



475 :デフォルトの名無しさん:02/05/26 02:52
>というわけで、契約の段階ではデータ登録系の着手だけを確約しておいて、参照系
>についてはイテレーションを使ってはどうかと考えている。

なるほど、面白そうだ。(つい応援したくなってしまった。)

しかし

>ところが参照系となると、現場の人間ですらどのようなデータが見たいかを把握し
>ていない。

これはやっぱり(設計重視派の俺としては)分析に力をいれた方がいいと思う
けどなぁ。こんな状況でXPで顧客とPGを直結したら、振り回されっぱなしにな
るんじゃないの?(っていう考えがそもそも反XPなんだろうか?)

>各フェーズは3ヶ月程度の期間があるのだけれど、そのうち1ヶ月は仕様作成に費や
>されているんだよな。しかもFIXしたはずなのに変更が多発するし・・・

3ヶ月単位でも仕様変更が多発するのか。それは気の毒としか言いようがない。

俺に言わせれば顧客の担当者サイドのリソース増強か、外部コンサルタントを
雇うべきと思うんだけどね。どうしても重厚長大の方向で考えてしまう俺。

ま、でも興味深い話サンクス。



476 :デフォルトの名無しさん:02/05/26 02:55
>>474-475
横レスだが、XPで何度もプロトタイプをリリースして
仕様を固めていく(やっぱりあれも見たい、これはいらない)
ってことじゃないの?

各部署からの顧客がみんな常駐するわけじゃなくて。

なんとなく効果をあげそうな気がする。おれも応援したい。

477 :デフォルトの名無しさん:02/05/26 02:57
>>474
?よくわからんのだけど、元請がエンドユーザに対して出す
仕様書はいつ、どの程度の粒度のものを提出するのだ?

478 :475:02/05/26 03:19
>>476
レス番号書き忘れたが、>>475>>473に対するレス。>>474は別の話。

479 :デフォルトの名無しさん:02/05/26 03:21
ん?
別に以前と同じようにやってる振りしてればぁ?

ただし、重要なことは、機能の間の優先順位を常に把握するような
インタビューをして、開発側に指示することだ。

機能の詳細をきっちりつめて同意したハンコもらったというタイプの
仕様書を作る必要はない。

完全な矛盾なき仕様書の呪縛から逃れられるのなら、仕様作成もそれほど
負担じゃなかろうさ。



480 :デフォルトの名無しさん:02/05/26 03:25
>>479
君の言ってることは、わけわからん。

481 :デフォルトの名無しさん:02/05/26 03:30
>>479
雑に書きすぎ。意思疎通が図れてないぞ(w

482 :デフォルトの名無しさん:02/05/26 03:38
朝一にスタンダップミーティングって必須なんですか?

XPに興味わいてたんですが、Next Engineerとかいう雑誌で
「XPでは朝一番に全員揃ってスタンダップミーティングをするので
フレックス通勤などはできなくなる」
と書いてあったので社内ではXP反対派になりました。

しかし本当にフレックスやめてスタンダップミーティングなんかしてるの??

483 :デフォルトの名無しさん:02/05/26 03:44
>まず機能の優先順位についてだけど、顧客側担当者もうちもどの機能が最優先かに
>ついては実はちゃんと解っている。
>それは製造ラインからDBへデータをストアする機能。
>問題はそこからデータ参照系をどう作るかという部分で仕様作成が紛糾する事なん
>だよ。

優先順位が2段階なのは荒すぎるのでは(w
データ参照系の中でも優先順位をつけられないと、XPは無理と思われ。
(つけた優先順位が後になって変更されるのはよいけど。)



484 :461:02/05/26 03:55
>>483

確かにちょっと表現が乱暴だったかも。
一応参照系の中でも優先順位は有るには有るんだけど、守秘義務を破らずに説明す
るのが難しいもんで(w
当り障りの無いところで言えば、機能は帳票とグラフ表示とに大別できて、製造の
工程ごとに詳細部分がカスタマイズされているという感じかな。
そのなかでもグラフ表示のデータをどのように扱うかという部分がなかなか決まら
ない傾向にあるね。
多分グラフ表示だけXPに持ち込んでも相当な工数削減が望めると思うよ。

485 :デフォルトの名無しさん:02/05/26 04:26
思ったんだけど、XPには顧客側にコンサルタントが必要なんじゃないのかな。
そうじゃないと顧客は怖くてOKできない気が。

486 :デフォルトの名無しさん:02/05/26 04:31
>>485
コーチってそういう役じゃないの?

487 :デフォルトの名無しさん:02/05/26 06:36
>>486
コーチは開発サイドだよね。

488 :デフォルトの名無しさん:02/05/26 10:11
>>482 つかペアプロだと相手がフレックスとか言って遅れてきたら
ペアプロできないだろ(w

あと最近このスレ面白くなってきたけど、つまるところ客の予算に対する
考え方が非常に大きいと感じる。年度末決算で予算消化、とか、上期・下期で
事業部再編なんてのが当たり前だと、技術論と無縁のところで予算枠や
使い道が決まるから、XPはその辺で理解を得辛いかもなー。

要するに>>467のいうような形だと、年度内の「枠」を設定するお題目を
作り辛いから(えらいさんへの言い訳考えるの大変だわな)、開発費なのに
ランニングコストとして計上するような形になってしまうんだろうな。
稟議を通し辛いのは間違いないな。長文スマソ

489 :デフォルトの名無しさん:02/05/26 11:40
「つまるところ〜」と総括的な話にすると面白くなくなるのだよ。

490 :デフォルトの名無しさん:02/05/26 11:49
つまるところ、
XPのユーザというのは、
プロダクトマネージャに相当する仕事だ。
作業量が半端じゃないなら、チームを構成するしかないがな。
エンドユーザという意味だけでないことは確かだ。
ドシロウトには無理というのも確かかも知れん。
というより、怖いわな。そういう仕事は。


491 :デフォルトの名無しさん:02/05/26 12:01
>>482
スタンダップミーティング自体はかなり有効だと思う。
自分のなすべきタスクを把握できてないPGや新人がプロジェクトにいる場合はなおのこと。
しかし、XP自体はある程度以上のスキルをメンバーに要求しているので、
つまるところ、必須ではないと思われる。
12のプラクティスにも入ってないし。

つーか、やった方が効果あるならやればいいし、やるだけ時間の無駄ならやらなければいい。
それだけのことだと思うが。

>>488
サインアップ後、作業を始めてから遅れてくる奴はほんと困る。

ところでさ、PGが奇数だったらペアプロどうするの?
何か書いてあったっけ?

492 :デフォルトの名無しさん:02/05/26 12:15
JUnitを使いたいんだけど、
解説ページない?
いまいちよくわからない。




493 :デフォルトの名無しさん:02/05/26 12:43
>>492
http://objectclub.esm.co.jp/eXtremeProgramming/TestInfected-J.html

494 :XP信者:02/05/26 14:47
>>457
>機能と品質を混同してるような。

いい返しを思いつかなかったので、外部品質としてみました。

>そもそもXPでちゃんとテスティングとリファクタリングの過程を経て作られたプロ
>グラムに品質1/2なんてあり得んのだが。

もしXPが他の手法にくらべて効率が上がる場合、その品質保証によるところが
大きいと思うので、1倍の品質で効率だけアップっていうのもありえないと思うのです。


495 :デフォルトの名無しさん:02/05/26 15:44
>もしXPが他の手法にくらべて効率が上がる場合、その品質保証によるところが
>大きいと思うので、

なるほど。ってものわかりよすぎ>俺

496 :デフォルトの名無しさん:02/05/27 08:04
>>495
このスレ、2ちゃんのスレにしとくの勿体無さ過ぎ(w

497 :デフォルトの名無しさん:02/05/27 08:15
http://diary.cgiboy.com/d01/tsugeikuhito/

498 :デフォルトの名無しさん:02/05/27 12:47
29は豆の皆○わ だ。

499 :デフォルトの名無しさん:02/05/27 14:55
>>488
>考え方が非常に大きいと感じる。年度末決算で予算消化、とか、上期・下期で
>事業部再編なんてのが当たり前だと、技術論と無縁のところで予算枠や
>使い道が決まるから、XPはその辺で理解を得辛いかもなー。

顧客から見ればXPは予算内で顧客&開発両者がベストを尽くすわけだから、
ある意味ぴったりという気もするけどね。従来のように必要な機能とその実装
にかかる費用を加算して金額を決めるよりは。従来の方法でも、そこから予算
に合わせて機能の取捨選択を行って発注するのだから、最終的には同じ結果
になるはずだが。(もちろん違いは機能の決定を最初にするか、開発途上で
するかだ。)

ま、顧客&開発とも「仕様はこうですから〜」という安易な逃げが使えなくなるの
だから、常にエキサイティングなものになるだろうね。良くも悪くも。


500 :デフォルトの名無しさん:02/05/27 15:33
今だ!500ゲットオォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;


501 :HAMAIタンうぉっち:02/05/27 17:42
>>電車の中吊り広告が気になったので初めて東洋経済を購入しました。特集は

>>です。いろいろ面白いことも書いてありますが、そことなく強調されているのは
>>「ビジネス主導で開発を進めていくこと」です。

>みずほの場合は、むしろビジネス主導というか発注側の都合優先で失敗した例
>だと思います。

>システムダウンなどの動作しないという種類のトラブルを回避するだけなら、
>ビジネス主導よりも技術主導の方が確実性が高いです。

相変わらず馬鹿の一つ覚えでつまらん。うぉっちする気力を萎えさせる作戦か?

東洋経済の話は合併に伴う勢力争いよりもビジネスを重視しろって話なんでは
ないのかね。読んでないから確かなこといえんけど、記事の紹介を読む限りは。

少なくともHAMAIタンがいうような技術よりもビジネスを優先させろなんて話じゃないだろうし。


502 :デフォルトの名無しさん:02/05/27 18:30
>>499
> ま、顧客&開発とも「仕様はこうですから〜」という安易な逃げが使えなくなるの
> だから、常にエキサイティングなものになるだろうね。良くも悪くも。
顧客は常に「仕様とはかくあるべきだ」と提示し続けなければならないし、
開発は常に「その仕様を実装するのにはどれくらいかかるのか」を見積もり続ける必要があるね。

今まではそれらはSEというある種の独裁者が決定していて、顧客は納品物、
開発は仕様書を口をあけて待っているいわゆる「専制政治」だったからね。

個人的な妄想を行うと、XPは貴族政治、開発とテスタが分離していない、
立法を顧客が行い、行政を開発が行い、司法をテスタが行う3権分立が
俺の理想と妄想してみる。


503 :デフォルトの名無しさん:02/05/27 19:13
>>502
>今まではそれらはSEというある種の独裁者が決定していて、顧客は納品物、
>開発は仕様書を口をあけて待っているいわゆる「専制政治」だったからね。

おかしいな。専制政治の方が効率が機動性があって効率もいいはずなんだが。
といってみるテスト。

>人的な妄想を行うと、XPは貴族政治、開発とテスタが分離していない、

XPは原始共産制じゃないのかね。
ウォーターフォールは良くも悪くも官僚主義にどっぷり使った民主主義だと思うよ。
それとも立憲君主制かな。

>立法を顧客が行い、行政を開発が行い、司法をテスタが行う3権分立が
>俺の理想と妄想してみる。

俺の感覚では首相がSEだと思うんだけどね。民主主義の場合権限が大きければ
大きいほどそれを実際に行使する自由度は少なくなる。SEにもPGが思うほど自由度
はないよ。

504 :デフォルトの名無しさん:02/05/27 19:56
> おかしいな。専制政治の方が効率が機動性があって効率もいいはずなんだが。
> といってみるテスト。
「優秀な」専制君主の場合は効率も機動性も高い。
なぜなら自分=顧客であり、自分=開発者だから。

> ウォーターフォールは良くも悪くも官僚主義にどっぷり使った民主主義だと思うよ。
> それとも立憲君主制かな。
現在のウォーターフォールは立憲君主制説に1票。
特にこの板で「Sヨ」と呼ばれる人は君臨するだけで
統治はしていないのではないかと思う。

> 俺の感覚では首相がSEだと思うんだけどね。
仕様の決定 =法律の決定権
仕様の実装 =法律の執行
仕様のテスト=法律のチェックと考えていたのでそれでは違和感がある。


505 :デフォルトの名無しさん:02/05/27 21:12
>>499

XPは受託よりも派遣として扱ったほうがギャップが少ないと思われ。
チームごと相手会社に派遣ですな。作業場所は自社のままだけど。

506 :デフォルトの名無しさん:02/05/27 22:17
ずいぶんいいスレになったな・・1weekで・・・

507 :デフォルトの名無しさん:02/05/28 00:29
つまるところスレにもイテレーションが大切ということか

508 :デフォルトの名無しさん:02/05/28 02:12
XPは派遣か。考えようによっちゃそうかもね。時間で拘束して
作業内容は顧客の言いなりだから。

509 :508:02/05/28 02:13
だから40時間労働なわけだ。

510 :デフォルトの名無しさん:02/05/28 02:27
Σ(゚ロ゚;)ガーン

511 :デフォルトの名無しさん:02/05/28 08:11
>>507
スレにもリファクタリングが必要かといってみるテスト。

512 :デフォルトの名無しさん:02/05/28 08:34
>>508

真理かも知れない・・・と思うと萎えー(w

513 :デフォルトの名無しさん:02/05/28 12:13
ということでXPは派遣社員の管理に有効であるとの結論がでました。
同じ会社から集団で派遣にくるやつららにXPを実践させてみてください。

514 :デフォルトの名無しさん:02/05/28 12:22
>>513
集団で派遣にくるやつらに知識が蓄積

開発完了

そいつら撤収

ドキュメント残せや、ゴルァ!!

だめだ、こりゃ。

515 :デフォルトの名無しさん:02/05/28 12:26
>>514
逆に独りで XP やる場合を想像してみれ。

516 :デフォルトの名無しさん:02/05/28 12:56
>>514
顧客からみたらドキュメントのない成果物は、それと同じでゴルァなんだけどなぁ。
ま、派遣の場合保守契約が出来ないから、その点が違うか。でも発注先がつぶれれば
同じこと。

517 :デフォルトの名無しさん:02/05/28 13:02
>>516
しかし顧客でどれだけ真面目に ドキュメント 読んでるのか?と言って見るテスト

518 :デフォルトの名無しさん:02/05/28 13:06
>>517
そりゃ必要になるまで読まないんじゃない?
俺もソフトのドキュメントとかは必要になるまで読まないし。

519 :デフォルトの名無しさん:02/05/28 13:12
XPを使えば「僕は先のことをちゃんと考えて〜してるんです」とかいう
小生意気なPGを黙らせることが出来るってホントですか?

520 :デフォルトの名無しさん:02/05/28 14:40
>>511
レスはユニットテストを通してから書き込むべしと逝ってみるテスト

521 :デフォルトの名無しさん:02/05/28 14:52
>>501
案の定[XP-jp:03486]で突っ込まれてるし。必死で「僕のいうことが正しいんだぞー」とか
わめいてるガキだな。HAMAIは。

522 :Del房:02/05/28 15:49
リファクタリングすると確かにソフトウェアの保守能力は向上すると思われますが、
やはりパフォーマンスが落ちるという問題がありますね。
VC++ なんかだと国内版でもプロファイラはいくつか出てますが、
Delphi のプロファイラでお勧めのやつはありますか?できれば国内版がいいのですが・・・

523 :デフォルトの名無しさん:02/05/28 16:08
>やはりパフォーマンスが落ちるという問題がありますね。
ハツミミです。ほんと?

524 :デフォルトの名無しさん:02/05/28 16:37
>>522
なんでやねん。説明きぼーん。つーかどういうリファクタリングやったの?

525 :Del房:02/05/28 17:09
>>523
リファクタリング以前のソースは、1メソッド300行程度はざら。
凄まじいのは 1メソッド 800行以上ってあったっけか。しかも 条件分岐の嵐 (w
構造化型の可読性無視速度重視のロジックを

1.メソッドの徹底分割→当然CALLのオーバーヘッドが発生。
2.グローバル関数のメソッドオブジェクト化
3.一時変数の徹底削除によるメソッド、プロパティ呼び出しによるオーバーヘッドの発生。
4.パターンの導入によるクラスの大量発生(爆発まではしてない)
  それに伴う生成と破棄のオーバーヘッドの発生。

としましたッス。

ファウラーもこの問題は「リファクタリング」のなかで挙げてますね。
最終的に可読性が増す事により、真のオーバーヘッド発生箇所が
容易に追跡できるようになるとは述べているが、他のツールだとプロファイラは相当あるようですが
どうも Del だと国内ではプロファイラはないようで・・・



526 :デフォルトの名無しさん:02/05/28 17:54
>>525
盲目的に行うパフォーマンス落とす様な変更はリファクタリングとは
言えないと思う。

527 :デフォルトの名無しさん:02/05/28 17:58
>>520 レス書くときは、やはりペアレスか?

528 :デフォルトの名無しさん:02/05/28 18:15
>>525

>リファクタリング以前のソースは、1メソッド300行程度はざら。
>凄まじいのは 1メソッド 800行以上ってあったっけか。しかも 条件分岐の嵐 (w
>構造化型の可読性無視速度重視のロジックを

メソッド呼び出しのオーバーヘッドは相当な頻度で呼び出されるメソッド以外、
無視できると思うけどね。たとえば気にしなきゃならない相当な頻度とは
たとえばビットマップデータを1ピクセルごとに処理する部分とか(w

ま、そのメソッドが1秒間に何回ぐらい呼び出されるかは、リファクタリング
中も気にしたほうがよいと思われ。たとえば1秒間に高々1000回のメソッド
と100万回のメソッドを同一のポリシーでリファクタリングは不可と思う。

800行ってのは論外だけど。なんだそりゃ(w

>1.メソッドの徹底分割→当然CALLのオーバーヘッドが発生。

だからよほど高頻度で呼び出される処理でなければCALLのオーバーヘッドは
それほどないはず。

>2.グローバル関数のメソッドオブジェクト化

これも同様に普通は影響ないと思われる。

>3.一時変数の徹底削除によるメソッド、プロパティ呼び出しによるオーバーヘッドの発生。

ここが重要だと思う。一時変数を徹底削除というのは無謀だと思う。
使用頻度を考えないと。何も考えず「機械的に」何かやるのは
リファクタリングではない。

>4.パターンの導入によるクラスの大量発生(爆発まではしてない)
>  それに伴う生成と破棄のオーバーヘッドの発生。

生成&破棄のオーバーヘッドは非常に大きいから、高頻度で実行される
部分は使い回しをする必要があると思う。可読性とパフォーマンスのバランス
をとるときに一番注意しなければならない点。



529 :デフォルトの名無しさん:02/05/28 18:40
アスパラタンのサイトから。
http://tcup7006.tripod.co.jp/aspara_2000/bbs

やはりXP信者さんは高慢な口調が抜けないようでうねぇ。
HAMAIタンとアスパラタンの議論を見てみたい(w

残念ながら削除前の発言は保存してない。

--------------------------------------------------------------------------------

Re:やれやれ 投稿者:アスパラ(管理者)  投稿日: 5月28日(火)09時45分13秒

「ヴォケ」とか書いたら消されるのは当たり前です。

この誰でも解かりきった記事と「SE的視点」、それから「XP」と
どのような関係が御ありだと考えますでしょうか?
何故これが「SE的視点」なのか解からないのですが・・。

記事に挙げられたこれらの問題を解決するには
どのようにしたら良いと思われますか?
あなた自身の御意見を具体的に意見をお聞かせください。


SEといっても、ピンからキリまでいますので・・・。
半分以上は一般人かプログラマらしいですね。



--------------------------------------------------------------------------------
やれやれ 投稿者:XP信者  投稿日: 5月28日(火)07時47分13秒

消しちゃったな(苦笑)。
http://www.cqpub.co.jp/dwm/column/ito/dwm0039itom16.htm

SE的視点はこういうものだ。
乖離しないよう注意しなさい。


530 :デフォルトの名無しさん:02/05/28 18:52
でうねぇage

531 :fd:02/05/28 19:00
-------風俗の総合商社・MTTどこでも-------

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードSM奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種!
●楽しく遊べます! 090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
  http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入(日払い)月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://www.mttdocomo.jp/
------------------------------------------------



532 :デフォルトの名無しさん:02/05/28 19:13
XP信者は2chで行儀がよくて他の掲示板では「ヴォケ」とか平気で書く不思議な人です。
地は後のほうなんでしょう。

533 :デフォルトの名無しさん:02/05/28 19:54
>>528
> ま、そのメソッドが1秒間に何回ぐらい呼び出されるかは、リファクタリング
> 中も気にしたほうがよいと思われ。たとえば1秒間に高々1000回のメソッド
> と100万回のメソッドを同一のポリシーでリファクタリングは不可と思う。
後半は同意するが前半は同意できない。
たとえそのメソッドが1秒間に1億回呼ばれようが同じオブジェクトが
1億個生成されようが、まず考えられる最もシンプルな実装を行うべき。
まずは正しく動作するコードを手に入れるべきで、
チューニングは「本当に」そのコードが性能に影響を与えていることを
確認できてからでも遅くはない。


534 :デフォルトの名無しさん:02/05/28 20:13
>>533

>チューニングは「本当に」そのコードが性能に影響を与えていることを
>確認できてからでも遅くはない。

遅いと思うけど。煽るわけじゃないので念のため。
パフォーマンスをまったく無視したリファクタリングなど現実的に意味ない。

もちろん実行頻度が1000か1000000かも予想できない(低い)レベルの人
なら確認しながら進めるのに賛成だけどね。そんな人に実行頻度を
意識してコーディングしろなんていった日には、見当違いなことやりだすから。

いいたいことは1000か1000000かの見当ぐらいはつけるべきってこと。
だいたいそれでなきゃデータをメモリに置くかDBに置くかさえ、検討が
つけられないわけだから。



535 :デフォルトの名無しさん:02/05/28 20:16
ははは、アスパラたんのサイトのXP信者は私だ。
2chのXP信者さんとは別人だろう。

で、削除された内容は、大筋大体このとおり、

うーむ^2
必要な分析やってるだって?
その前に基本的な分析にミスがあるだろう。

書籍と作者の関係だが、
複数の作者によって書かれる書籍がある以上、
そこは、n対n関係でなければならんだろう。

ちゃんと分析できているようには見えない。
それなのに、廃棄日付などの枝葉末節に行くのは
しっかりしろや、ヴォケーと言った文脈だ。

ついでに、
同姓同名の別人が作者にはある可能性が高いので、
それらを区別するために、キー指定が必要になる。

入力データの処理のところで、どちらの同姓同名を選ぶかの
選択が必要になってくるが、ユースケースにきちんと反映されているのか?

書籍データも同様で、廃却日付のようなデータが必要なら、
同じ本を複数買う考慮が必要で、
すなわち個々の本を管理する必要があって、
ISBNではキーの役割を果たせない。

分析分析というなら、そういうところでの
コボシとかミスはまずすぎるということだ。
以下は追加。

n対nとか1対nとかの関係に無頓着すぎだな。
デザイン工程に入れない分析仕様を一生懸命書くタイプだな。
PGが従わないんじゃないかなぁ。

まぁ、これもあれも正規化やると決めた時点で
はまってしまった罠なんだが、
まだ気づいてはいないようだ。






536 :デフォルトの名無しさん:02/05/28 20:26
>>535
漏れはそれ、正しいとおもう、が、そういうのが理解(というより実感)出来てないアスパラたんに、それをぶつけても・・・

予想通りの結果になった、というわけですな。

537 :デフォルトの名無しさん:02/05/28 20:34
>ははは、アスパラたんのサイトのXP信者は私だ。
>2chのXP信者さんとは別人だろう。

いやぁ同じだと思うよ。(笑

538 :デフォルトの名無しさん:02/05/28 20:46
>>535
>n対nとか1対nとかの関係に無頓着すぎだな。

ん〜単にそういった話じゃないから書いてないんじゃないの?
純粋にどう分析していくかを考えてるわけだから、分析するのが
正しいかとかは、少なくとも同じ話題とはいえないし。

あるテーマに対してはそのテーマを中心に議論すべきで、そもそ
もテーマに議論すべき価値があるか、とかは別なスレでやるべき。
さらにいえばそういったスレは元のスレの議論が一段落した後に、
一呼吸おいて提出するぐらいの心配りがほしいけどね。

これは脊髄反射のHAMAIにもいえることだけどね。


539 :534:02/05/28 21:06
ちょっとだけ補足

>>533

>>4.パターンの導入によるクラスの大量発生(爆発まではしてない)
>>  それに伴う生成と破棄のオーバーヘッドの発生。

>生成&破棄のオーバーヘッドは非常に大きいから、高頻度で実行される
>部分は使い回しをする必要があると思う。可読性とパフォーマンスのバランス
>をとるときに一番注意しなければならない点。

この部分だけは、まずパフォーマンスが悪くてもシンプルでちゃんと動く
ものを先ず作ることに賛成。


540 :XP信者:02/05/28 21:34
>>534

>もちろん実行頻度が1000か1000000かも予想できない(低い)レベルの人
>なら確認しながら進めるのに賛成だけどね。そんな人に実行頻度を
>意識してコーディングしろなんていった日には、見当違いなことやりだすから。

相当高いレベルの人でも、パフォーマンスにクリティカルな処理の位置を
見誤る例が、XP本かリファクタリング本に載ってなかったっけ?



541 :XP信者:02/05/28 21:38
>>537

>いやぁ同じだと思うよ。(笑

別の信仰を持つ方には理解できないとは思われますが、
同じ信者にもいろいろな宗派があるのです。


542 :デフォルトの名無しさん:02/05/28 21:48
>>540
例えばどの話?
あげてくれれば同意するなり反論するなりマジにお付き合いするけど。
実はこれ話題に出したかったから。

543 :デフォルトの名無しさん:02/05/28 21:59
今週のいてレーションは失敗しました(・∀・)!

544 :XP信者:02/05/28 22:04
>>542

たぶんリファクタリング本の方だと思うんだけど(いま手元に無いので)
C3のプロジェクトで計算のパフォーマンスの原因が、特定のオブジェクトの
生成に集中してたって話。

プロファイルを取る前に数人のミーティングで想定したボトルネックは全て
本物のボトルネックでは無かった、というのが印象的だったので、
「計測してみるまでは分からない」って感じがあるんだけど。


545 :デフォルトの名無しさん:02/05/28 22:34
>>544
あーそういうレベルのやつであれば、すごく残念だけど俺の方に反論の余地ない。
外から表面だけ見てあれこれ考えてるだけじゃ絶対わからないネックはある。
こういうのは実際に各所の処理時間を計測していくしかない。あれこれソースを見て当てずっぽに直していくのは具の骨頂だ。散々苦労しても全然速度が変わらない。

しかしレアケースで予測が外れるからといって最初から予想さえしないのはどうかと思う。予測は必要。予測が外れる予測も必要ってのが俺の考えだ。

それにしてもオブジェクト生成のコストは本当に予測しにくい。ある程度の規模のOOPではプロファイラが必須と思ったり。


546 :XP信者:02/05/28 22:47
>しかしレアケースで予測が外れるからといって最初から予想さえしないのはどうかと思う。予測は必要。予測が外れる予測も必要ってのが俺の考えだ。

予測が必要ってのは同意。
でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
方が上だと思う。
これは、表面的なパフォーマンスに囚われやすい自分を戒めるためでもあるんだけど。

>それにしてもオブジェクト生成のコストは本当に予測しにくい。ある程度の規模のOOPではプロファイラが必須と思ったり。

で、Delのプロファイラはないのか、という話に戻る…。

547 :デフォルトの名無しさん:02/05/29 00:23
>>541
>別の信仰を持つ方には理解できないとは思われますが、
>同じ信者にもいろいろな宗派があるのです。

ワラタ

548 :XP狂信者:02/05/29 00:47
http://www.airclub.org/diary/

こいつでどや? Delphi Profiler


549 :XP狂信者:02/05/29 00:49
つーことで、アスパラたんのサイトのXP信者は
こちらでは、XP狂信者と名乗ることにした。

XPマンセー。マンセー。マンセー。

ハイル ベック、ハイル ベック、ハイル ベック。


550 :元質問者じゃないけど:02/05/29 00:57
>>548
ほーあるんだ。あとAirWebってDelphiで書かれてたんだー。2度びっくり。

> あきらめて、自前のデバッグルーチンを埋め込んで、プログラムの
>どの部分に処理のウェイトがかかっているのかを探っては、パフォー
>マンスのチューニングを行ってきたのですが、これはまるで printf で
>デバッグを行うのと同様な原始的な方法でした(不可能ではありませ
>んが)。そのため、僕のプログラムには 無数の EnterProfile 関数と
>ExitProfile 関数が埋め込まれています。30万行もあるコードになると、
>途方に暮れてしまいます。まさに干草の中から針を探す心境です。

いやぁ、身につまされる話ですな。俺もやったよ。


551 :デフォルトの名無しさん:02/05/29 00:59
じゃあ2chでは区別しやすいように「無印」と「狂」とでも呼ぼうか。

552 :デフォルトの名無しさん:02/05/29 00:59
XP信者=鍋タン
XP狂信者=手タン
でいいですか?

553 :デフォルトの名無しさん:02/05/29 01:23
無神論者ですが何か。
現世(プロセス)がすべてです。水が高きより低きへ流れるがごとく。

554 :デフォルトの名無しさん:02/05/29 01:59
>>553

アスパラたん、いらっしゃーい!

555 :XP狂信者:02/05/29 02:29
にしても、やっぱりアスパラたん終わってるねぇ。

ドシロウトー>アラシと決め付けられちゃったよ(笑)。
保守やったことないやつに、保守の大変さ教授されちゃったさ(シクシク)。

まぁ、プロセスだけじゃソフトウェアなんざ作れない。
机上の分析だけでソフトは作れない。
知識だけが必要なのではない。知恵が必要なのだ。

ドシロウトにはわからない領域のようだけどね(爆)。






556 :デフォルトの名無しさん:02/05/29 02:41
>>555
おれはアスパラではないが、

机上の分析を研究(?)してる学生相手に、机上の分析じゃ現実の仕事は
できない、と説教たれるのもどうかと思うけど。

557 :XP狂信者:02/05/29 02:50
まぁ、どうかとは思うんだが、
ほうっておくと、そのまま変な方向走っていくからねぇ。
ちょっと修正かけてやろうかとおせっかいしてみただけさ。

分析は重要さ。だけど、それを実装コードまで落とさないと、
分析の学習は完了しない。

分析段階であのレベルのモデリングでは、
設計段階で、どんどん変な構造に行き着くのは見えているんだが?
その点どうよ?

おそらく完了しないプロジェクトになる。
例の分析マヒってやつな。

RUPには、私もしんどい思いをした経験があるので(笑)、
予定通りそれにはまることになるやろうね。
まぁ、あたたかく失敗を見守ってやるしかないかな?
予定では、そこでXPに改宗するんだがなぁ。
アレルギーがあるのがどうにも(苦笑)。



558 :デフォルトの名無しさん:02/05/29 03:15
DBの辺りってあまり経験ないんだけどついでに聞いていい?

XPでもスパイラルでもウォーターフォールでも何でもいいんだけど、
当初の設計じゃどうにもならなくなって、あれこれ変更せざるをえなく
なったとする。

プログラムを変更は、まあさておき、DBの変更はどう考えれば
よいざんしょ?とくに変化ヲ抱擁しなければならないXPとかは、
DBの構造も柔軟に変更するのかな。

コンバーターをつくるってのが月並みな発想だと思うんだけど。
なんかそれ以外に変化に対応しやすい設計のコツとかがやっぱ
あるのかしらん?


559 :XP狂信者:02/05/29 06:56
DBまわりは14番目のプラクティス

最新のスキームで日々作業

というのが、標語。

結局、XPの場合は、常にNOW (フッルー)
Up to dateな状態が必要と考えられているわけよね。

まとめてドーンという発想は嫌われる。




560 :Del房:02/05/29 08:56
>>548
おぉ!サンクスコ!!

http://www.turbopower.com/products/sleuthqa/

見にいったら QA Suite 3 が出てたね。
しかし日本語版を売り出そうってところはないのかだろうか。。。鬱
Delphi 関連のこの手のツールって、よほど売れんと考えてんのかね?

561 :Del房:02/05/29 09:04
>>560
ついでだが。。。

> でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
方が上だと思う。

同意!
漏れ的には、リファクタリングを行なっている際には、徹底してソースの可読性のみにこだわってもいいと考えてる。
その後、パフォーマンスを計測して問題箇所をつぶして行けばいいだろうに。。。


562 :デフォルトの名無しさん:02/05/29 09:41
>> でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
>方が上だと思う。

>同意!
>漏れ的には、リファクタリングを行なっている際には、徹底してソースの可読性のみにこだわってもいいと考えてる。
>その後、パフォーマンスを計測して問題箇所をつぶして行けばいいだろうに。。。

なんか微妙に違うような気が

563 :デフォルトの名無しさん:02/05/29 10:25
>>562
「リファクタリング」読んでる?

564 :デフォルトの名無しさん:02/05/29 10:30
>>563
でた!本嫁厨房

565 :デフォルトの名無しさん:02/05/29 10:39
どこのml/bbsにもいるな。教科書の内容を踏まえた上で実践編の
話をしてる時に、教科書から一歩も出ない内容を力説してしらけさせるやつ。
HAMAIのようやつってのが一番わかりやすいが。

566 :デフォルトの名無しさん:02/05/29 10:42
>>558-559
「スキーマ進化」とかってどうなのかね。
こういうのって実際に使われてるのかな。


567 :デフォルトの名無しさん:02/05/29 10:47
>>563
何事も一気にやるのがXPに反しているといってる。
リファクタリングにしても可読性&パフォーマンスを常にチェックしながら行うべきということ。

568 :デフォルトの名無しさん:02/05/29 10:54
濱井ってmemo-mlとoosquare-mlにも出没してるけど、やつの発言にレスが
つくのはxpmlだけなんだよなぁ。なんでだろ。

569 :Del房:02/05/29 11:00
>>567
> 何事も一気にやるのがXPに反しているといってる。

なるほど。といっても XP 自体には全然こだわってなかったりして (w
個人的には使えそうなプロファイラ教えてもらったんでよしとしときます。

570 :デフォルトの名無しさん:02/05/29 11:06
だめだ〜。このXP信者の恩を受けた以上、お前もXP信者になるのだ〜

571 :デフォルトの名無しさん:02/05/29 11:08
XPはフリーメーソン。
半分マジ

572 :Del房:02/05/29 11:13
>>570
ん〜・・・と、独りで作業してるんで、ペアプロできません。
こんな漏れでも XP 信者になれますか? (w

573 :デフォルトの名無しさん:02/05/29 11:57
>>568
濱井タンにも困ったもんだね。

574 :デフォルトの名無しさん:02/05/29 13:40
誰かに相手してもらいたいんだよ。
2chに飽きたらmlに投稿するのさ。
きっと会社じゃ干されてるんだろうよ。

575 :デフォルトの名無しさん:02/05/29 13:43
>>572
ってことは800行のメソッドも自分で書いたのか。なんとまあ。

576 :Del房:02/05/29 14:38
>>575
それは4年前、今よりもっと厨房だった時代に書いたもんです。。。あぁ!

577 :デフォルトの名無しさん:02/05/29 17:30
>>557

>まぁ、どうかとは思うんだが、
>ほうっておくと、そのまま変な方向走っていくからねぇ。
>ちょっと修正かけてやろうかとおせっかいしてみただけさ。

アスパラタンが考察してるのは彼が言うところの

|ファウラー氏の文献、「分析パターン」やら「エッセンス」などの、
|良い設計では、属性を書き出してから判断基準に基づいて分割せず、
|実体のみを直感的に分割してしまうという、離れ技をやっている。

この「直感」の部分を人間が頭の中でどう処理しているのか?
って部分だと思うよ。要件の分析じゃなくて分析を行う人間の
思考の分析。

引用部分が正しいとも思ってないし、彼の考えを支持するわけでもないけど、
まあ”研究”テーマとしては面白い。いまの延長で何らかの成果を残せるかも
懐疑的だけど、研究しちゃいけないわけじゃないし。

>分析は重要さ。だけど、それを実装コードまで落とさないと、
>分析の学習は完了しない。

彼がしたいのは学習ではないんでしょうな。きっと。

>分析段階であのレベルのモデリングでは、
>設計段階で、どんどん変な構造に行き着くのは見えているんだが?
>その点どうよ?

くりかえしになっちゃうけど彼がやろうとしているのはデータの
モデリングじゃなくて、人間の分析のモデリングではないかと。

>おそらく完了しないプロジェクトになる。

だから完了なんてするわけないし、完了するか否かなんてのは
眼中にないんじゃないかと。

>例の分析マヒってやつな。

そうね。同じプロジェクトのメンバがこんなこと考えてりゃ、
ひっぱたいて目を覚まさせるけど。

>RUPには、私もしんどい思いをした経験があるので(笑)、
>予定通りそれにはまることになるやろうね。

設計&実装にたどり着けばそうなるだろうね。

>まぁ、あたたかく失敗を見守ってやるしかないかな?
>予定では、そこでXPに改宗するんだがなぁ。
>アレルギーがあるのがどうにも(苦笑)。

いやいや、一度や2度の失敗でへこたれるようじゃダメ。
なんどもなんども失敗を繰り返し反省を繰り返し、どんなに
時間と情報と知能があったところで、人間の分析&設計能力には
本質的に限界がある、と絶望しないとね。そこからが出発点。
それでこそ筋金入りのXP信者に(w





578 :XP狂信者:02/05/29 21:54
DBまわりの設計。

基本的にSQLはあまり多用しないほうが、OOPでは楽だね。
RDBは、RDBでER図に発展してくわけで、
ER図は、UMLのクラス図だから、自然な対応関係はある。

そこを基本におさえた上で、クラス定義を行う。

で、単にRDBは、シリアライズ(あるいはPersistant Object)コンテナ
だと思って扱うのが、僕の趣味だなぁ。

これで、きっちりクラス定義しとけば、
単純なスキームの変更はじょじょに対応可能かと。

じょじょに変更していく、いっきにドーンを避ける。
やる前とやる後にバックアップをとる。
やる前とやった後で動作に違いがないことを
確認するためのテストプログラムを書く。

こんなとこじゃない?XPスタイルは。

ところでリリース間隔はどうなってるの?
運用DBをどーんはやっぱり怖いと思うよ。
特に、SQLをばらまいた設計やってると。

だから、データ構造設計は、きちんとという
分析屋の意見にも一理あるわけだし。




579 :XP狂信者:02/05/29 22:01
オレがXP狂信者になった理由だけど、
話題だからという理由で本を買って読んだわけさ。

微妙に近いところにいながら、オレさまには欠けているポイントを
いくつも羅列させられていて頭痛くなったのさ。

ところが、どれもこれもよく考察していくと、
「おばあちゃんの知恵」なんよねぇ。
そういうことぐらいは理解できる賢さはあったので(自爆)
もう参りましたさ。
今ではぞっこんラブラブです。

XPには知識はそんなにはない。
でも、知恵の宝庫なのだ。

結局、ここにつきるのよね。






580 :XP狂信者:02/05/29 22:14
>>577
了解。わかったよ。
結局、若いってことなんだよね。
大昔コンピュータを勉強しはじめたころ、
全てが計算できると信じてた(爆笑)。
数学の定理をコンピュータでばんばん発見できると思ってた。

彼の場合は、それが全部自分の頭で分析できると信じているわけだよね。

おれは、将棋もやるんだが、せいぜい15手ぐらいの詰め将棋解けるぐらいさ。
でも、200手以上の詰め将棋解けるプロ棋士ってのもいるわけで、
アスパラたんはそれになろうとしているらしいってことかね(苦笑)。

右脳の使い方が下手そうなのが危惧している部分なんだけどね。





581 :デフォルトの名無しさん:02/05/30 11:49
ageとこ

582 :デフォルトの名無しさん:02/05/30 14:27
>>580

漏れは青木淳さんの本に引用されていた
「デザインはフォルムの実現にあるのではなく,『ぴったりしないもの』の排除にある。」 ----Alexander
が転機だったよ。

bestは得られない。できるのはbetterの積み重ね。

583 :デフォルトの名無しさん:02/05/30 14:46
>>576
プロファイル&チューニングに成功したら、どんなとこがネックになってたのか
レポートきぼん。

584 :デフォルトの名無しさん:02/05/30 14:53
あとオブジェクトの生成のコストを避けるための使い回しとか
単純なメソッド呼び出しのオーバーヘッドの削減は、将来的には
言語自身が行うべきと思う。オブジェクトのキャッシング(?)

CやC++の場合プログラマが行っていたオブジェクトの解放を
javaとかが自動で行うように。(まgcの技術は大昔からあるわ
けだけど。)

10年ぐらいしたらオブジェクトのキャッシュはシステムに任せるか
プログラマが行うべきかの論争が起きたりして。


585 :デフォルトの名無しさん:02/05/30 14:55
>右脳の使い方が下手そうなのが危惧している部分なんだけどね。

漏れもそう思う。(右脳/左脳って言い方は好きじゃないけど)

586 :XP狂信者:02/05/30 21:57
ところで、CMMに詳しい人に質問だが
アスパラたん、
PSPで1万行っておっしゃってますが、
一日で一万行の意味?
どのくらいの期間の話?

一万行って、別に設計書いらない水準の話だけど、
そんなにプロセスいるんだっけ?
あー、わからん(^^^;
そんな大げさな話なの?


587 :Del房:02/05/30 22:37
>>583
りょうかい〜ん!!
ちゅうても QA Suirt すんなり導入できるんだかは未定だったりして(w

588 :デフォルトの名無しさん:02/05/31 00:23
ここは宗教スレですか?信者ってナニ?狂信者って狂ってるの?

合理的な判断努力の積み重ねだと思うけど...。
合理的な判断の結果信者になるのは、敗北だと思うが。


589 :デフォルトの名無しさん:02/05/31 01:51
俺が個人で書いた最大はだいたい200万行。半年かけた。(過去に書いた
コードを流用した部分もあるある。)プロジェクトに参加したのは俺一人では
ないが、主要コードの大半は俺が書き、残りもすべて把握していた。

そのうちUIや単純なデータ処理の部分(早い話コピペ&手直しですむ部分。
処理は複雑ではないが量がかさばる部分。)は1/3ぐらい。後はアルゴリズム
が売りの部分。(どういった分野かは話せないが)

顧客は非常に優秀でかつ協力的。要求分析やアルゴリズムについても相互に
相談しあえる良好な関係だった。これは俺ではなく顧客の人徳に負うところが多い。
打ち合わせは頻繁に行われ、(アルゴリズム勝負のソフトゆえ)常に試行錯誤の
繰り返しだった。

そのプロジェクトは成功した。が、はっきりいえば自分の頭の限界を自覚もした。
どうがんばってもこれの10倍のコードは自分の頭に入りきらないだろう。コード
のすべてを把握し高い機動性をもって仕様変更に柔軟に対応することは、一人
の人間では(時間の制限がなくても)無理だ。と。

一般に開発は少数精鋭の方が効率がよいといわれている。俺もそうおもう。
しかしどうなのだろうか?時間さえ無限にあればどんな大規模かつ複雑な
ソフトでも、少人数で開発可能なのだろうか。

人間の頭の中に入りきる容量には限界があり、それを一次キャッシュとみな
せば、それを上回る規模のソフトは、効率が落ちるのではないだろうか。

XPでしばしば、少人数でも徐々に拡張していけば大規模なプロジェクトも
可能ではないか、という。自分のつたない経験でそれを否定するつもりはな
いが。。。


590 :デフォルトの名無しさん:02/05/31 02:10
>>586
1万行か。個人で請け負うなら手ごろな大きさだね。

591 :デフォルトの名無しさん:02/05/31 04:53
イテレーションを繰り返せばXPで大規模ソフトも開発可能なんて与太話
信じているやつはいない。

592 :XP狂信者:02/05/31 06:24
>>590
そうそう、その手ごろな領域のところだよね。
まぁ、標準プロセスなんだから、
そんな大げさな話はあるわけもないとも思うのだが、
ちと志が低すぎないかと(苦笑)。


593 :デフォルトの名無しさん:02/05/31 10:09
スペースシャトルのソフトは420,000行らしいよ。


594 :デフォルトの名無しさん:02/05/31 12:31
>>593

そんなに少ない行数なの? すごいなぁ〜。
スペースシャトルの空調管理システムのソフトとかじゃないよね?
つーか、ソフトって何をさしてるの? システム?


595 :デフォルトの名無しさん:02/05/31 12:39
行数が少ないほうが安全なんだろ。

漏れだったら、可読性の良いシステムに命をあずけるけどな。


596 :デフォルトの名無しさん:02/05/31 12:44
スペースシャトルって行数あたりのコストがものすごく高いんだったよね。

597 :デフォルトの名無しさん:02/05/31 12:44
>>593
あれって5台ぐらい同じ処理するコンピュータのせてて多数決するんじゃなかったっけ。

598 :デフォルトの名無しさん:02/05/31 12:53
>5台ぐらい同じ処理するコンピュータのせてて多数決
アウトプットは同じだと思う。

599 :デフォルトの名無しさん:02/05/31 13:21
>>598
ん?どういう意味?故障とかバグを多数決で回避するってことだよ。

600 :究極の選択:02/05/31 13:26
CMMで開発されたシャトルとXPで開発されたシャトルのどっちに乗りたいですか?

601 :デフォルトの名無しさん:02/05/31 13:36
大気圏外は宇宙線による誤動作がすごいからね。

602 :デフォルトの名無しさん:02/05/31 13:45
>>600
どっちでやっていようが、ソフトウェアテストは、通常のアプリのそれとは全く比較にならんよ。

603 :デフォルトの名無しさん:02/05/31 14:10
そういやNASAが保守部品として8086をかき集めてるよね。PC9801のV30でもいいのかな。

604 :デフォルトの名無しさん:02/05/31 14:15
>5台。。。

科学者としてのスペースシャトル、母としてのスペースシャトル、以下略としての
スペースシャトル、極寒ネタとしてのスペースシャトル。。。

605 :デフォルトの名無しさん:02/05/31 14:44
>>604
なんと・・・NASAって実は「補完」を企んでいたのか。

606 :デフォルトの名無しさん:02/05/31 14:49
>>593
原発もそうだけどそういった人命に関わるシステムは
ソフトは限りなく少なくして、
多重冗長化構成にしたハードによってリスクを抑えてる。

607 :デフォルトの名無しさん:02/05/31 15:21
>>605
密かに エヴァシリーズ を開発しているという話もある。

608 :デフォルトの名無しさん:02/05/31 15:26
惑星間ネットワーク(とりあえず地球と火星だったkな)の構想を
練ってるワーキンググループがあったような。

609 :デフォルトの名無しさん:02/05/31 15:27
地球と火星でペアプロするにはどうすればいいんですか?
リアルタイム通信がだんだん辛くなってくるんですけど。
てゆーか日本<->アメリカでペアプロするには?

610 :デフォルトの名無しさん:02/05/31 15:29
>>604
自爆装置は5台が一致しないと作動しない設計ですか?

611 :デフォルトの名無しさん:02/05/31 15:45
>>609
どこでもドアー 常時接続バージョン を使いましょう。

612 :デフォルトの名無しさん:02/05/31 16:53
>>611
漏れはまだ深夜のどあほーだいなので、昼間は接続料金が気になります。

613 :デフォルトの名無しさん:02/05/31 17:48
>>609
日本伝統のプロトコル、以心伝心と阿吽の呼吸を使います。

614 :デフォルトの名無しさん:02/05/31 18:44
>>600
XPだな

615 :デフォルトの名無しさん:02/06/01 00:24
>>613
そのプロトコルにはまだ国際化対応の部分にバグがあるそうです。


616 :デフォルトの名無しさん:02/06/01 00:44
>>614
顧客がストーリーを書き忘れたので、そのシャトルには帰還プログラムが実装
されていなかった。キミは軌道上をさまよう人工衛星となった。

-- Game Over --


617 :デフォルトの名無しさん:02/06/01 00:48
XP(狂)信者の人にお伺いします。HAMAIタンとアスパラタンで
ペアプロさせるにはどうしたらいいでしょうか。


618 :XP信者:02/06/01 01:16
改宗させる。

619 :XP信者:02/06/01 01:40
http://www-6.ibm.com/jp/developerworks/java/020125/j_j-diag0911.html#8

の記事で、

>そして、この疑問に代えて、「どうしたら、テストできる方法でこのコードを書け
>るか?」と自分自身にしばしば、テストを容易にするという目的だけに寄与する
>機能を多く追加することになります。

というのがあります。

個人的には、テストのみにしか使用できない機能を付加するのは非常に抵抗が
あるんですが、テストのためのテストって気がしませんか?

テストをし易い構造にするってのが正道だとは思うんですが。

620 :デフォルトの名無しさん:02/06/01 02:40
プログラムの品質って、どうやって計るの?、どうやって見せるの?

621 :デフォルトの名無しさん:02/06/01 03:17
>>619
テストしやすい構造にするってのと
テストのみにしか必要のない機能を追加するということは
同じことだと思っている。

テストが容易になるのなら構造をバンバンいじるべき
最初は抵抗があったけどね。

>>620
その辺のまっとうなプログラマに見せれば、それなりに判断してくれると思う。
何らかの手法で計測したくなったりするかもしれないけど、
それは悪魔の囁きなので気をつけること。

622 :デフォルトの名無しさん:02/06/01 03:21
>>620
顧客が「使える」と思うかどうか。

623 :デフォルトの名無しさん:02/06/01 03:24
テストコードを埋め込むってのは、突き詰めれば、起こりえないはずの状態が起こるか否か
をチェックすると思う。アサートとかはね。

外部のテストコードによるテストは、起こりえるすべての状態においてプログラムが期待通り
動くか否かをチェックする。

性質的に一方が他方で代用できるものじゃないと思うけど。

事前条件、事後条件、不変条件とかはコンパイラがすごく賢くなって、これらの静的な
整合性のチェック(方チェックみたいに)まで出来るようになると面白いんだけどね。
これにはまだ時間がかかりそう。

624 :デフォルトの名無しさん:02/06/01 03:25
方チェック->型チェック

625 :デフォルトの名無しさん:02/06/01 03:30
品質=(稼働時間)/(クレーム数)

ひゃひゃひゃ。(クレームゼロの場合困るな。)

626 :デフォルトの名無しさん:02/06/01 03:41
>>617-618
改宗しても一日の大半はお互いの価値観の議論に消費されそうだ。
一般に別々の人間が本当の意味でペアプロできるほど価値を共有する
なんてことはありえん。ペアプロがうまくいくなんてのは、所詮ごまかしだよ。
まあ、そうなると結婚なんてのもありえないはずだけど、それはごまかしの
許容範囲内ってことだな。

つまり相性がよい相手としか開発できないわけだよ。小学校で好きな人と
グループを作りなさいってのとおんなじ。そのうち仲間はずれにされて
「会社がXPを採用したため不当な精神的苦痛を受けた。XPは労働基準法
違反である」とかって会社が訴えられたりして。



627 :デフォルトの名無しさん:02/06/01 03:50
>まあ、そうなると結婚なんてのもありえないはずだけど、それはごまかしの
>許容範囲内ってことだな。

なるほど、面白い結婚観をお持ちですね。
続きは、結婚板で議論しましょう!!


628 :デフォルトの名無しさん:02/06/01 04:03
>>623
テストを容易にするための機能であって、アサートじゃないのでは?

あと、勝手にアサートしてくれるコンパイラがあるということは、
コンパイラがプログラムの文脈を理解するということで、
大部分のプログラマが必要なくなる一歩手前なような気がする。
俺はとても困ります。

629 :デフォルトの名無しさん:02/06/01 04:12
>>628

文脈の理解は必要ない。そんなことが出来るならAIとかの話になっちゃう。
俺が言ってるのは前段のメソッドの事後条件が後段のメソッドの事前条件と矛盾しないか否かのチェック。
矛盾すれば間違っていることがわかる。矛盾しないからといって正しいとは限らないって程度の話。

630 :デフォルトの名無しさん:02/06/01 04:15
>>629
Eiffel や D みたいなやつ?

631 :デフォルトの名無しさん:02/06/01 04:16
>>628
テストを容易にするための機能ってのは、あとどんなものがあるの?

632 :デフォルトの名無しさん:02/06/01 04:16
>>630
そゆこと。

633 :XP信者:02/06/01 04:23
>621
>テストしやすい構造にするってのと
>テストのみにしか必要のない機能を追加するということは
>同じことだと思っている。

そうですか?
テストのみにしか必要のない機能ってのは、例えば

http://www-6.ibm.com/jp/developerworks/java/011109/j_j-diag0612.html

の記事の「全てのオブジェクトにRecorderを実装する」ってのが該当すると
思うのですが、このRecorder機能って完全にテストのためだけですよね。

自分だったら、全てのオブジェクトにRecorderを実装する変わりに、
全てのオブジェクトをRecorder機能を持つスタブと交換できるように
インタフェースを定義したくなります。

上の記事の例でいえば、Sender、 GreeterにRecorder機能を持たせる
変わりに、Sender、Greeterと交換可能なRecorder機能のみを持つ
SenderRecorder、GreeterRecorderを定義し、Coordinatorのユニットテストでは、
そっちの方を使用します。

SenderにRecorderを組み込むのと、SenderのかわりにSenderRecorderを使用
してテストするのでは、意味合いが異なると思います。
これは、自分が組み込み系のせいで、リリースコードにテストコードを入れてお
きたくないという想いが強いせいかもしれません。


634 :デフォルトの名無しさん:02/06/01 04:44
>>633
テストも製品の一部であると考えれば、
パフォーマンスに影響なければテストがしやすいように
テストのみにしか必要のない機能を追加することに躊躇すべきではないとも言える。
機能追加を避けることでテストが不十分になる可能性があるならね。

ただ、「テスト・コードの製品コードからの分離」 を謳うならば
やはりスタブを使うのが正しいか。

635 :デフォルトの名無しさん:02/06/01 05:08
>>633

>上の記事の例でいえば、Sender、 GreeterにRecorder機能を持たせる
>変わりに、Sender、Greeterと交換可能なRecorder機能のみを持つ
>SenderRecorder、GreeterRecorderを定義し、Coordinatorのユニットテストでは、
>そっちの方を使用します。

呼び出し順序がSenderやGreeterの状態に依存しないなら、それでいいと思うけど、
やり取りするデータによって流れが変わる場合、テストできないんじゃない?

そこまでシミュレートするXXRecorderをテスト用に作るんじゃ、それこそテストのため
のテストのような気がするし。

>これは、自分が組み込み系のせいで、リリースコードにテストコードを入れてお
>きたくないという想いが強いせいかもしれません。

俺ならそうゆー場合条件付コンパイルの方法を探すけど(ツール使うなりその他
もろもろの方法で)。けど、まずはRecoder機能をなるべく軽く実装するように努力するかな。



636 :デフォルトの名無しさん:02/06/01 12:16
結婚は人生のペアプロです。(w

637 :デフォルトの名無しさん:02/06/01 12:20
>>625
品質 = 1 - (クレーム数) / (稼働時間)

638 :XP信者:02/06/01 12:49
>呼び出し順序がSenderやGreeterの状態に依存しないなら、それでいいと思うけど、
>やり取りするデータによって流れが変わる場合、テストできないんじゃない?

そうかも。
で、呼び出される側のオブジェクトの状態によって、呼び出し順序が変わらないように
するのがテストしやすい構造なのではないかと。

そして、テストしやすい構造を目指すと、自然に良い構造になる効果があるのでは
ないかと期待しているのです。

>そこまでシミュレートするXXRecorderをテスト用に作るんじゃ、それこそテストのため
>のテストのような気がするし。

そこまでして、その部分のテストを重要視していることが示せていいんじゃないかなと。
屁理屈かもしれないけど。

実際に作ってみると、マルチスレッドが絡まなければ、それほど複雑なスタブは必要
ありませんし。

>俺ならそうゆー場合条件付コンパイルの方法を探すけど(ツール使うなりその他
>もろもろの方法で)。けど、まずはRecoder機能をなるべく軽く実装するように努力するかな。

条件付コンパイルは、その中に副作用を紛れ込ませたときに恐いので、テスト環境では
使用したくないな。
デバッグコードの分離には使うけど。


639 :XP信者:02/06/01 12:54
>>634
>パフォーマンスに影響なければテストがしやすいように
>テストのみにしか必要のない機能を追加することに躊躇すべきではないとも言える。

パフォーマンスの関係も、もちろんあるんだけど、例えば、テストのためだけに、
隠蔽されている内部構造を取得できるGetterを付けてもいいかとか、そんな感じ。



640 :デフォルトの名無しさん:02/06/01 14:04
>>639

>で、呼び出される側のオブジェクトの状態によって、呼び出し順序が変わらないように
>するのがテストしやすい構造なのではないかと。

でも、それって(そういう構造に)実装するという実装の問題ではなくて、
実現する(要求される)機能によって決まっちゃうと思うけど。。。

大昔の本「Microsoft Code Complete」にもあったけど、Excelの再計算
処理を実現するとき、全体を計算しなおすと確実だけど効率が悪い。
部分的な計算だけで済ませば速いけど、バグが生じやすい。だから
Microsoftの技術者は常に両者の結果が一致するかのチェックルーチン
を組み込んで部分的な計算ルーチンのデバッグをした。といった話
が書かれている。

俺もそれをイメージしていまレスを書いてるんだけど。俺も似たようなことはする。
パフォーマンスをチューニングする時に馬鹿正直に書いた処理といろいろ小技を
使った処理を同時に動かして、プログラム自身でチェックさせる。

>そこまでして、その部分のテストを重要視していることが示せていいんじゃないかなと。
>屁理屈かもしれないけど。

というとXXとXXRecorderの状態遷移が見かけ上一致するか否かのテストもするって
こと?まあ、そこまでするのであればそれはそれで一理ある。でもこれはテストのための
テストだよね。

>条件付コンパイルは、その中に副作用を紛れ込ませたときに恐いので、テスト環境では
>使用したくないな。

副作用があるかないかをテストすべきでと思うけど。それがテストのためのテスト
ってことでいやなのかな。ま、それはそれで共感する部分もある。俺も条件付コン
パイルはあまり多用したくない。

けどどの方法を使うにしろ上に書いたようにテストのためのテストは避けられないと
思うけど。

>パフォーマンスの関係も、もちろんあるんだけど、例えば、テストのためだけに、
>隠蔽されている内部構造を取得できるGetterを付けてもいいかとか、そんな感じ。

というわけで俺はGetterをつけるべきと思う。例えば電気回路にもテスト用のピン
が出てるよね。

641 :デフォルトの名無しさん:02/06/01 14:16
つづき

カプセル化が崩れるのは、いかんともしがたいと思うけど。コードの上でそれが
チェック/デバッグのために用意されたメソッドだってことは、コメントで伝えるか、
あるいは条件付コンパイルの記述とかで伝えるしかないんじゃないかな。

大筋テストしやすい構造にできる場合はそういう構造にするってのは賛成。
「よい設計」と「テストしやすい設計」はほとんど同義。


642 :デフォルトの名無しさん:02/06/01 14:19
>>640
>例えば電気回路にもテスト用のピンが出てるよね。

なかなかうまい例えだと思う。
そこから一歩踏み込んで、テストコードを実環境での動作チェック機能としてリリ
ースコード化してしまうという手もありでは?
ストーリーカードに載せられるかどうかが微妙ではあるけど。

643 :デフォルトの名無しさん:02/06/01 15:11
>>636
XPなのにデスマーチになりましたが、何か?

644 :デフォルトの名無しさん:02/06/01 15:13
>>643
どういう経緯ですか?

645 :デフォルトの名無しさん:02/06/01 15:17
>>644
リンク先を見てネタだと気付こう(w

646 :デフォルトの名無しさん:02/06/01 15:53
XPなのにデスマーチが回避できないの?
ウニットテストとイテレーションが足りないのでは?


647 :デフォルトの名無しさん:02/06/01 19:52
XPでペアとけんかしたときも、やっぱりセックスすれば仲直りできますか?

648 :デフォルトの名無しさん:02/06/01 22:09
>>647
激しくないと効き目が無いので早急にイテレーションしてください。


649 :デフォルトの名無しさん:02/06/02 10:27
>>647
まめにペアを入れ替えるようにしていろいろと共有するよう心がけましょう。

650 :デフォルトの名無しさん:02/06/02 10:41
人生にユニットテストかけたら、絶望しました。どうしたらいいですか?

651 :デフォルトの名無しさん:02/06/02 11:17
時には全てを破棄して最初からやり直す勇気も必要です。

652 :デフォルトの名無しさん:02/06/02 13:12
>>649
まじで聞きたいんだけど、ペア同士喧嘩にならないのかな?
XPの(数少ない)レポートでも、なんかこの辺は特にきれいごとでまとめられてる
気がするんだけど。

生なましペアプロの実体レポートってないの?

・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
 インデントを書き直す。
・1日中議論だけで終わってしまった。
・1週間口も聞かなかった。
・もう2度とキミとは組みたくないといわれて落ち込んだ。
・相手は一歩も譲らず、自分はまるで相手の部下のようにはいはい従うしかない。

とか。

653 :デフォルトの名無しさん:02/06/02 13:15
>>652
>・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
> インデントを書き直す。
これはpractice説明でもいましめられてるね。だからコーディング規約を
あらかじめ統一しておくこと、と。

654 :デフォルトの名無しさん:02/06/02 14:19
>>653
うーん、やっぱつっこみが入ったか。
規約を決めても、そのちょっと外側辺りでそれぞれのポリシーの相違がある
じゃん。言いたかったのはそういうこと。


655 :デフォルトの名無しさん:02/06/02 14:23
ついでに追加

・あいつはいつも派手で面白そうなところを作りたがる。だけどバグだらけで
 尻拭いはいつも俺の方。
・xxとペアを組むといつもどうでもいい箇所にこだわるから効率が悪くてしょがない。

656 :デフォルトの名無しさん:02/06/02 15:08
>652
> ・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
>  インデントを書き直す。

コーディング標準の導入は当然。
インデントは、フォーマッタで機械的に整形するのが吉。
文句のつけようがない。


> ・1日中議論だけで終わってしまった。

ペアプロ中はなかった。
おそらく、”実現方法がわからないから議論する”という状況ではなく、
ポリシーの相違が問題になっている状況であると思うが、
そんな時は他のメンバーに判断を仰ぐね。
それがシンプルかどうかを基準に、客観的に判断してくれる。


> ・1週間口も聞かなかった。
> ・もう2度とキミとは組みたくないといわれて落ち込んだ。
> ・相手は一歩も譲らず、自分はまるで相手の部下のようにはいはい従うしかない。

その辺は大人だからね、普通は何とか折り合いをつけるんじゃないかなぁ。

でもまあ、どうしても合わなかったり、XPを理解しなかったりの問題児さんはサッサと辞めてもらえ
ってケント・ベックもXP本のっどこかでで言っていたような覚えがあるなあ。


657 :デフォルトの名無しさん:02/06/02 15:34
あのぅ〜個人でプログラムやってますが、XPの導入は可能ですか?

658 :デフォルトの名無しさん:02/06/02 15:36
部分的にならひとりでも。

659 :デフォルトの名無しさん:02/06/02 16:14
ペアになった相手を説得するのも、技術(コミュニケーション)の1つでしょ。
ちゃんと理由を説明すれば、納得してもらえるかと。
それでもダメなら辞めれ。


660 :デフォルトの名無しさん:02/06/02 16:29
>>659
ここ数日でいきなりこのスレ盛り上がってるようだけど、一体何が起きたんだよ〜!!!!!といって見るテスト

661 :XP信者:02/06/02 20:37
>>657

信じさえすれば。

いや、マジな話、XPはXPの思想に共感するかどうかで大違いだし、
便利なツールとしては使用できないと思うよ。

ただし、プラクティス自体は、XPの思想とは関係なくツールとして
使用できるから、UnitTestをやってみれ。

662 :デフォルトの名無しさん:02/06/02 22:01
>でもまあ、どうしても合わなかったり、XPを理解しなかったりの問題児さんはサッサと辞めてもらえ

相手がやめるか自分がやめるか大きな問題がある気がするが。
それともチキンレース方式で先に根をあげた方が敗者?

663 :デフォルトの名無しさん:02/06/02 22:05
>>657

そして(XPをやるものが)誰もいなくなった

664 :デフォルトの名無しさん:02/06/02 22:06
>>659の間違い

665 :デフォルトの名無しさん:02/06/02 22:12
>662
最終的にはマネージャが邪魔だと判断した方を排除するだろ。
そこに到達するまでの過程は知らんがね。

少人数のチームで毎日顔を突き合わせるんだから、判断できないことはないでしょ。

666 :XP狂信者:02/06/02 22:34
>>655
ペアプロ強制するのは、まだ時期尚早じゃないかな?

ただ、教科書的には、
「ペアプロの原則は、頼まれたら断らない。」
だから、これを断ったり、協力姿勢が見られないなら排除でしょう。

その上で人間関係がマズイペアの場合は、
要請しないという形でクッションおいていると思われます。

多少ソロ開発の余地もあっていいんじゃないかな。
馴染むまではさ。

ついでに新入りの場合は、当然左も右もわからない状態から
スタートだから、自然にペアプロだわなぁ。



667 :デフォルトの名無しさん:02/06/02 22:52
>>666
ペアプロを外すと情報の共有に激しく支障が出ると思うが。
XPはただ単にみんなが好き勝手やってるだけになるんじゃないの?

668 :デフォルトの名無しさん:02/06/02 22:54
例えばxxの部分の追加や変更はyyさんじゃないとだめだから。。。って話に
すぐなると思うがどうよ?

669 :XP狂信者:02/06/02 23:00
そこはそれ、
XPコア信者がやはり、ペアプロを要請して、
改宗させていくしか方法はないと思われ。
「ペアプロを断るな。」
最低原則はあるわけだから、後は運用でしょう?
ペアプロ実施率見てコーチは、対策採らないとならないんじゃないかな?
いずれにせよ、強制するのはスジが多少違うと思う。



670 :デフォルトの名無しさん:02/06/02 23:29
>>669

>いずれにせよ、強制するのはスジが多少違うと思う。

うーん。それは納得いかん。「ペアプロをしないならXPではない」のでは。

情報が共有されているからこそドキュメントとかにかかるコストを減らしても
よいわけで、ある部分の「担当者」が病気になったら何も進まないって
事態になるんじゃないの。

表面的な効率だけ考えれば特定の部分は特定の人が常に担当していた
方が効率がいいわけだから、歯止めがなくなれば、情報の独占の方向に
チームのチューニングが進んでしまうと思うけど。



671 :XP狂信者:02/06/03 00:22
うーん、ところで、
そのソロ開発者。自分ひとりでタスク処理できるのかなぁ?
必ずしも、効率優先じゃないのがXPだしさぁ。
自分以外の部分もドキュメントレスなんだよ??

XP実践編では、受け入れテストができてなかった。
論文集では、計画ゲームが機能してないが、XP成功例というべき
プロジェクトの例が載っていた。
メタファが機能しているXPプロジェクトは多くないらしい。
オンサイトユーザ実施に頭痛めているのも多い。

そういうわけで理想的XPプロジェクトってそんなに多くはないのでは?
やれることからやってこうよ。

ペアプロしないと、XPスタイルだと開発効率は下がるのは確かなんだから、
ソロ開発でやってると、ほかの連中よりタスクポイントのあがり
少なくなるでしょ?
そこらへんが、XPプラクティスの組み方の秘密なんだと思う。




672 :デフォルトの名無しさん:02/06/03 01:13
>必ずしも、効率優先じゃないのがXPだしさぁ。

うん。効率優先の弊害に歯止めをかけるためにいくつかのプラクティスが
用意されていると思う。ペアプロもその一つと思う。

俺の感覚では、確かに実際に2人が顔つき合わせてプログラムするのが
必要とはいわない。けど、コードや情報の独占を防止するための方法が
かなり気になる。ペアプロしないなら、ある部分を常に同じ人が担当するこ
とがないようにいっそう神経を使うひつようがあるんじゃないかな。

開発をやってればよくこういう場面に出くわすよね。xxの部分はyyyさんで
ないと直せません。けどyyyさんは今zzの部分をやっているのでそれが終
わるまでxxの部分は変更できません。xxの部分はyyyさんがうんといわ
ない限り変更できませんが、うんといってくれないので、私の作業ができま
せん。

こういった事態を防止する立場の人間がXPだといないか、極めて希薄なの
だから、こういった事態にならないようにかなり神経を使う必要があると
思うけど、どう?

>やれることからやってこうよ。

ま、それを否定するつもりはないけどね。

673 :デフォルトの名無しさん:02/06/03 02:07
おれはペアプロじゃないと不安でしかたがないです。
一人でコード書くのが怖いです。依存ぎみかも。

おれはペアプロは情報共有の効果よりも、実装が素敵になる効果のほうが
大きいとおもっているんだけど、どうだろう?理想的なプログラムなら
読めば何をやっているかは自明のはずだし。

あとペアプロとコード共有がごっちゃになってるような?

674 :デフォルトの名無しさん:02/06/03 02:32
>あとペアプロとコード共有がごっちゃになってるような?

そうだよ。だめ?

675 :674:02/06/03 02:41
これだけだとあんまりだから、補足するけど

「コード共有」を具体的にどう推進&維持してる?

676 :673:02/06/03 11:08
もともとコードの所有権という概念がなく、誰がコードを修正してもよいという
やり方だったのであまり困ることはなかった。

CVSの類を使う、頻繁に変更を反映する、
変えられたくはない場所はコメントではなくテストを書く、
などですんでいる。
ひょっとしたら、幸せなことなのか?

677 :デフォルトの名無しさん:02/06/03 12:32
>もともとコードの所有権という概念がなく、誰がコードを修正してもよいという
>やり方だったのであまり困ることはなかった。

長くやってるとだんだん「担当者」が偏ってこない?

メンバーのレベルのばらつきはどんなかんじ?みんな同じレベルなのかな。
レベルの高いメンバーがいると複雑な箇所はいつもその人が担当する傾向が
徐々に出てこない?


678 :デフォルトの名無しさん:02/06/04 00:13
大統領とかの再選禁止みたいに、1回担当したら必ず次は別の人が担当しなきゃならない、
とかするといいかも。

679 :デフォルトの名無しさん:02/06/04 00:31
そんなんじゃマジで布石を打てねえな。ホントにその場その場のタスクを
わき目も振らずにコーディングするだけ。それがXPの姿なんだろうけど、
そんなのやってて楽しい?

680 :デフォルトの名無しさん:02/06/04 00:49
>>679
XPは悩みすぎるなって言ってるんだよ
あれはある程度のスキル保有者のチームじゃないと成り立たない
初心者だらけのXP大会ポロリばっかだョ

681 :XP狂信者:02/06/04 00:51
というか、そこの偏りがあるから、ペアプロ要請を行えると考えるべし。
「そこのところは、xxさんと一緒でなければ。」
こうやって、持ち上げて、ペアプロに巻き込むのがテクニック。

これが教科書的な答えだなぁ。




682 :デフォルトの名無しさん:02/06/04 01:01
自分の会社を見渡して、XPでうまくいきそうなやつってどれくらいいる?
俺の独断

上位から
1割のうち半分ははやり方さえ教えれば、結構うまくいきそう。半分は絶対XPに向かない人間。
2割はXPをやらせると、そこそこやると思うが、せっかくの主戦力が逆に低下して、会社が維持できなくなる気がする。
4割のうち半分はXPで能率アップ。半分はダウン。どっちかというとダウンが多そう。
2割はもともとだめだからXPでもやって遊んでていいよ。
1割はXPの真似事も無理。勝手に暇つぶして。けどXPで大化けする人も中にはいるかもしれない。



683 :デフォルトの名無しさん:02/06/04 01:07
>>681
XPはペアプロの狙いがいまいち整理できてない気がする。
 情報の共有
 教育
 コードの品質アップ
これらがないまぜになってる気がする。俺のXPに対する理解が浅いからかもしれないが。

684 :673:02/06/04 01:18
>>677
実際には全員がすべてのコードを把握しているわけにもいかないので
担当者みたいなものは出てきます。そのほうが効率いいだろうし。
ただしそのことに対して「所有権」みたいなものを主張することは、
なんというか、文化として許されていません。特に制度的なものはないっす。

ただ人のコードを勝手にレビュー、リファクタリング、テストを行う人が
それなりにいるので、所有化の歯止めになっているのかも。

スキルはそれなりにバラけているだろうけど、あんまりな馬鹿は
チームにいれないようにしている。


685 :XP狂信者:02/06/04 01:22
もうひとつは、パワーの落ちた経験豊富な古株の再利用効果。
体力的に落ちてきているので量は無理なんだが、
若手とかませることで、作業量を増やせる。

まぁ、SEとPGがべったりでコーディングしていると見れば
ペアプロってのは、あながちひどいもんでもない。
(異常な形態に見えるけど。)

ついでに、ソーシャルな部分の教育効果もあるので、
自然に、対人関係的、管理的職務に対する準備効果もある。
限界まで自分の能力を使い切る必要もないし、
Helpを通じて、別のスキルを磨くこともできる。

ペアプロに隠された意味は結構深いものがあるよ。



686 :デフォルトの名無しさん:02/06/04 01:31
>>684
>実際には全員がすべてのコードを把握しているわけにもいかないので

全員が把握している必要はないと思うけど、複数の人が把握している必要は
あるよね。

>担当者みたいなものは出てきます。そのほうが効率いいだろうし。

短期的な効率だけ考えれば、共同所有やペアプロとか多くは否定されると思う。
短期的な効率にとらわれず、長期的な効率のためにこれらがあると思う。

で、俺が言いたいのは特にルールとかなくても、短期的な効率に惑わされずに
長期的な効率を見据えられるものなのか?ってこと。(できないだろうといってる
んじゃなくて、質問なので誤解ないように。)

>ただしそのことに対して「所有権」みたいなものを主張することは、
>なんというか、文化として許されていません。特に制度的なものはないっす。

すばらしい。そういう考えのメンバーだけ集めたわけじゃなくて自然に
みんながそういう方向に考える土壌が生まれたの?それならうらやましい。

>ただ人のコードを勝手にレビュー、リファクタリング、テストを行う人が
>それなりにいるので、所有化の歯止めになっているのかも。

それは確かにあるかもしれないね。

>スキルはそれなりにバラけているだろうけど、あんまりな馬鹿は
>チームにいれないようにしている。

逆は?あんまり優秀だけどチームには入れられないと思う人間は
いるよね?それはやっぱ入れない?


687 :デフォルトの名無しさん:02/06/04 01:36
>>685

>まぁ、SEとPGがべったりでコーディングしていると見れば
>ペアプロってのは、あながちひどいもんでもない。

うーむ。なかなか考えさせられるね。

688 :デフォルトの名無しさん:02/06/04 02:50
>>686
短期間でも、ペアプロ、共同所有は効果的だと信じている(信者的発言)

経験上、共同所有じゃない状態に利益があったとは思えない。
ペアプロは設計の止揚(大げさか?)と簡潔なコードによって、
短期的にも効果がある、はず。

プログラムの質 = 人間の質と考えているように見えるため、
社内から評価の良くない人もチームにいるけど、
チームでは少々性格の悪い人程度に思われているような。

ルールを守って、コードが書ければ人格的なことは
あまり気にしないようにしているけど、どうなんだろう。


689 :デフォルトの名無しさん:02/06/04 03:11
>>688
>短期間でも、ペアプロ、共同所有は効果的だと信じている(信者的発言)

そういうことを聞いてるんじゃないんだけど。
元の発言全体を読めばわかるだろ?

>経験上、共同所有じゃない状態に利益があったとは思えない。
>ペアプロは設計の止揚(大げさか?)と簡潔なコードによって、
>短期的にも効果がある、はず。

同上。教科書どおりの発言にはあまりお付き合いするつもりはない。

>プログラムの質 = 人間の質と考えているように見えるため、
>社内から評価の良くない人もチームにいるけど、
>チームでは少々性格の悪い人程度に思われているような。
>
>ルールを守って、コードが書ければ人格的なことは
>あまり気にしないようにしているけど、どうなんだろう。

だから、ルールを守らないでコードを書く人の話をしてるんだけど。
そしてそのルールには共同所有を妨げる行為を陰に陽に禁止する
ものがなくても大丈夫なのかということ。
それ以外の人格なんて気にしだしたら果てしないから。


690 :デフォルトの名無しさん:02/06/04 03:38
つづき

ほとんどの場合優秀な人間ほど紳士的に振舞うだろう。相手の考えを
尊重し、多少の価値観の相違は相手の判断を優先する。

問題なのは、そういう人間が、あえてこだわる箇所。めったにないことだが、
逆に言えば頻度は少ないものの、必ずある。そして紳士的なもの同士が
あえて妥協できない箇所なのだから、それは並大抵のことじゃ譲れない
部分なわけ。

その時他にこれといって明確な理由がなければ、「担当者」の意見が通るの
が最もありそうなことと思う。で、聞きたい。こうした場合「担当者」の意見を
尊重するのが妥当か否か。(優劣を決める他の条件はまったく同等とする。)

それともむしろ担当者ではない意見を取り入れるべきか。あるいは純粋に
さいころでも振って平等にするか?

担当者の意見を尊重する
 これまでやってきたのだからいろいろ経験もあり、この先いろいろ考えている
 こともあるだろう。という判断。非常にもっともな話だ。けどこれを認めれば、
 今後さらに人とプログラムのその部分の結びつきが固定され、だんだんと
 ほかの人にとってプログラムのその部分に意見をさしはさめないような雰囲気
 になっていくのではないか?

あえて担当者でない意見を尊重する
 新しい考えが入って、ブレイクスルーがおきるかもしれない。しかし前「担当者」
 は不満かもしれない。また感情的なものを抜きにしても、「担当者」が暖めてい
 た腹案は日の目を見なくなる。また、こういったことが普通なら、あまり先のこと
 を考えるのは損ということになる。XPの趣旨にも沿っているのかもしれない。
 そして共同所有の精神にもそっているかもしれない。

さいころで決める
 案外これが一番平和?


691 :XP狂信者:02/06/04 07:00
そこまでいくと、ほとんどYAGNIだなぁ。
あんまり考えすぎないこと。

ペアで意見が対立するようなら、
その設計、アイデアはたいしたことはない。

全員で設計レビューの会議を行うこと。
もし、問題がはっきりしていて、解決策として適当なら支持が得られるだろう。



692 :デフォルトの名無しさん:02/06/04 12:40
>ペアで意見が対立するようなら、
>その設計、アイデアはたいしたことはない。

それはちょっと短絡的過ぎると思う。つーかそう考えたいだけでは。

おれは案外さいころがいいんじゃないかと思ったりしてる。表面的には
何か理由をこじつけると思うけどね。

「常に担当者の意見を尊重する」も「常に担当者でない意見を尊重する」も、
予測がつくと結局人間って無意識にそれを避けるようになるから。ランダムな
要素を入れて適度にかき回したいという思いがある。

リーダーならそれをリーダーが判断すればいいけど、XPの場合リーダー
的立場の人があまりイニシアチブをとらないほうがむしろいいんだよね。
場合によりけりだと思うけど。それともこういう場合はやった方がいいのかな。

693 :XP狂信者:02/06/04 19:59
チームの誰もが賛成しないコードを作るということなら、
当然排除の対象だなぁ。
ペアで賛成しないならというのはそういう意味。
プロペラ帽をかぶるしかない。

まぁ、なんかの機会にリファクタリングされちゃって、
跡形もなくなるんじゃないかな?



694 :デフォルトの名無しさん:02/06/04 21:04
>チームの誰もが賛成しないコードを作るということなら、
>当然排除の対象だなぁ。

しつこくて悪いけど「誰もが賛成しない」ほどじゃないときの話。

なんつーかこういうどっちでもいいようにみえる、1つ1つは取るに足らない
ような微妙な時の判断の積み重ねが、雰囲気というか文化というか、そいうい
ものを作っていくと思うんだ。

#君の意見に難癖つけてるわけじゃないよ。レスありがとね。

695 :XP信者:02/06/04 22:16
>なんつーかこういうどっちでもいいようにみえる、1つ1つは取るに足らない
>ような微妙な時の判断の積み重ねが、雰囲気というか文化というか、そいうい
>ものを作っていくと思うんだ。

自分で答えているように、どっちかとかどう決める、とか決めないで、
そのチームの雰囲気とか文化に従って判断するしかないんじゃない?

サイコロで決めるって文化ならそれもそれでいいけど、別に優れているって
わけでもない。

うちなら、アミダクジだな。

696 :デフォルトの名無しさん:02/06/04 22:42
じゃんけんでいいじゃん

697 :デフォルトの名無しさん:02/06/04 22:53
>サイコロで決めるって文化ならそれもそれでいいけど、別に優れているって
>わけでもない。

さいころが文化なんじゃなくて、前担当者が同じモジュールを次も担当するか
否かの比率が1でも0でもなくて1/2ぐらい、ってなスタイルがXPにあってるんじゃ
ないのか、という話。

1だと共同所有が圧迫される気がする。0だとコードに対する愛着がなさ過ぎ。

698 :XP狂信者:02/06/05 00:28
だから、教科書的な答えで申し訳ないんだけど、
次も担当するかってのは0でもかまわないのがXP。
ただし、ヘルプ要請を受け入れて、結局は半分くらいを担当するのが基本。

タスクは個人で受け入れる。
実際には、助けあって開発する。
これでペアプロを推進していこうというのが、
教科書の記述だね。


699 :デフォルトの名無しさん:02/06/05 00:30
愛着と所有は似たようなものなので、XP的には否定されるのかも。

共同所有を徹底していると、自分の愛着のあるコードがどんどん変更、
しかもより良い方向に変わっていくので、愛着をもっていた自分が
馬鹿みたいに思えてくる。だからあまりこだわらないことにしています。

うちでは居合わせたメンバーに対して簡単なコンペ、で多数決。
同数の場合リーダーが投票したほうを選ぶことになっています。

700 :デフォルトの名無しさん:02/06/05 01:00
>だから、教科書的な答えで申し訳ないんだけど、

後から読み直したらやっぱ俺の>>689はいろいろ表現がよくないね。スマソ。

701 :デフォルトの名無しさん:02/06/05 01:11
>うちでは居合わせたメンバーに対して簡単なコンペ、で多数決。

多数決の結果、いつも同じ人が同じモジュールを直す事になったとする。

これは
 「まったく問題ない。XPの主旨にも反していない。」?
それとも
 「能動的にローテーションさせる方が共同所有が浸透してよい」?
あるいは
 「XPを正しく実践していれば、そもそも同じ人が同じモジュール長く
 担当することなどは起こらない。起こるとすれば何かおかしい」?


702 :XP狂信者:02/06/05 02:53
>>701
タスクとクラスとモジュールの関係が不明かも。
タスクわけのとき、必ずしもクラス単位、モジュール単位の作業に分解しないのだけど?
だから、タスクの処理を行う時点で、複数のクラスに手を入れる。
言語は何??



703 :デフォルトの名無しさん:02/06/05 02:57
ある人の設計が常に取り入れられるのは問題ないと思います。
コンペの結果であり、どうせペアで実装なのですから。

あと、ローテーションもします。
XPの経典にもそうあったはずだし、
第一、ずっと同じ場所をやっていると退屈します。
個人的にはこちらのほうが重要です。退屈は効率の最大の敵かと。

でも緩やかな担当者みたいなものは存在しています。
そっちのほうが効率的という認識です。

704 :デフォルトの名無しさん:02/06/05 14:41
>XPの経典にもそうあったはずだし、
>第一、ずっと同じ場所をやっていると退屈します。
>個人的にはこちらのほうが重要です。退屈は効率の最大の敵かと。

生半可なことでは退屈しないような奥の深い分野(?)はXPに向かない?
と言ってみるテスト。

705 :デフォルトの名無しさん:02/06/05 16:16
>>704
奥の深い分野なればこそ、リファクタリングとテスティングは絶対必要と
逝ってみるテスト。

706 :デフォルトの名無しさん:02/06/05 16:28
>>704

ん〜・・・例えばこういう分野ね。。。(w

ObjectARX
http://usa.autodesk.com/adsk/index/0,,773204-123112,00.html

でもやり方しだいで何とかなりそな気もなくもない(W



707 :デフォルトの名無しさん:02/06/05 21:29
>>706

なにゆえそのリンク先が突然でてくるの?説明きぼん。

708 :デフォルトの名無しさん:02/06/06 08:42
>>707
多分下の掲示板から飛んできたものと思われる。。。

http://www.acesekkei.com/forum/wforum.cgi

AutoCAD 関連は両極端だからのう・・・いまだに LISP でしか PG 組めんのと、フレームワーク使ってごりごり組めるのがいたりする。
でも AutoCAD の公開されているフレームワークやAPIは難解すぎて、使いこなすだけで一生終える可能性も無きにしも非ず(獏
そうなってくると専門的になりすぎて >>704 みたいな話も当然出てくるわけだ。。。

709 :デフォルトの名無しさん:02/06/06 12:12
>>708
Visual C++ 使ってても、未だに LISP 的発想しかできないのが多いのが AutoCAD 関連プログラマの特徴です。
でもここで LISP と言ってもどんな言語か皆知らんだろ (w

710 :デフォルトの名無しさん:02/06/06 13:19
>>708
>多分下の掲示板から飛んできたものと思われる。。。

さんくす。

>そうなってくると専門的になりすぎて >>704 みたいな話も当然出てくるわけだ。。。

うーん、つーと専門的になりすぎた分野に対してはXPは向かないというのは
否定しないということ?

>>705
>奥の深い分野なればこそ、リファクタリングとテスティングは絶対必要と
>逝ってみるテスト。

奥が深い分野でもそうでない分野でもリファクタリングやテスティングが大事なのは
否定しないけど、ペアプロや共同所有が奥が深い分野でもうまく機能するんだろうか。。。
奥が深い分野をやってるやつはどっちかっつーと一人でこつこつ型だから、なんとなく
そのままじゃXPに向かない気がする。

だけど、その部分を外から呼び出して使う部分はXPでやりたいって場合、可能なのかなぁ。
その部分だけ市販のソフトを利用しているのと同じ扱いすればいいのかな。


711 :デフォルトの名無しさん:02/06/06 14:02
>>710
> うーん、つーと専門的になりすぎた分野に対してはXPは向かないというのは
> 否定しないということ?

漏れは知っている、ついこないだまでJAVAラーだったPGが、

> ObjectARX
http://usa.autodesk.com/adsk/index/0,,773204-123112,00.html

に挑戦していたのを!!
元々↑は専門外でトーシロだったが、やりゃできるもんだとつくづく感心したっけ。

712 :デフォルトの名無しさん:02/06/06 14:10
>>711
ということで、奥が深い分野でもペアプロ可能という事でケテーイ!!(w

713 :デフォルトの名無しさん:02/06/06 16:17
ObjectARXがどういう深さなのかわからんから、さっぱり話が見えない。悲しい。

714 :デフォルトの名無しさん:02/06/06 16:56
>>713
フレームワークとしては実はそんなに難しくない。
ただし何が話をややこしくさせているかというと、
リファレンスやデベロッパガイドが日本語版がない上、
技術者が少ないので初心者の学習が困難
という事が挙げられる。

715 :デフォルトの名無しさん:02/06/06 17:45
>>714
なるほど。そういう深さならペアプロした方が技術が伝授されていいよね。
それに覚えることが多い類の「難しさ」の場合は、一人でやってるとやになっちゃう。


716 :narucy56 ◆wMOjCT4s :02/06/06 19:50
XP って、やっぱ名前よくなかったと思う。
もう少し大人っぽい名前つけたら、現場に説得しやすかったのにと思う人も多いんじゃないか。

717 :デフォルトの名無しさん:02/06/06 19:59
>>652
>・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
> インデントを書き直す。

Pair Programming で争いがおこりそうなポイントとしては、
例えばポリモーフィズムで処理を分岐させたいようなところで、

「ここはクラス作るぽうがイイって!」
「if 〜 else で十分だ」

というような。

これは、オブジェクト指向を全く知らない人と、知ってる人とで争いがでるかもしれないし、
はたまた、オブジェクト指向の勉強したい人と、オブジェクト指向を知っているが if 〜
else で事足りると言う人との争いかもしれない。

一番シンプルな作り方ってのは、話をすればたいていまとまるもんだとは思うけど
人によってシンプルさが異なるポイントは、ここらへんになるんじゃないか。

オブジェクト指向といってもシンプルな技術なんだから、俺はこういうケースの場合
OOPで作るという道を優先したほうがいいんじゃないかと思う。

718 :デフォルトの名無しさん:02/06/06 22:48
それってオブジェクトをどこまで分解するかって話になるよね。

全体のシンプルさとは、ひとつひとつのオブジェクトがシンプル(小さい)であることか、
オブジェクト相互の関係がシンプル(少ない)であることか、ってことにいきつく。

もちろんどちらでもないからこそ悩むし、技術力の差になるとおもう。

シンプルな方を選択すればいい、ってのは
正しいことをするのが正しい、ってのと同じ気がする。


719 :デフォルトの名無しさん:02/06/07 00:02
従来の開発手法ではそういった議論を通じての相互のスキルアップなど
到底望めない状況であったわけだ。




・・・無理に持ち上げて誉め殺してやれと思ったら、それなりに筋が通ってしまった。


720 :デフォルトの名無しさん:02/06/07 01:45
だからあ、それをあれこれ考える考えかをまとめて教科書にしてあるのが「方法論」なわけだろ。
XPは自己流で個人個人が再発見しろと突き放してるわけだよ。

教科書にとらわれず生きた教育を、ってか?
そりゃ小学校ならいいかもしれないけど、高校、大学もその調子でいくのかい。


721 :デフォルトの名無しさん:02/06/07 02:19
もう一つメタな視点を持ってくれ。

ソフトウェア開発の 「開発」 だけに視点をおいていたのが従来のプロセスだ。
成果物がすべてであり、開発者が人間だろうと人工知能だろうと考慮されない。
これらのプロセスが述べるのは 「ソフトウェアはどう開発されるべきか」 だ。

XP ではソフトウェアは実は人が作っているのだと発見してくれた。
XP が述べるのは 「開発者はどう開発に取り組むべきか」 だ。

重なる部分も多いが、カバーしている範囲が違う。
排他的ではなく、相補的に利用しよう。

どうせ、すでにある方法論を寸分たがわず実行するなんて XP も含めて無理なのだから。
自分たちの方法論を構築するための土台や糧と考えたい。

722 :デフォルトの名無しさん:02/06/07 02:36
>排他的ではなく、相補的に利用しよう。

従来の方法論を否定しているのはいつもXP側のような気がするが。
ってことはXPの信者はメタな視点をもってないのが多いってことだね。


723 :デフォルトの名無しさん:02/06/07 02:39
XP 信者の話をしてもしょうがないよ。

724 :デフォルトの名無しさん:02/06/07 02:51
その通りやってみようなんてのは、
技術的ノウハウの蓄積がない、真っ白な人間だけ。
経験を積んだ人間は、良さそうなところだけつまんで、
自分のスタイルに取り込んで消化する。

725 :デフォルトの名無しさん:02/06/07 02:57
例えば自然科学は「書物」がなければきっとここまで発展しなかっただろう。
一子相伝じゃないけど人から人への口伝じゃ無理。

文字を持たない文明があればきっとその発展の限界は人間の寿命としゃべる
速さで決まるんじゃないかな。

同じ理由でXPは発展しないんじゃないかな。毎回再発明を強制し、個人の
記憶の中にしか蓄積がない。

メタの話をするなら、XPはXPのプラクティス自身の追加や変更、改良の方法
とかも取り扱うべきだよ。例えばローカルプラクティスの設定とか、ローカル
プラクティスを持ち寄ってスタンダードなものに昇格させるとか。

これならきっと積み上がっていくものもあるだろう。そうでなければ再発見の
繰り返し。


726 :XP狂信者:02/06/07 06:26
>>725
まぁ、それはそうと、じゃあ大量のドキュメントに、
その真実が書かれているとでも?

実際歴史的な経緯をきちんと踏まえていくと、
ここ30年のソフトウェアムーブメントはほとんどSmalltalkの世界から
来ている。
(Network,Window,OOP,Pattern,TestFirst...)
ドキュメントはソースだけだよ。
それでもきちんとソフトウェアが書けて、読める人間には十分なんだ。

よーするに、ソースで語れば十分。

XPが言っているのはそれだけ。
読みこなすことができるかどうか?
だから黙ってあるレベルのソースを読めと強制するのがXP。

君のは、答えが書いてある本を沢山大量に暗記してわかった気になっている
アスパラ君と同じ発想だよ。
却下する。(と煽ってみる)




727 :デフォルトの名無しさん:02/06/07 06:29
XPの直接的な原型は、多分オブジェクト・コミュニティに20年近く根付いていて、
それを明文化してみたのが XPなわけ。

んで、プラクティスのスタンダード化とかいうと、
OOPSLAとかがその役割を立派に果たして来た、と思う。

ところで、>>722 は意味不明っぽくていいですね。どの分野でも通用するレスだ。

728 :XP狂信者:02/06/07 06:53
ついでに、
方法論、方法論、方法論の価値ってのはなんじゃらほい?

っていうと、実は失われた全体知を以下に取り戻すか?
この言明が結局はポイントなんだよね。

かっての方法論は、アナリシスをきっちりすることで、
全体知を表すドキュメントを作れると言って来たわけだ。

で、それをデザインに持ち込もうとして(RUP)
確かに有効なんだけど、やってられんぞおらー。
というところがあったわけだ。

だから、RUPやるなら、全体知を表現している
重要なシナリオ、クラス図、ユースケース。
そういう本質的なものだけあれば良いというのが、
最近の僕。

XPでは全体知は、いつでも誰でも読めるソース(オープンソースと同じノリ)
とペアプロによる口伝により、
(能力があれば)全体に浸透させることができる。こう言っているわけよね。




729 :デフォルトの名無しさん:02/06/07 07:26
日本では、つーか非英語圏ではドキュメントを絶対に書かないというのは無理がある。
やっぱり大抵の言語は英語ベースだからね。詳細なドキュメントは書かない代わりに
ある程度は丁寧なコメント(クラスとかメソッドの先頭に処理の概要と目的程度)は
不可欠なんじゃないかな。どうせリファクタリングされるっていうならコメントも含めて
リファクタリングすればいい。紙のドキュメントを平行して修正する義務から解放される
だけでも全然違うと思う。

あとXPは開発に使用するツール(エディタとかCVSとか)のチュートリアルを作成して
配布するとか各個人がメモを取ることまでは禁止していないと思うんだけどどうだろう。

とりあえず日本ではストーリーカードを丁寧に作ることと、そのストーリーカードが各
イテレーション開始時に客の承認を得ているという証拠を残すこと(ああ日本的)と、
リリース毎に後付け設計書を(もちろんタスクとして起こした上で)作成することは
避けられないと思う。無駄なトラブル避けるためにも。


730 :XP狂信者:02/06/07 07:36
ついでにアスパラ君にアドバイスしとくと(苦笑)

全体知から離れた分析やってるから点数低くなるんや。

こういうことね。


731 :デフォルトの名無しさん:02/06/07 10:02
>>726
>
>ドキュメントはソースだけだよ。

ほら、やっぱXP信者は従来の方法論を拒絶する(w
どこが相補的なんだか。

方法論というとドキュメントの書き方だと馬鹿の一つ覚えのように
思い込んでるんじゃないの?

>君のは、答えが書いてある本を沢山大量に暗記してわかった気になっている

XP信者はXPの本を読み漁ってわかった気になってるだけじゃないの?

>>727
>ところで、>>722 は意味不明っぽくていいですね。どの分野でも通用するレスだ。

失礼なやつだな(w その部分は>>721

>もう一つメタな視点を持ってくれ。

>重なる部分も多いが、カバーしている範囲が違う。
>排他的ではなく、相補的に利用しよう。

に対応してて、逆の立場から同じ論法を使ってるの。>>722が意味不明な
言葉遊びなら>>721も同じだって皮肉なんだが、それが通じないようだな。

現にXPと従来の方法論は相補うものじゃなくて従来の方法論を否定している
じゃないか。どこが

>ところで、>>722 は意味不明っぽくていいですね。どの分野でも通用するレスだ。

なんだ?キミの発言こそ、内容がない無意味な発言だ。


732 :デフォルトの名無しさん:02/06/07 10:14
>>728

>っていうと、実は失われた全体知を以下に取り戻すか?
>この言明が結局はポイントなんだよね。

>かっての方法論は、アナリシスをきっちりすることで、
>全体知を表すドキュメントを作れると言って来たわけだ。

だれもそんなことを本気にしてはいない。「物理」でもなんでも
よくあるだろ?「空気抵抗は考えないこととする」とか非現実的にシンプルに
した状態を考える。

教科書は説明を簡単にするためにあえてそうしてんるわけで、
実際に応用するときは別途空気抵抗を計算するなり、計算できない
場合は実測値を用いるなり、するわけ。もちろんどういう場合はどう
実測値を放り込むかってノウハウもその範疇なわけだ。

キミの「方法論」に関する考えは、初心者向けの教科書を読んで、
物理学者なんて所詮非現実的なことばかり相手にしてるんだろう、
とか思い込んでるのと同じだよ。

ステレオタイプというか…頭が固いね(w

733 :デフォルトの名無しさん:02/06/07 10:29
>>728
>かっての方法論は、アナリシスをきっちりすることで、
>全体知を表すドキュメントを作れると言って来たわけだ。
>
>で、それをデザインに持ち込もうとして(RUP)
>確かに有効なんだけど、やってられんぞおらー。
>というところがあったわけだ。
>
>だから、RUPやるなら、全体知を表現している
>重要なシナリオ、クラス図、ユースケース。
>そういう本質的なものだけあれば良いというのが、
>最近の僕。

結局従来の方法論を批判するのにドキュメントうんぬんしか
批判できないの?ドキュメント信奉者なんだね(w

物理で使用する数式や計算を嫌悪するようなものじゃないの?
物理学の本質も数学の本質も、考え方を追究しているのだけど、
数式の羅列や延々と続く計算式を「やってられんぞー」とか
いってるんだよね。ピントがずれてない?

>XPでは全体知は、いつでも誰でも読めるソース(オープンソースと同じノリ)
>とペアプロによる口伝により、
>(能力があれば)全体に浸透させることができる。こう言っているわけよね。

物理で小難しい数式をこねくり回しても、現実の世界では誤差が
多くて結局使えない。だから最初から計算なんてしないでカットアンド
トライでやりましょうよ、とこう言ってるわけだよね。

カットアンドトライでいきましょうよといいつつ、具体的にどういうケース
ではどうするかってノウハウをどう蓄積するかは一切触れずにね。

これがXPだ。

実際には小難しい数式をひねくり回している人は、どこまでを計算で求めて、
どこの部分は実測で行うかまで考慮に入れてるんだけどね。


734 :デフォルトの名無しさん:02/06/07 10:41
>>731-733
もう少し冷静に、簡潔に頼む。

735 :デフォルトの名無しさん:02/06/07 10:51
んだから、XPってのは学問に対する姿勢を述べたものかもしれない。

常に客観的な姿勢で、真摯な態度で事実を観察し、ささいな点も
見逃さずに〜

とかね。方法論はそれに対する物理学とか化学とかにあたるんじゃないのかな。

小学校で習う理科は学問に対する姿勢を教えているようなものだ。
だから教科書にとらわれず〜とかも意味がある。「学問に対する姿勢」を
重視するのは結構なことだけど、学問自体はどこにいっちゃったの?って
感じかな。

上の方で出ていたswitch-caseにするか多様性を使うかについて言えば、
「全体がシンプルになるように分解しましょう」ってのは「学問に対する姿勢」
だね。これがXP信者の考え。いろんな方法論は、じゃあシンプルとは
どういうものなのか?ってのをこういうものだと断言して、そのための方法を
考えていく。

シンプルなんて難しいものを、こうこうこういうもんだと断言するわけだから、
確かに独善的だよ。でもね、それはペアプロで2人の人間が議論するにしても、
それぞれの意見は独善的だろ?方法論も同じなんだけどね。議論をする
土台を作るために、あえて独善的に断言しているわけ。

それを方法論の教科書に書いてある以上神聖不可侵なものとして無批判に
従わなきゃならないと考える方がおかしい。その土台の上で議論し、時には
土台そのものも疑う。これが自然科学の世界だし、「方法論」も同じだ。

物理でもソフト開発方法論でも、教科書に書いてあることは異議をさしはさ
むことさえゆるされないと思っているなら、それこそ「教科書教育」に毒されて
いるんじゃないの?困ったものだ。

736 :デフォルトの名無しさん:02/06/07 10:53
>>734
冷静だが?

従来の方法論をドキュメントの作成の仕方だとでも思っている人間に
方法論をかたってほしくないねぇ。

737 :デフォルトの名無しさん:02/06/07 11:13
>>736
自分は冷静でも、あちこちに感情を煽る表現が入っているので
冷静さを失わせようという意図が見える。
そういうのは冷静な発言とはとれないよ。

まあともかく、長いよ。xp-jp MLみたいだ。

738 :デフォルトの名無しさん:02/06/07 11:44
>>737
無意味は発言だねぇ。
こういうレスをつけさせるのが目的なのかい?君は。

それじゃ望みがかなったろうから、そろそろ学校へ行けよ、消防。

739 :デフォルトの名無しさん:02/06/07 12:27
やっぱりっぱな本に書いてあると、それだけで必要以上に権威を感じて、
服従するか拒絶するかの2者択一するしか、余裕がなくなっちゃうんだろうね。

xp信者も方法論信者も、他者の考え盲従してることに違いはない。
xp信者は自覚がない分たちが悪いかもしれない。

740 :デフォルトの名無しさん:02/06/07 12:29

      rー、
    」´ ̄`lー) \
    T¨L |_/⌒/   ←XPを導入してプロジェクトを成功させた俺たち
     `レ ̄`ヽ〈
       |  i__1
     _ゝ_/ ノ
      L__jイ´_ )
        |  イ
         |  ノ--、           r'⌒ヽ_
        ゝ、___ノ二7  /´ ̄l、_,/}:\
         |ーi |   l_/ /__ィ::.  ゝ~_ィ´:; ,ゝ
        __〉 {      (T´ |1:::.  \_>、};;_」
       'ー‐┘       ! ` ̄''ァ一 、\ ヽ} ←古い方法論に固執し、突然のクライアントの仕様変更に泣いてる連中
               〈` ̄ ̄^`¬ノ .::〔 ̄´
                   1  ヽ   .:::レ  ヽ、
                |_イー-、_;;j|_:.   ゝ、
                __,,,... -- |. {―――‐フゝ、   〉 -- ...,,,__
        _,, -‐ ´       ,r|__ト,    1ニノ ー'´       ` ‐- ,,_
    , ‐ ´         └―'´                     ` ‐ 、



741 :デフォルトの名無しさん:02/06/07 12:35
>>739
同意!
確かにやりとり見てると哲学的な話しか見えてこない。
XPと他の方法論との比較&論争じゃなくて、
両者の使えるところを実戦に導入していけばいいだけの話。。。

742 :デフォルトの名無しさん:02/06/07 12:37
>>741 禿どう!
漏れなんかはリファクタリングとテスティングだけで充分間に合ってます(w

743 :デフォルトの名無しさん:02/06/07 12:39
>>741

> 両者の使えるところを実戦に導入していけばいいだけの話


しかし、理論というのは一本貫いたものがあってこそ。
いいとこ取りというのは、理論が通らなくなる。

(90年代の日本企業じゃないんだからさ。二者択一でいけ。そのほうがうまくいく。)

744 :デフォルトの名無しさん:02/06/07 12:41
スパイラル信者です。いいとこ取りしてますが、何か?

745 :デフォルトの名無しさん:02/06/07 12:45
>小学校で習う理科は学問に対する姿勢を教えているようなものだ。
>だから教科書にとらわれず〜とかも意味がある。「学問に対する姿勢」を
>重視するのは結構なことだけど、学問自体はどこにいっちゃったの?って
>感じかな。

XPは小学生向き。方法論は大学生向き。ケテーイ!

746 :デフォルトの名無しさん:02/06/07 14:18
XP == スバイラル でしょう

747 :デフォルトの名無しさん:02/06/07 15:13
>>743
他人の考えをいいとこ取りし、混ぜ合わせて自分の意見を作り出すことは、
他人の考えを盲信するより難しいことだと思います。失敗も多いでしょう。
しかし、難しいから二者択一に逃げるというのは、どうかと思うのです。
学問の世界では、A理論とB理論のいいとこ取りであるC理論が実は正しかった…
というケースが非常に多いと思うのですが?

>>745
あなたは、学問自体の発展ために学問しているのですか?
私は学問自体は、最終的な利益への貢献度によって評価されるものだと思っています。
そのためには、あらゆる手段を試し、適正に評価し、取捨選択するべきだと思います。
派閥にしか関心が無く、理論を煮詰めることを放棄した科学者を想像すれば、
「方法論を二者択一することこそ幼稚」だということは容易に想像できると思うのですが。

748 :デフォルトの名無しさん:02/06/07 20:24
とりあえず学問持ち出すのは止めとけ。
宗教論争となんも変わらん。
議論のための議論はもうおなかイパーイ!

749 :デフォルトの名無しさん:02/06/07 20:32
>>748
だって宗教論争だもん。みんな信者だし(w

750 :デフォルトの名無しさん:02/06/07 20:37
>>749

そんなこたー解っとるよ。
メタ議論してるつもりで学問持ち出してる奴がウザイだけ。
信者を名乗る奴より自覚症状が無いだけ始末が悪い。

751 :749:02/06/07 20:42
XP=小学校の授業、方法論=大学の授業はいい喩えだと思うけどね。

大学の実生活から遊離した授業を横で眺めつつ、
みんなもっと楽しくやろうよ、っていってる小学生たち。

小学生の図工の時間の生き生きとした風景と
大学の何とか工学概論の講義の風景。

ろくに設計しないで「えいやっ」と作る鳥の巣箱と
延々と緻密な設計しなけりゃできない高層ビル。



752 :デフォルトの名無しさん:02/06/07 20:44
>>750

>メタ議論してるつもりで学問持ち出してる奴がウザイだけ。

「メタ議論」の用法が間違っていると思われ。

753 :デフォルトの名無しさん:02/06/07 20:44
>>747

ちまちまと各論反対を言うだけならダメ。

それよりも、まるっきり違うオプションの理論を構築して、
議論したほうがよほどレベルが高い。(難しいけど)

754 :デフォルトの名無しさん:02/06/07 20:45
>>750
君の発言をメタ議論という。

755 :デフォルトの名無しさん:02/06/07 20:48
>>753
>それよりも、まるっきり違うオプションの理論を構築して、
>議論したほうがよほどレベルが高い。(難しいけど)

こんなことをさらっといえるのが、本気でものを考えてない証拠だろうな。
まともな神経の持ち主なら身の程知らずと笑われるのが怖くてとてもいえないや。

756 :デフォルトの名無しさん:02/06/07 21:02
>>751
そのメタファよいね。
小学生には高層ビルは作れないと思う。
でも、何度も手直しして立派な鳥の巣箱を作ることは出来そう。

757 :デフォルトの名無しさん:02/06/07 21:11
結論

今までの間違い=小学生にビルを作らせようとしていたこと。
XPの功績=小学生には鳥の巣箱レベルがお似合いだと看破した事。

758 :デフォルトの名無しさん:02/06/07 21:34
>>747
> 学問は利益に貢献度により評価

工学にはそういう面があるが理学はそうではない。彼らは役に立たないものの方を尊ぶ。連続体仮説とか(w

ソフトウェア理学としよう。これからは。

759 :デフォルトの名無しさん:02/06/07 21:41
大学の教科書では実践の役に立たない。
漏れがビルを建てるら、実際にビルを建てた経験者とペアを組む。


760 :デフォルトの名無しさん:02/06/07 21:52
多くのソフトウェア設計は、構造的欠陥を持つ。未来においても完璧でありつづける設計はないからだ。
それを認めず、方法論を二者択一すれば開発上の問題が解決すると判断する態度は、まさに大学生だな。

あらゆる盲信は進歩の敵だ。

幼稚ないいとこ取りも、完全否定するほど悪くはないと思うが?学歴高いと自分で考えるのが億劫か?(ワラ

761 :デフォルトの名無しさん:02/06/07 22:02
>>760
禿同

762 :デフォルトの名無しさん:02/06/07 22:02
ソフトウェア工学もXPもビル作るのに有効なのか、鳥の巣箱作るのに有効なのか、
開発対象の規模について明言してないから混乱するのでは?

規模や開発言語、業態によって開発プロセスを変えるのが自然だと思われ。

763 :デフォルトの名無しさん:02/06/07 22:07
学問とか、方法論とか、理論とかいう言葉を持ち出すのは
現場を知らない学生か教授のみ。

実践から導き出されたXPは試す価値あり。
つねに理論は後からついてくると思われ。

764 :デフォルトの名無しさん:02/06/07 22:07
>あらゆる盲信は進歩の敵だ.
という発想を盲信するとどうなるんだろう、などと言ってみるテスト.

765 :デフォルトの名無しさん:02/06/07 22:09
とりあえずラスト50スレ読んで、
>>735 に同意。


766 :XP狂信者:02/06/07 22:16
シンプルに言おう
XPは長島だ。
来た球を打て。ジャストミートしよう。そうすればホームランだ。

対して方法論は
野村ID野球だ。
一生懸命考えてしんどい思いをしながらやっていく。

どっちが普遍的だ?どっちが興味もてる?

だから、XPは永遠だ。PG、SEの憧れであり続けられるのだ。


767 :デフォルトの名無しさん:02/06/07 22:21
長島は嫌いなのでXPやめます。

768 :デフォルトの名無しさん:02/06/07 22:28
>>766
それは万人が理解できるメタファではないので却下。

769 :デフォルトの名無しさん:02/06/07 22:41
>>759
>大学の教科書では実践の役に立たない。
>漏れがビルを建てるら、実際にビルを建てた経験者とペアを組む。

大学の教科書の知識だけでは実践に役に立たないかもしれないが、
大学の教科書の知識さえないのでは論外。経験者の方がキミとペアを
組みたがらないと思われ。

770 :デフォルトの名無しさん:02/06/07 22:44
>>764
>>あらゆる盲信は進歩の敵だ.
>という発想を盲信するとどうなるんだろう、などと言ってみるテスト.

自己矛盾してるから盲信できなくて安心。安心。
自己矛盾を抱え込むことが安全装置なんだよ。

771 :デフォルトの名無しさん:02/06/07 22:45
>>755
> こんなことをさらっといえるのが、本気でものを考えてない証拠だろうな。
> まともな神経の持ち主なら身の程知らずと笑われるのが怖くてとてもいえないや。

ということは、やはり、XP を否定することは恐れ多くてできない、素晴らしいものである
と認めるわけやね。

772 :デフォルトの名無しさん:02/06/07 22:47
>>763
>学問とか、方法論とか、理論とかいう言葉を持ち出すのは
>現場を知らない学生か教授のみ。
>
>実践から導き出されたXPは試す価値あり。
>つねに理論は後からついてくると思われ。

既存の方法論も一応実践をベースにしているから、その主張は
正しくないと思われ。CMMだって実践に基づいてる(w


773 :デフォルトの名無しさん:02/06/07 22:47
日本風XP検討メモ。

(1)最初のn日で客と打ち合わせをし、要求仕様を定義する。
(2)次のn日で概要設計のラフをまとめて客の承認を得る。
※1〜2の間、設計担当者以外は環境構築とツールのお勉強。
(3)ストーリーカード作成およびイテレーション、リリース計画立案。
(4)タスク消化開始。ドキュメントは(2)の物を使うがメンテしない。
(5)ふつうにXP。
(6)1イテレーション終了時に現状を反映してドキュメント再作成。
(7)5〜6繰り返し。
(8)リリース時にタスクとして納品用各種ドキュメント作成。
(9)5〜8繰り返し。
(10)第一次正式リリース。
(11)理想的には継続。

ドキュメントはSEが必要最小限の労力で作る。
ただし細部や煮詰まった個所は放置して厳密さこだわらない(こだわっても無駄)。
客にストーリーカードの提出を期待してはいけないので用意して判子をもらおう。
プログラマはドキュメントに忠実である必要はない(分からんもん分からんしクソはクソ)。
ドキュメントについての修正案は社内MLなどで周知蓄積する(ペアプロだけに頼るな)。
客からの変更要求の「やっぱりいらない」では潰さずに隠す(You Are Gonna Need It.)。
納品用ドキュメント作成はあらかじめタスクとして上げておく(必須)。

今日はここまで。


774 :デフォルトの名無しさん:02/06/07 22:51
>>771

いいとこどりはどこいっちゃったんだよ?
お前は前の議論を忘れてるのか?3歩あるくと忘れる鳥頭か?

775 :デフォルトの名無しさん:02/06/07 22:52
>769
昔の大工はXP。

バカヤロウ、てめえはカンナひとつまともにかけられねえのか。
オッス、すんません棟梁。
いいかようく見てやがれトンチキが。
オッス。

ペアプロで家が建つ。


776 :デフォルトの名無しさん:02/06/07 22:53
でも高層ビルは建たない。

777 :743, 771:02/06/07 22:54
俺は最初からいいとこどり反対派なのだが・・・。

778 :デフォルトの名無しさん:02/06/07 22:55
結論その2

XPの主張:木造住宅を建てよう。高層ビルはやめよう。

# 書いた後に気づいたが、ぜんぜんしゃれになってないな。

779 :デフォルトの名無しさん:02/06/07 22:56
なんでこのスレの人はXPに執着してんの?

XP見て、「そこまで極端にはできないから俺はこーする」とか、>>766にチラリと出たように
「そーゆー極端な考え方を出した裏には、普遍的なアイデアがあるだろう. それを自分なりに解釈し実践しよう」
ってもんじゃないのかな

780 :デフォルトの名無しさん:02/06/07 22:56
>>778
それはわかってるが、君の都合で3択を勝手に2択にしても、
煽りにすらなってないんだが、何が言いたいのかね、チミは。

781 :デフォルトの名無しさん:02/06/07 22:57
高層ビルって、どこから出てきた話なの?


782 :デフォルトの名無しさん:02/06/07 22:58
>>778

ソフト作りとハード作りを一緒にすな ボーケー

783 :デフォルトの名無しさん:02/06/07 23:01
>>779
スレタイトルをよめ。それが理由だ。
ここは、みなXPに執着している人間が集うスレだ。(XP信者もXP批判者も)
富士山頂に来て、ここは何で登山が好きな人ばかりいるの?と聞くのか。

ところで後半がちんぷんかんぷんなんだが?なにゆーとるの?
じぇんじぇんわかりましぇーん。内容がないよう(w

784 :デフォルトの名無しさん:02/06/07 23:02
>>782
本質は同じと思われ。
あるいは両者の違いを簡潔にまとめよ。(制限時間5分)

785 :デフォルトの名無しさん:02/06/07 23:14
>>783 重症だね

786 :デフォルトの名無しさん:02/06/07 23:17
三択って、
□XPをしよう
□XPはやめよう
□いいとこどりをしよう
ってこと?

787 :デフォルトの名無しさん:02/06/07 23:19
規模の問題とXPを採用する話は無関係でしょ。関係あるの?

788 :デフォルトの名無しさん:02/06/08 00:27
>>787
シンプルな実装を優先して大規模な伽羅を作るとどこかで破綻しないのか、ってことだと思う。

789 :デフォルトの名無しさん:02/06/08 01:40
>>773
概要設計は従来どおりやって、詳細設計はXP的に省こうってことだね。
なるほど、割と現実的な気がする。つーか俺が信頼できる外注に
やってるのと同じだ。

>(8)リリース時にタスクとして納品用各種ドキュメント作成。

俺はドキュメントも正式リリースの後に1回出させるだけか、
readmeやchange.logで代用するけど、まあ、これは俺が技術者で、
相手のやってることを理解しているからだろうね。一般の顧客を相手
にするなら、必要だろうね。



790 :XP狂信者:02/06/08 03:33
大工というメタファで言えば、
どっちかというと、
伝統大工vsツーバイフォーじゃないかねぇ?
木の性質を生かした1000年使える家vs消耗品。



791 :デフォルトの名無しさん:02/06/08 04:45
>>778
高層ビルのようなソフトウェアがどのくらいあるかだな。
漏れ個人の感覚的に、一ヶ月すげー頑張ってすらすら実装できて
奇跡のようにバグがゼロという条件で完成しそうなら XP でできる規模で、
一人じゃどうあがいても無理だめぽなら 従来の方法論かなと思う。

それに、大きい規模のソフトウェアって長く変化せずに利用できることを
目的にするものが多いから XP 向きではないと思う。
OS、公共システム、金融システムとか。

792 :デフォルトの名無しさん:02/06/08 08:51
>>791
>一ヶ月すげー頑張ってすらすら実装できて奇跡のようにバグがゼロという条件
>で完成しそうなら

クライスラーの給与計算システムってそんな小さなシステムだったのか?

793 :XP狂信者:02/06/08 09:22
んー?
だいたいオープンソースってXPノリでしょ?

ウォーターフォールで作ってるOSってどんなやつやねん?
そりゃ、IBMの互換機OSをF通やヘタチが作ったというやつなら
ウォーターフォールでもおかしかないが。

ちなみに対比しているのは、
アーキテクト=デザイナ=プログラマ=テスタ
vs
アーキテクト、デザイナ、プログラマ、テスタの分業体制ね。
従来の方法論というときに対比しなければならないのは
この分業か全部をやるかの対比。
NTはカトラーが作ったが、アーキテクトであると同時に彼も
いっぱいコード書いてる。
Linuxも、Linusがもとは書いてるわけだし。
分業で作ったOSって、メインフレーマのOSぐらいじゃないのか?

multicsは確かにウォーターフォールだったわけだが、
それの反省で、個人で作ったのがunixの原型なわけだしなぁ。

職人魂vs一般プログラマ大量方式
これで戦わせると、職人魂のほうが、価値あるソフトウェアを
作ってきてる。


794 :デフォルトの名無しさん:02/06/08 13:38
オープンソースを牽引しているのはトップレベルのプログラマだからね。
こんなことができるのは一握りだとおもうけど。凡人には無理。

795 :XP信者:02/06/08 14:32
>>785

>重症だね

そりゃ自覚症状がでてるくらいだからね

796 :XP信者:02/06/08 14:33
>>779

>XP見て、「そこまで極端にはできないから俺はこーする」とか、

XPはそれを推奨してますが。



797 :デフォルトの名無しさん:02/06/08 14:39
自分が正しいと思うことをやれってか?
意味ねー

798 :デフォルトの名無しさん:02/06/08 14:48
正しいことをするのが正しい。。。内容がないよう。

799 :デフォルトの名無しさん:02/06/08 15:05
どんどんずらしてますな。

800 :デフォルトの名無しさん:02/06/08 15:12
抽象論は飽きたんで、実際大規模なシステムにXPを導入して成功した事例とか書籍とか教えてきぼんぬ。

あ、そうそう・・・海外のはダメダメね。日本の事情に合ってないと思うから!
XPの一連の本って海外の事情を前提に書かれてるから、イマイチ読む気になれんね。


801 :デフォルトの名無しさん:02/06/08 15:13
>>797
XPは青春ですか?

802 :デフォルトの名無しさん:02/06/08 15:17
>>800
日本にXPは根付きません。なぜなら日本のウォーターフォールが
すでにそれなのです。

いい加減な設計。度重なる仕様変更。馴れ合い。一週間だけ出荷延期を繰り返す納期。
そうです。すでにXPは実践されているのです。

あなたは幸福の青い鳥を捜し求めていますが、青い鳥はあなたの一番身近な
ところにいるのです。


803 :デフォルトの名無しさん:02/06/08 15:21
>>802
反論しようと思ったが、XP紹介のときに言い尽くされてる事になるだけなのでやめた。

804 :デフォルトの名無しさん:02/06/08 15:22
追加

いい加減な設計。度重なる仕様変更。馴れ合い。一週間だけ出荷延期を繰り返す納期。
行き当たりばったりの判断しか出来ないマネージャ。自分の担当箇所しか把握していない
SEたち。

これをプロジェクトの破綻と考えるかXPを考えるかはあなたの気持ちしだい。
さあ明日からちょっと考え方を変えてみませんか?とたんにすばらしい世界の
住人になれますよ。

仕様変更は正しい。
設計はいい加減なのが正しい。
その場その場の日和見主義が正しい。
プログラムの全体性など考えるのは悪。
とにかく余計なことを考えず目の前のタスクを片付けよう。

さあもう一度唱えましょう。毎朝唱えましょう。

805 :デフォルトの名無しさん:02/06/08 15:25
>>803
気の持ちようです。気のせいです。あなたはすでにXPの渦中にいるのです。
深く考えるのはやめましょう。目の前のタスクを片付けることだけを考えましょう。
仕様変更は素直に受け入れましょう。全体を把握していないことを罵ることは
悪です。考え方を変えればあなたも明日から幸せになれます。

806 :デフォルトの名無しさん:02/06/08 15:27
>>800
その論法で行くと日本が自前で方法論を作って実績あげないとダメにならんか?
それでも、業界特有の事情、メーカー特有の事情といって審議拒否できる。

前提となっている海外の事情とは何で、
どうして日本では適用できないのか、
日本でも適用できる部分はあるのかを議論したいが。

807 :デフォルトの名無しさん:02/06/08 15:31
>>802
米国でもプロジェクトの体質は似たようなもんだから CMM 流行らせて、
軍や政府へ納入するシステムの質を上げようとしてたんだと思った。

808 :XP狂信者:02/06/08 16:16
そうウォーターフォールは無理なんだよ。
そこを認めることから始めよう。
公式的にそれを表明しよう。
そうすればXPさ。確かにね。

公式的になぜ認めなければならないかって?
それは、週40時間労働のプラクティスが実践できるかどうかの
キーだからだ。

非公式だから、無茶な残業がはびこるんだ。
公式的に認めてしまえば楽になる。

良い設計を考える余裕が生まれてくる。
そういうこと。


809 :デフォルトの名無しさん:02/06/08 16:26
XPは「いいかげんに設計」じゃなくて
「対象を最少にしてからきっちり設計」を繰り返す。

延期(?)を繰り返すのも、「あらかじめ期日を決めてから、それができなくて破る」のではなく
「先にここまで実装すると合意し、それを期日に完成させ、次に進む」

だいぶ違うな。>>804

810 :XP狂信者:02/06/08 16:28
>>794
そこなんだが、それは鶏と卵の関係だよ。
XPやオプソやればスキルアップが早い。

いつまでも肉体労働デバッグやらせておいたり、
ださいデザイン詳細設計コーディングをガリガリやらせているから、
レベルアップが遅い。
だから、できなくなってしまうんだよ。



811 :デフォルトの名無しさん:02/06/08 16:38
みんなでデスマーチをXPと呼ぶことにしよう。
積極的に"XP"に突入するように努力しよう。
XPになったらみんなで喜ぼう。


812 :デフォルトの名無しさん:02/06/08 19:19
ウオーターフォールとの違いについてXP体験者の意見を起勃ーン!

っていうか、XPも所詮方法論の1つだよね(プ

813 :デフォルトの名無しさん:02/06/08 19:31
>>812
>っていうか、XPも所詮方法論の1つだよね(プ
とりあえず死ね。小鳥。脳みそ。

814 :デフォルトの名無しさん:02/06/08 20:33
>>813
こういうふうに、方法論に対して感情的な
拒絶反応しかできないところにXP信者の悲哀があるな。
おれには物理なんか難しくてわかんねーよ、
難しい話しないでくれよ、適当に作ってりゃできるからいいじゃんかよー、ってな。
物理と理科をどっちでも選べる人間と
理科しか選べない人間の余裕の差だろうな。

815 :デフォルトの名無しさん:02/06/08 20:57
>>813
おい!お前ら!こっちも面白くなってきたぞ!
http://pc.2ch.net/test/read.cgi/tech/1021468476/l50

816 :デフォルトの名無しさん:02/06/08 21:12
そっちにも顔を出してますが何か

817 :デフォルトの名無しさん:02/06/08 21:31
>>814
ここまで食いついてくるバカがいるとは思わなかった(ワラ
しかも物理と理科?理科と社会の間違い?
いずれにしても稚拙なアナロジーだ。

818 :XP信者:02/06/08 22:03
>>812

>ウオーターフォールとの違いについてXP体験者の意見を起勃ーン!

ちゃんとしたウォーターフォールが実施されているのを見たことがありません。
ちゃんとしたXPが実施されているのも見たことが無いので、どちらも想像の
産物かもしれません。

>っていうか、XPも所詮方法論の1つだよね(プ

そうですけど、むしろ宗教ですって。


819 :XP信者:02/06/08 22:05
>>800

>抽象論は飽きたんで、実際大規模なシステムにXPを導入して成功した事例とか書籍とか教えてきぼんぬ。

むしろ、大規模なシステムにXP以外を導入して成功した事例を知りたい。

っていうか日本で、大規模なシステムの開発に成功した事例ってどんなのがあります?


820 :デフォルトの名無しさん:02/06/08 22:15
>>819
DATARUNで朝日テレビの全社システムを設計し成功したというのが以前日経に載ってた

821 :デフォルトの名無しさん:02/06/09 03:38
>>917
>いずれにしても稚拙なアナロジーだ。

もう少し中身のあることしゃべれないの?(w

>>818
>ちゃんとしたウォーターフォールが実施されているのを見たことがありません。
>ちゃんとしたXPが実施されているのも見たことが無いので、どちらも想像の
>産物かもしれません。

それはそうだね。物理の教科書に出てくる「空気抵抗は無視する」
「摩擦は考えないものとする」世界が実際に存在しないのと同じ。
同じようにちゃんとした「物理」が現実の世界で実施されているのを見たことがない。(w



822 :デフォルトの名無しさん:02/06/09 03:50
>>817
>しかも物理と理科?理科と社会の間違い?

物理と理科だよ。要は小学校の(レベルは低くても生き生きとした楽しい)授業を選ぶか、
大学の(レベルは高くても地味で傍目にはあまり面白くなさそうな)授業を選ぶか。

大学生はどちらでも選択できるけど、小学生は小学校の授業しか選択できなくて
哀れだねって話だよ。ちょっと小学生には難しすぎるアナロジーだったかな(w


823 :デフォルトの名無しさん:02/06/09 04:10
あと、厳密なXPってなんなのかねぇ。

例えば概要のレベルでさえ全体像を伝えずに、1つ1つの断片的なシナリオ
だけを随時伝えたとする。効率に脇においたとして、作業を行っている人間の
精神面でそれってよいのかねぇ。

じゃ概要だけは全体像を伝えたとする。でも概要とはいえ全体像なんて
「人間に扱えない」ようなものを扱うわけだよねぇ。

ウォーターフォールは当たり前だけど仕様変更を認めている。それが正しく
実施されず、仕様変更があたかも悪であるかのように運営されていることが
問題ともいえるねぇ。ま、ウォーターフォールの考え方にそもそも仕様変更を
悪と考えがちな潜在的な欠陥があるといえば、そうかもしれないけどね。

XPもウォーターフォールも規模が小さいと別の体系に見えるかもしれないけど、
(XPが大規模なものも可能として)規模が大きくなれば、どちらもだんだん
近づいていくと思うけどね。



824 :デフォルトの名無しさん:02/06/09 04:20
>>823 お前等、そんなに複雑怪奇な設計してるんですか?
   それって、センス&頭悪い奴がウォーターフォールで分割して、
   化け物と化した仕様を弄くってるのと違いますか?
>じゃ概要だけは全体像を伝えたとする。でも概要とはいえ全体像なんて
>「人間に扱えない」ようなものを扱うわけだよねぇ。


825 :XP狂信者:02/06/09 04:27
>>823
いやいや違うんだよ。
デスマーチプロジェクトでの最大の課題は、
みんながどうでもいいことに血道をあげるのを
以下にやめるかが大事だということなんだ。

公式的にそう言い切っているのはXP。

ヨードンのデスマーチにも書かれているように、(triage)
対策としてお勧めなのは、もっとも大事な機能の20%を実現すること。
20-80ルールの二乗則を使うと、
36%を実現すると、96%の機能は実現可能。
4%は多分夢、幻だから相手にするなということ。

ウォーターフォールにはそういう枠組みがないんだよ。
全体仕様でプライオリティがごっちゃになった状態で
分業で、伝言ゲームやりながらやっていくスタイルが
効率いいわけないんだって。

スパイラルに関しては公式的な原典がどれか
よーわからんので、コメントは微妙になるけどな。

ウォーターフォールスタイルでもバージョン3からは
まともなソフトウェアが作れるというのも経験的事実だけど、
結局、バージョン1はパイロットプロジェクトなわけで、
それをスパイラルだと思えば、別にそれはそれでかまわんさ。



826 :デフォルトの名無しさん:02/06/09 04:36
あと、
ウォーターフォール≠スパイラル≠イテレーション(RUP,XP)
ってあたりはきちっと区別しておいてくれ。


827 :デフォルトの名無しさん:02/06/09 04:36
>>824
>>>823 お前等、そんなに複雑怪奇な設計してるんですか?
>   それって、センス&頭悪い奴がウォーターフォールで分割して、
>   化け物と化した仕様を弄くってるのと違いますか?

簡単なものならXPだろうがウォーターフォールだろうが、現状のままで
うまくいくよ。いかないのはやってる人間が馬鹿だから。とんでもなく
複雑なものも、ベースをどこにおくかは違っても、それが成功するなら
変形XPでも変形ウォーターフォールでも、最終的に大して変わらない形
になると予想するよ。

両者の違いが顕著なのは中途半端な複雑さの時だけだ。

828 :デフォルトの名無しさん:02/06/09 04:45
>>825

>デスマーチプロジェクトでの最大の課題は、
>みんながどうでもいいことに血道をあげるのを
>以下にやめるかが大事だということなんだ。

総論賛成だが・・・

>ヨードンのデスマーチにも書かれているように、(triage)
>対策としてお勧めなのは、もっとも大事な機能の20%を実現すること。
>20-80ルールの二乗則を使うと、
>36%を実現すると、96%の機能は実現可能。
>4%は多分夢、幻だから相手にするなということ。

これも反対するべきところはないが・・・

>ウォーターフォールにはそういう枠組みがないんだよ。

だったらXPにもないと思うけどね。顧客がプライオリティを
決定する、が仕組みとはちゃんちゃらおかしい。

>全体仕様でプライオリティがごっちゃになった状態で
>分業で、伝言ゲームやりながらやっていくスタイルが
>効率いいわけないんだって。

XPは伝言ゲームを開発側からエンドユーザー側に追い出しただけだ。
全体として変わらない。それが意味が全くないとはいわないけどね。


829 :デフォルトの名無しさん:02/06/09 04:47
>>826

十分複雑なプロジェクトに対しては区別がなくなるだろうという趣旨の発言にたいして、
区別しておいてくれって、あのね、どうしてキミはいつもとんちんかんなレスつけるのかね?

830 :デフォルトの名無しさん:02/06/09 04:49
スパイラルとイテレーションの違いがわからん・・・

831 :デフォルトの名無しさん:02/06/09 04:57
828の補足だけど

すべての仕様を把握し、取りまとめる人間はいずれにしろ必要なんだよ。
それが顧客側の担当者か、開発者側のSEかの違いはあっても。
顧客側の担当者がやるとして、その人はどうやって自分たちの要求を
取りまとめて、優先順位をつけるのか。XPは何も助けてくれない。

リリースを頻繁にやって実物を見せることは、確かによい点もある。
けどこの発想はプロトタイピングとかXP以前からあるよね。すごく
有効なケースもあれば、やはりそうではないケースもある。


832 :デフォルトの名無しさん:02/06/09 05:22
>>830
各種方法論とくっ付いて使われる用語なので、文脈によりけりだなあ。

古典的なスパイラルは要求定義・分析・設計・実装・テストといった
ウォーターフォール型を何度も繰り返す開発形態。

RUP ではスパイラル一回転分が一イテレーション。
最初の方のイテレーションでは要求定義や分析の占める割合が大きく、
段々設計と実装が増えていき、最終的には残った実装とテストが占める。
これの図でも見れ。
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/ObjectModeling/article.html

XP では作ると決めておいたタスクを作る期間がイテレーション。

833 :デフォルトの名無しさん:02/06/09 05:23
>>831
>けどこの発想はプロトタイピングとかXP以前からあるよね
プロトタイピングを extreme に推し進めると小規模リリースになる。
プロトタイプは実用に供しないが、XP のリリースは動く。
まあ、動くといってもユニットテストは
そもそも作るソフトが間違ってないかまでは保証してくれないから、
ストーリーと受け入れテストの精度が問題になる。
そうすると改めて、

>顧客側の担当者がやるとして、その人はどうやって自分たちの要求を
>取りまとめて、優先順位をつけるのか。XPは何も助けてくれない。

が浮き彫りになるね。
イテレーション間隔が短いので軌道修正も楽だろうという
希望的観測だけでは心もとない。

834 :デフォルトの名無しさん:02/06/09 05:31
>>833
>>けどこの発想はプロトタイピングとかXP以前からあるよね
>プロトタイピングを extreme に推し進めると小規模リリースになる。
>プロトタイプは実用に供しないが、XP のリリースは動く。

プロトタイプを発展させてそのまま実用プログラムのベースにしようという
考えも以前からある。キミが知っててわざと(何か都合があって)触れないのか、
知らないのかは知らんが。

>まあ、動くといってもユニットテストは
>そもそも作るソフトが間違ってないかまでは保証してくれないから、
>ストーリーと受け入れテストの精度が問題になる。
>そうすると改めて、
>
>>顧客側の担当者がやるとして、その人はどうやって自分たちの要求を
>>取りまとめて、優先順位をつけるのか。XPは何も助けてくれない。
>
>が浮き彫りになるね。
>イテレーション間隔が短いので軌道修正も楽だろうという
>希望的観測だけでは心もとない。

何が言いたいことなのかよくわからんのだけど・・・
俺の
>XPは何も助けてくれない。
に同意するということでよいの?

835 :XP狂信者:02/06/09 05:31
>>829
すまんのぉ。コテハンじゃないので、君の発言の履歴までは把握できんのだよ。
>>831の話なら了解だが、
それはXPではソフトウェア開発側の仕事ではないと言っているわけだから、
それがXPの適用できない理由なら、いかにもそうだろう。

助けてはくれないが、考え直す機会を与えている点がポイントだ。
ついでに常にイクラというのも伝えているのもな。
通常はそれで十分じゃないのかね?

実際、君の領域では、そこがネックになっているというのかい?
というより、優先順位さえ誰もはっきりできないソフトウェア開発
が成功する可能性はあるのかい?
既存方法論ではそれが可能だとでも?

そこのところを突っ込んで聞きたいね。
XPが万能解だなんて誰も言ってないんだしさ。








836 :デフォルトの名無しさん:02/06/09 05:31
>>832
>XP では作ると決めておいたタスクを作る期間がイテレーション。
訂正。タスク選択からイテレーションだな。

平たく言えば、ウォーターフォールの頭から保守の手前までが一つのイテレーションに相当する。
ただし、RUP の場合はイテレーションごとに分析や実装の割合を変えながら
少しずつ段階的に作っていってリスクを分散させている。
XP の場合は、その時点で最小限必要な機能だけを選んで作ることでリスクを抑えている。

837 :デフォルトの名無しさん:02/06/09 05:44
>>835
>>>829
>すまんのぉ。コテハンじゃないので、君の発言の履歴までは把握できんのだよ。

ってことは826=825なのか。俺もわからなかった。

>それはXPではソフトウェア開発側の仕事ではないと言っているわけだから、
>それがXPの適用できない理由なら、いかにもそうだろう。
>
>助けてはくれないが、考え直す機会を与えている点がポイントだ。

それだけの説明じゃ開発側が責任を放棄し顧客に押し付けたと
いわれるだけだと思うけどね。開発者がやるより顧客がやるのが
実は正しかった、顧客なら開発者よりもっとうまく出来る、という
なら別だけど。

>ついでに常にイクラというのも伝えているのもな。
>通常はそれで十分じゃないのかね?
>
>実際、君の領域では、そこがネックになっているというのかい?
>というより、優先順位さえ誰もはっきりできないソフトウェア開発
>が成功する可能性はあるのかい?
>既存方法論ではそれが可能だとでも?

XPでそれが可能とでも?優先度の決定が自分(開発者)の仕事(責任)
でなければ、プロジェクトがどうなろうと、自分は自分の責任を果たしたから
よいという考えじゃ、さすがにないと思うけど、じゃあ同考えるわけ?



838 :デフォルトの名無しさん:02/06/09 05:47
>ついでに常にイクラというのも伝えているのもな。
>通常はそれで十分じゃないのかね?

仕様変更/追加のコストのことをいってるの?
それがXPできっちり出来て、他の方法じゃできない理由を聞きたい。
おれはXPでも現実的には出来ないと思ってるんだけど。

839 :デフォルトの名無しさん:02/06/09 05:53
>>834
>プロトタイプを発展させてそのまま実用プログラムのベースにしようという
いや、知っているけど。
ああ、すまん。張りぼてを作るいわゆるプロトタイプとプロトタイピング開発を混同していた。
後者を指していたのか。

>>XPは何も助けてくれない。
>に同意するということでよいの?
そうだね。
自分でまだよく咀嚼できていないから半端な書き方になってる。
独り言だと思ってくれ。

方法論は提示しないが、顧客と十分に対話をすれば
クリアできる問題だというのがおそらく XP の立場だと思う。
逆に言えば、客の話も聞かずに良いものが作れるはずがないという思想か。
話を十分に聞けってのは要求工学も同じだけど、形式的な方法を重視するよりも
オンサイト顧客でコミュニケーションを増やした方が効果があるとするのが XP なんだろうな。

840 :デフォルトの名無しさん:02/06/09 06:01
>>839
>方法論は提示しないが、顧客と十分に対話をすれば
>クリアできる問題だというのがおそらく XP の立場だと思う。
>逆に言えば、客の話も聞かずに良いものが作れるはずがないという思想か。
>話を十分に聞けってのは要求工学も同じだけど、形式的な方法を重視するよりも
>オンサイト顧客でコミュニケーションを増やした方が効果があるとするのが XP なんだろうな。

まるで形式的な方法を重視すると対話がおろそかになるといってるようだが。
「形式化」するのは対話&検討をするため(と後からそれをトレースするため)のはずだ。

形式的に対話した振りをして実質的な対話をしないような人間なら、XPでも他の方法でも
やっぱりしないと思うけどね。

841 :デフォルトの名無しさん:02/06/09 06:02
>>837
>顧客側の担当者がやるとして、その人はどうやって自分たちの要求を
>取りまとめて、優先順位をつけるのか。XPは何も助けてくれない。
開発側と話し合って適当に決める。
今までと対して変わらないと思われ。
顧客に対して、作らせているものにもっと責任と自覚を持てと促している以外は。

842 :XP狂信者:02/06/09 06:03
某所からのこぴぺだ。

オンサイト顧客(On-Site Customer)
現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。

どこかで適当な文書を読んだ記憶があるのだが、失念。
(2001/6/6追記 辻 忠一さん提供の情報より)
[7]「人月の神話」p186

ソフトウエア製作者が顧客のために行う最も重要な仕事は、
製品の用件を繰り返し抽出し、洗練していくことだ。
実際のところ、顧客自信何を希望しているのかわかっていないものだ。
彼らは通常、どんな質問に答えなくてはならないかを理解しておらず、
指定しなければならない問題の詳細さについて考えたことなどほとんどない。
「これまで人がやっていた情報処理作業と
同じように動く新しいソフトウェアシステムを作ってくれ」
という単純な答えでは、実際まさしく単純すぎる。
顧客は、性格にそれを望んでいるのではない。
複雑なソフトウェアシステムは、それ以上に働き、動き、処理するものだ。
そうした働きのダイナミクスを創造するのは難しい。
したがってソフトウェアのはたらきを計画する場合、
顧客とデザイナーとの間であらゆることについて繰り返し話し合うことをシステム定義の一部として認めることが必要である。

某所からのコピーだ。
「ようするに話し合え。」
これがXP的な答えだな。
そうは言っても何を話さなければならないかが不明確なわけだが、

ストーリーカードを作ること。
優先順位を決めること。

これを目標につめられるだけつめろといっているわけだから、
プロセスとしてはかなり明確だ。

いわゆるコンサルタント(政治的SE)の難しさはわかるのだが、
それの回答をXPに求めても、それは無理だろう。

ただし、技術と政治と経済のインタフェースを
明確にしているのがポイント高い。


843 :XP狂信者:02/06/09 06:07
あと、
アクセプタンステストもユーザの機能になってるな。
そういう意味では、XPのユーザは普通のレベルの人間を想定してはいないよ。



844 :デフォルトの名無しさん:02/06/09 06:09
>>840
対立項的な書き方をしたのは間違いだった。
単純に
対話が足りていない→もっと対話しろ→オンサイト顧客
でいいな。

対話の内容でなく、対話すること自体を大文字で制度化しているのがXP の特徴だろう。

845 :XP狂信者:02/06/09 06:11
>>837についてだが、
ほかの方法論でやれるというのなら、それを知りたいと思っているから
聞いてみただけだ。
ほかの方法論でできないのなら、別にXPができなくても、問題にはならんしな。

要求定義工学とかRUPのユースケースを
ユーザと一緒にレビューしましょなんてのはやめてくれよ。
あれは、あれで頭がイタクなるだけだから。


846 :デフォルトの名無しさん:02/06/09 06:12
>>841
>今までと対して変わらないと思われ。
>顧客に対して、作らせているものにもっと責任と自覚を持てと促している以外は。

ようするにいままでと全く同じということでいいのだよね。
顧客が自分が作らせているものに対して責任と自覚を持っていないとは
思えないんでね。


847 :デフォルトの名無しさん:02/06/09 06:30
>>842
>実際のところ、顧客自信何を希望しているのかわかっていないものだ。

そのとおり。顧客は自分が作らせているものに対して責任も自覚もあるが、
分析力がない。開発者も分析力がないが、顧客はそれ以上にない。

>したがってソフトウェアのはたらきを計画する場合、
>顧客とデザイナーとの間であらゆることについて繰り返し話し合うことをシステム定義の一部として認めることが必要である。
>
>某所からのコピーだ。
>「ようするに話し合え。」
>これがXP的な答えだな。
>そうは言っても何を話さなければならないかが不明確なわけだが、

そう。話し合えといって解決するなら誰も苦労しない。
時間をかけたとしても分析が伴わない話し合いでは意味がない。

>ストーリーカードを作ること。
>優先順位を決めること。
>
>これを目標につめられるだけつめろといっているわけだから、
>プロセスとしてはかなり明確だ。
>
>いわゆるコンサルタント(政治的SE)の難しさはわかるのだが、
>それの回答をXPに求めても、それは無理だろう。
>
>ただし、技術と政治と経済のインタフェースを
>明確にしているのがポイント高い。

それでは
>ストーリーカードを作ること。
>優先順位を決めること。
をウォーターフォール風に最初にまとめてやってもよいの?

>>844
>対話が足りていない→もっと対話しろ→オンサイト顧客
>でいいな。
>
>対話の内容でなく、対話すること自体を大文字で制度化しているのがXP の特徴だろう。

もっと「対話しろ」と呪文を唱えるとすばらしいことが起きるということだね。
ふむ。宗教か魔術だ。



848 :デフォルトの名無しさん:02/06/09 06:30
>>845
>>>837についてだが、
>ほかの方法論でやれるというのなら、それを知りたいと思っているから
>聞いてみただけだ。

キミがウォーターフォールは優先度もつけられない伝言ゲームだと
>>825でいったので、俺はキミがXPはその点まだましだといってる
のかと思っていたのだが。

それに対して俺はXPだと開発者側で伝言ゲームが減ったとしても、
その分顧客側で伝言ゲームが増えるだろうから、全体としては
同じだろうといってる。

つまり伝言ゲームは必要不可避といってる。エンドユーザーが
実際にやっている細かな業務の知識(これにはエンドユーザー
側でさえマニュアル化されていないものも含む)と、プログラミング
の知識を一つにまとめるのがソフト開発なのだから、非常に複雑かつ
広範囲な知識&それを処理する人数がいるのは自明だ。


849 :デフォルトの名無しさん:02/06/09 06:36
もう一つ。俺が顧客なら、自分(顧客)が開発者に代わって要求分析を
行うのであれば、当然その分発注金額を減らすと思う。いままでそれを
開発者が行っていたし、その分の料金が含まれていたと解釈するのが
妥当と思うから。それは正しいと考えていいんだよね。

850 :デフォルトの名無しさん:02/06/09 06:39
>>822
あんた、相手が分かってるもんだと思って話してるうちにどんどん突っ走ったり、相手の話もよく聞かずに決め付ける傾向あるだろ。
その前のやり取りがあったとは言え、「物理」と「理科」で分かるか。「工学概論」と「図工」なら分かるが。
それにしても、いつの間にか「大学生」と「小学生」というメタファにすりかわってるな。

誤解・曲解のおそれのあるメタファは生産性を下げる可能性がある、ってことか。
それにしても「小鳥」とか「脳みそ」とか言われて、感情的な拒絶反応と捉えるやつもいるんだな。
いろいろ勉強になったよ(ワラ

851 :デフォルトの名無しさん:02/06/09 06:49
たとえば、資料を整理するときに、何もしないという方法がある。
ただただ、時間順に格納していくだけ。
これが実は、非常に効率的なんだ。
人間というのは、時間の流れと関連づけると、驚くほど記憶している。
また、作業コストがほとんどかからない。

この手法の欠点は、同じ時間を共有していなかった人間には、資料を検索不可能なことだ。
だからといって、この手法が役にたたないと言えるか?
ほとんどの情報処理部の人間が、定年まで勤めるような会社なら、何の問題がある?

852 :デフォルトの名無しさん:02/06/09 06:56
>>850
>誤解・曲解のおそれのあるメタファは生産性を下げる可能性がある、ってことか。
 メタファなんだから誤解・曲解なんて大いにあると思われ。
 ttp://spring.ics.nitech.ac.jp/HCI/lecture/L4/part2/sld011.htm


853 :XP狂信者:02/06/09 07:52
いやいや、話し合おうということが魔術なのだよ。

一般人は、その一言が何を意味しているのかに
あまりにも無頓着すぎるのだ。
だから、それに対して正確なフィードバックを返してあげる必要がある。
それが、対話せよの本質的な意味。

ついでに、超大量のストーリーカードを手に持てば、
沢山の金はらわなきゃならん理由にも納得がいく。
少なくとも、上級管理職に対する説得材料は作れてるわけさ。

実際、ディスカッションすることで、課題、制約条件、優先順位、状況など
さまざまなことに対して注意を向けさせることができるので、
優先順位を決断すること自体、難しくはないはずだ。

マジこれが難しいドキュソユーザ相手なら撤退しろってことやな。
XPの場合はダイレクトコミュニケーションが基本なので、
伝言ゲームはない。

その点は勘違いしないでくれ。
君が何を問題にしているのかがわからないんだが?
ユーザ側の伝言ゲームって何?どういう状況のこと?
そろそろ、コテハンつかってくれよ。対話を望むのならば。




854 :Coffee:02/06/09 09:25
過去レスを眺めていて気付いたんだが、XPって客との対話の必要性を論じていても、
具体的な対話の方法を論じてないのか…。

じゃあ、俺が知ってる効果的方法を書き込んでも良い?
もしかして営業に近い技術はスレ違い?


855 :XP狂信者:02/06/09 11:33
>>854
どうぞ、どうぞ。その手の具体的ノウハウは、個人的スキルに依存する部分があるから、
決まった形式にはこだわってないようだよ。
いくつかのガイドラインは書いてあるけど。
形式よりは思想を伝えることで、各状況に応じた組織を作れるように
書いてあるのがXP本だから。だから思想書、宗教書なわけだ。
対してCMMやISO9000とかは、思想を形式にすることで、
コントロールしようとしているけど、だから魂の部分の共感は
得られない構造。わからなくてもやってる振りができる。

XPはわかってなければ何もできない。まわらない。
まわらないことで、どこに問題が発生しているか発見して
対策をとることができる。
原理原則に戻ることで別の解答を作れる。
XPを絶賛する所以だよ。

いずれにせよ、XPのユーザはかなりきついジョブなので、
XPユーザに対するガイド本はみんな待ち望んでいるところじゃないかな。





856 :デフォルトの名無しさん:02/06/09 12:33
>>850
>あんた、相手が分かってるもんだと思って話してるうちにどんどん突っ走ったり、相手の話もよく聞かずに決め付ける傾向あるだろ。

なに騒いでんの?

>その前のやり取りがあったとは言え、「物理」と「理科」で分かるか。「工学概論」と「図工」なら分かるが。

俺はあんたの考えがわからん。どう違うんだい?(w

>それにしても、いつの間にか「大学生」と「小学生」というメタファにすりかわってるな。

それはキミが過去ログを読まないから。せめてこのスレをあんたが「」をつけた単語で
2,3回サーチすれば少しはわかるんじゃないの。

>誤解・曲解のおそれのあるメタファは生産性を下げる可能性がある、ってことか。
>それにしても「小鳥」とか「脳みそ」とか言われて、感情的な拒絶反応と捉えるやつもいるんだな。
>いろいろ勉強になったよ(ワラ

あのさぁ、そもそも自分から

>>813
>とりあえず死ね。小鳥。脳みそ。

こんな発言しといてまともに相手されると思ってんの?
俺があんたをまともに相手してると思ってんの?

俺は煽りのつもりでレスつけてたんだけどね。
あんたの煽りよりはハイレベルだろ(w
まともに相手してほしけりゃ、出直すことだ。

857 :デフォルトの名無しさん:02/06/09 12:47
>>851
>たとえば、資料を整理するときに、何もしないという方法がある。

あるねー。俺反対派なんだけど。(w

>ただただ、時間順に格納していくだけ。
>これが実は、非常に効率的なんだ。
>人間というのは、時間の流れと関連づけると、驚くほど記憶している。
>また、作業コストがほとんどかからない。

一理あるけど、これは整理自体は人間の頭の中で別な方法で
行われており、現実の資料の整理はそれと関連付けているだけだと思う。

整理の本質は物の整理ではなく、思考の整理であること、そして
物の整理にとらわれて本質的な整理をおろそかにしがちであるということ
に対するアンチテーゼとしては価値がある。

でも、それじゃあ「思考の整理とは?」となるんだけどね。なんかXPと似ている。

>この手法の欠点は、同じ時間を共有していなかった人間には、資料を検索不可能なことだ。
>だからといって、この手法が役にたたないと言えるか?

「整理」の本質がどこにあるかが明らかになるね。すなわち
「整理」するのは「資料」じゃない。頭の中にある情報だということを
いやおうなしに気づかされる。なかなか有益だ。

ただし(頭の中の)整理にはぜんぜん役に立たない。
これもXPと似ているね。

いや、なかなかいい例を出してくれた。超整理法とXPの類似点を考えてみるかな。

>ほとんどの情報処理部の人間が、定年まで勤めるような会社なら、何の問題がある?

まさか定年まで第一線でコーディングするわけじゃないだろうから、
記憶をいつかは新人に引き継がなきゃならない。その引継ぎのときに
役に立つのが「資料」だよね。資料がなかったり、整理されてなければ
その引継ぎ作業の負担が増えるってだけの話と思うが?
ようするにそれが問題だろ。


858 :カイロ:02/06/09 13:01
>>853
>マジこれが難しいドキュソユーザ相手なら撤退しろってことやな。
>XPの場合はダイレクトコミュニケーションが基本なので、
>伝言ゲームはない。

>その点は勘違いしないでくれ。
>君が何を問題にしているのかがわからないんだが?
>ユーザ側の伝言ゲームって何?どういう状況のこと?

何度かいってると思うが、君がいう「伝言ゲーム」は開発者側
にはないってことだよね。顧客側にはある。ユーザーが一人とか
数人のソフトを無意識に想定してない?

ユーザーが数百人いて、使い方や望む機能がまちまちで、
顧客側の担当者がそれをまとめきれなければ、どうするの?
開発者がプログラム作りながら個々のユーザーと話し合うわけ?



859 :デフォルトの名無しさん:02/06/09 13:18
>>858
>ユーザーが数百人いて、使い方や望む機能がまちまちで、
>顧客側の担当者がそれをまとめきれなければ、どうするの?
そんな状態になったらどんな手法でもそのプロジェクトは破綻するんでは(笑)

ともあれ、XPでは顧客は「決定権のある人」を要求している。
その例ではそもそもXPはできないな。

860 :XP狂信者:02/06/09 13:18
>>858
OKそういうものに関して言えば、XPは無力だよ(苦笑)。

ただ、良いソフトウェアをつくるためには、
超ハードユーザの助けが必要だというのが、これまでの知見なのだ。
その人選に問題がある場合は、どの道ソフトウェア開発はうまくいかない。
「万人の意見を聞くのではなく、たった一人の要望を限りなくかなえていく。」
このことが逆説的に万人のためのソフトウェアの作成方法なのだってね。
XPはそういう思想に基づいている。

で、突き放すだけではあれだから、別の方法についても提示しておくよ。
ハーバードプレスの「隠れた人材価値」という本がある。
http://www.amazon.co.jp/exec/obidos/ASIN/4798102245/ref=sr_aps_d_1_1/250-2897484-1399424
リンクうまく行くといいんだけど。

この中で紹介されているのが、SASインスティチュートの例だ。
SASのスタイルはXPではないが、XPと思想が同じものになっている。
人に優しく、ユーザに優しく。サステナブルに開発を継続していく。

ユーザ会などを通じて、どのような機能が必要か常に聞き続ける姿勢を
つらぬいているよ。

あとはオープンソースなら、バグトラッキングシステムを使いながら
Voteを使って優先順位を決めたりしているね。

何でもかんでもXPでってのは無理さ。でも、やり方はあるし、
それとXPを組み合わせるのもそう難しくはない。

がんばっていこうじゃないか。






861 :カイロ:02/06/09 13:43
>>859
>>ユーザーが数百人いて、使い方や望む機能がまちまちで、
>>顧客側の担当者がそれをまとめきれなければ、どうするの?
>
>そんな状態になったらどんな手法でもそのプロジェクトは破綻するんでは(笑)

破綻するプロジェクトってのはだいたいそういうもんだよ。
そうでなきゃウォーターフォールでも破綻しない。

>ともあれ、XPでは顧客は「決定権のある人」を要求している。
>その例ではそもそもXPはできないな。

だからウォーターフォールが破綻するようなプロジェクトはXPでも
破綻する。

>>860
>
>ただ、良いソフトウェアをつくるためには、
>超ハードユーザの助けが必要だというのが、これまでの知見なのだ。
>その人選に問題がある場合は、どの道ソフトウェア開発はうまくいかない。

同上の答えだ。なんとなくキミと俺ではプロジェクトが窮地に立たされる
主原因の想定に違いがあるようだ。

俺は基本的に顧客からの要求仕様の確定にネックがあると思っている。
顧客もSEもこの部分が分析しきれないから、破綻する。

一方キミが想定している破綻の原因はなんだい?顧客側に自分たち
が望むもののとりまとめが出来る人物を想定しているわけだよね。

となると設計や実装の方にネックがあるといってるの?それもあるけれど、
一番の原因は要求仕様のほうだと思うけど。

で、設計能力の未熟さはXPで改善できるが、要求仕様について
XPは開発者側から顧客側に責任を押し出しただけで、全体としては
なにも改善されていないだろう、と俺はいっている。

>で、突き放すだけではあれだから、別の方法についても提示しておくよ。
>ハーバードプレスの「隠れた人材価値」という本がある。
>http://www.amazon.co.jp/exec/obidos/ASIN/4798102245/ref=sr_aps_d_1_1/250-2897484-1399424
>リンクうまく行くといいんだけど。

ふむ。読んでみようかな。

>何でもかんでもXPでってのは無理さ。

俺の言いたいこともまさにそれだ。XPの考えはよいが、XPだけじゃ駄目だ。



862 :デフォルトの名無しさん:02/06/09 13:47
ん?>>861は XPだけですべてが賄えると信じている人を相手として想定してたの?
そんな人いないんでは。
もともとXPは対象を限定してるのに。

863 :カイロ:02/06/09 14:05
>>862
微妙に違うな。
XPだけでは「何も」賄えない、といってるんだよ。

そりゃ誰かに要求仕様をまとめてもらってあとはプログラムを作るだけに
してもらえれば、できるだろうね。けどそれはウォーターフォールでも
おなじなんだよ。



864 :カイロ:02/06/09 14:12
>もともとXPは対象を限定してるのに。

ではXPが対象としているのは、何だい?
それはウォーターフォールでは無理なのかい?

無理じゃないんだよ。XPでうまくいくならウォーターフォールでも
うまくいくんだよ。

XPはただ省エネだってだけだよ。


865 :デフォルトの名無しさん:02/06/09 16:43
>XPはただ省エネだってだけだよ。
それで十分じゃん。

866 :デフォルトの名無しさん:02/06/09 16:49
顧客の要求をそんなに簡単に確定できるのなら、
何でやっても成功するでしょう、それは。

プロジェクトの初期に顧客の要求を大部分捕らえることができる、
などと考えるのは傲慢だと思うんだけど、どうだろう?
ウォーターフォールな人は、自分の馬鹿さ加減を少なく見積もり過ぎてないか?

867 :カイロ:02/06/09 16:55
>>866
それは俺にいってるのか?
相変わらず馬鹿のひとつ覚えだな。
まともにレスつける気にもならん。
相手してほしけりゃもう一度俺の文章読み返せ。

868 :デフォルトの名無しさん:02/06/09 17:01
逃げに必死

869 :カイロ:02/06/09 17:01
少しヒントをやろう。
俺は要求仕様はそんな簡単に確定できない、といってるんだ。
にもかかわらずあんたの文章の出だしがそんなんじゃ、まともにレスする気力がなえるのもわかるだろう。

870 :カイロ:02/06/09 17:05
いまモバイルだから長い文章を書けないが、864がすべて反語表現になっていることさえ読み取れない自分を恥じるように。


871 :デフォルトの名無しさん:02/06/09 17:06
>にもかかわらずあんたの文章の

相手は一人、という事にしたいのですね?:-)

872 :デフォルトの名無しさん:02/06/09 17:07
くだらん。

873 :デフォルトの名無しさん:02/06/09 17:07
>反語表現になっていることさえ読み取れない自分を恥じるように。

ちゃんと自分の表現力の無さには恥じているんだろうな?


874 :デフォルトの名無しさん:02/06/09 17:10
つーことでこてはんはこの辺で止めるよ。
こてはんにすると厨房が群がってきてうざいからな。

わるいね>狂信者

875 :デフォルトの名無しさん:02/06/09 17:11
>>870
顧客相手にもそんな感じなの?

876 :デフォルトの名無しさん:02/06/09 17:15
>>873
そのレベルの煽りなら一人でやっててくれ。
もすこしベルの高い煽りなら、おれも煽りあいは嫌いじゃないから参加するがね。(w

ま、煽るにしても相手の文をちゃんと読むのが基本だけどな。そして論理の上げ足を取るの。


877 :デフォルトの名無しさん:02/06/09 17:16
モバイルで一生懸命書きこんでくれてるんだ…。いい人だなあ。

で、簡単にはできないが、俺のようなかしこい人間が努力すれば
それは可能である、と思っているように見えるが?

878 :デフォルトの名無しさん:02/06/09 17:19
>>875
お、ちょっとだけ煽りのレベルがあがったね(w

これは対厨房モードだよ。まともな議論するなら、なともに対応するが、君のレベルでは無理だろうな。ありがちなことをならべるだけだろ?

879 :デフォルトの名無しさん:02/06/09 17:22
>>877
駅についちゃったじゃねーか。つーことで終わり。
ひとつだけ答えれば、いくら賢くたっていくら努力したって要求仕様は確定しないんだよ。XPの教科書読め。

880 :デフォルトの名無しさん:02/06/09 19:23
862=866=873=875=877
こんな感じかな。809や813や824あたりも同一人物かな。

XPの教科書に書いてあることを丸暗記しているだけのやつ。

深い話になるとXP擁護、XP批判のどっちの立場でもついていけなくなって、なりを潜めて、
自分でも相手になりそうな発言(実は当人の読解力がないだけの誤解なんだけど)にだけレス
つけるやつ。

こういうのがのさばるからXPは宗教だとかいわれるんだろうね。
迷惑な話だ。

881 :デフォルトの名無しさん:02/06/09 19:24
>>854
期待して待ってるんだけど、まだ?

882 :XP狂信者:02/06/09 19:40
一人を相手にすることで万人に売れるのか?

これは実は割合に基本となる考え方なんだ。
やわらない商売の筆頭のCD業界でも
プロデューサーが絶対だ。

一般受けを考えるともう駄目。答えがでない袋小路にはまってしまう。
それならいっそたった一人のためのモノを作ったほうがいい。
似たような人は必ずいて、そしてその人たちに売れるのだから。

昔は、マーケッティングで統計的に処理するのが、はやったようだけどね。

今は、avexの松浦やケミストリの松尾のように、「ユーザ代表」の
ツボにくるものを納得いくまで作る体制で、自分と似た連中に
必ず売り込む体制を作る連中のほうが成果を出している。

売れるソフトウェアを作りたいのなら、
自分が一番ほしいソフトを開発すべきだ。

ここらへんが、オープンソースやシェアウェアと同じ発想だね。
XPは、そういう事実を素直に認めているだけなんだ。


883 :XP信者:02/06/09 20:28
>無理じゃないんだよ。XPでうまくいくならウォーターフォールでも
>うまくいくんだよ。

煽りあいにはしたくないので、それほど拘っているわけじゃないんだけど、
上のは、「XPでうまくいくプロジェクトはウォーターフォールでも必ずうまくいく」
って意味でしょうか?

単純に考えても、ウォータフォールじゃ工程移行コスト・工程戻りコストが大きくて、

・短納期
・開発体制が10人規模
・ビジネス上の理由により、要求仕様が確定しない

っていうようなプロジェクトがうまくいかない気がするんだけど。



884 :カイロ:02/06/09 20:33
>>882
>一般受けを考えるともう駄目。答えがでない袋小路にはまってしまう。
>それならいっそたった一人のためのモノを作ったほうがいい。

これは別に否定するつもりはないけど。

>売れるソフトウェアを作りたいのなら、
>自分が一番ほしいソフトを開発すべきだ。

これもね。

>XPは、そういう事実を素直に認めているだけなんだ。

ここに飛躍がある。別にXPがそれを認めているとか推奨している
事実はないと思うけど。

ま、いわんとすることはわかるよ。
少なくともXPはそういうものと相性は抜群にいいだろう。

となるとXPは受託とかよりは一般向けに販売される商品開発と
相性がいいだろうね。実際XPと呼ぶか否かは別として、規模は
さまざまだけど、それに近い形で開発されてると思う。

けれど受託は、その点、XPに向かないんじゃない?(w
イテレーションをやったところで、最初は造った部分も
少ないから、それに対する仕様変更とかも少ないかもしれない。

けどだんだん作った部分が増えていくが、それに対する仕様変更
の割合は減らない。仕様変更がくるのは新たに作った部分に対して
一定の割合でくるのではなく、そこまでに作った部分に対して一定
の割合でくる。

XPは、設計を先延ばしにして作業を暫時的に行うことで、変更が生じたときに
まだ作っていない部分を作り直す必要がない点を強調する。ウォーターフォール
では極端な話すべてを同時に作り始めるから、変更が生じた場合にすべてが
作り直しになる。この点XPは確かに優れているだろう。

しかし変更の頻度が問題だ。最悪

1回目 モジュール1を修正
2回目 モジュール1と2を修正
3回目 モジュール1と2と3を修正
 :
n回目 モジュール1と2と3と・・nを修正

なんてことになるんじゃないの?(w


885 :カイロ:02/06/09 20:38
すくなくとも顧客側の取りまとめ役が思いっきり馬鹿で近視眼的なしなりお
しか書けないなら、こんな悪夢のような状況になると思うけどね。

そうならないのは、やっぱ全体を見通してモジュール1とかモジュール2を作るからだよね。

つまり全体設計ってのは要るんだよ。XPでも。必要にもかかわらず陰に隠れてしまっている
ところが、むしろ始末が悪い。



886 :カイロ:02/06/09 21:00
>>883
>
>煽りあいにはしたくないので、それほど拘っているわけじゃないんだけど、
>上のは、「XPでうまくいくプロジェクトはウォーターフォールでも必ずうまくいく」
>って意味でしょうか?

いや、それは俺の煽りだよ。あえて飛躍した論法だ。(笑)

>単純に考えても、ウォータフォールじゃ工程移行コスト・工程戻りコストが大きくて、
>
>・短納期
>・開発体制が10人規模

そうだね。普通そういった小規模の開発は教科書どおりのウォーターフォールでは
しない。ウォーターフォールと呼ぶかどうかは別として、各工程の人をダブらせて
(例えば設計した人がコーディングもするとか)、現実的な範囲で運用する。

それをウォーターフォールの変形とするかXPの変形とするかは、さて。

工程の面から見たXPの本質はやっぱり段階的な開発だよね。(工程以外の
面から見たXPの本質はいろいろあるけど、ここでは置いとく。。。と書かないと
また厨房につっこまれてうっとうしいから。)

だから軽量型ウォーターフォールはやっぱりウォーターフォールじゃないかと思う。

この辺は実はどうでもよくて、

>・ビジネス上の理由により、要求仕様が確定しない

ここが焦点だと思う。この場合>>884の末尾のようなことにならないの?ってこと。
軽量型ウォーターフォールだと設計の見直しもコーディングの見直しもわやくちゃ
になっちゃうから、確かによくない。その点XPはこれをちゃんと扱っている。
ただしちゃんとあつかっているのは「開発者の側だけ」。

顧客の側を含めれば、何も変わってないんじゃないの?
だからくりかえし同じだといってるんだよ。

使用が確定しないのは顧客の自業自得だからしったこっちゃない、という
感じではないの?

開発者側が一方的に辛酸をなめるような自体がよいとはいわない。もちろん。
けど顧客のことを考えないなら、おそらく顧客はそんな開発方法を支持しないよね。


887 :XP狂信者:02/06/09 21:15
>>885
別に悪夢でもお金もらえれば全然問題にしない。
そういう割り切った部分はあるよ。

モジュールという言葉を使うとあれだけど、
タスク毎にかなりのクラスに手を入れるのがXPスタイルなので、
そういう状況は、むしろ大歓迎。

その手を入れるチャンスを使って、
トップPGが、大胆なリファクタリングをすることで、
設計品質を一定にするんだ。

XPがいかに優れたプロセスだからといって、
プログラマの無能をカバーはしてくれない。
そのチームの一番優秀なPGの力次第で、
どこまでやれるかは決まってしまうのさ。

経験豊富で優秀なPGを2割は押さえておかないとね。
そいつらが実質的に全体設計するんだよ。

ただ、そいつらが仕事するには、準備が必要で、
そのために、テストケースという形で、どこまでいじっていいのかを、
知らせてあげなくてはならない。

それさえできるなら、ダサイインプリでガリガリする
レベルの低いプログラマがやはり2,3割いても
問題にはならない。

まぁ、OOPを極めた人間を何人抱えているかが問題だな。












888 :XP狂信者:02/06/09 21:34
>一方キミが想定している破綻の原因はなんだい?
これだけど、一言で言えば、報告と事実とのカイリということだな。

プロジェクトの破綻の元の原因はともかくおいておくとすると、全ての罪はこれから始まる。

ウォーターフォールでやった場合の、SAの進捗どう図るんだい?
SDの進捗どう図るんだい?
「ClassXXX 設計進捗40%、まだ不明な点が多い。」

こんな報告に何の意味があるんだい?
XPはここの部分を明らかにしてくれる。それもシンプルで確実な方法で。
ついでに、失敗することを許容してくれている。
これにより、悪い情報を早く取ることが出来て、それに対する対策が取れる。

だからアグレッシブな見積もりもできるし、全力疾走やる気にさせてくれる。

XPマンセーの所以だよ。







889 :XP狂信者:02/06/09 22:17
http://www.tech-arts.co.jp/xp/OneTeamJ.pdf

最近のBeckのユーザに対する考え方は上のとおり。
XPも色々変わっていくんだよね(^^)。


890 :カイロ:02/06/09 22:28
>>887
>>>885
>別に悪夢でもお金もらえれば全然問題にしない。
>そういう割り切った部分はあるよ。

うーん。既存のプロジェクトでもデスマーチになる原因の
多くはこれだと思うんだけどね。で、問題は3つ。

 1)XPにしたからといって現実に金はおそらく取れない。
 2)XPにしたからといって、顧客らか見てスケジュールが遅れれば、さまざまな圧力はあるだろう。
 3)金とは関係なしにPGの士気が下がる。

仮に俺が顧客側だとして、1)と2)は認めがたい。というか
そこを譲歩して得られるメリットがよくわからない。

>モジュールという言葉を使うとあれだけど、
>タスク毎にかなりのクラスに手を入れるのがXPスタイルなので、
>そういう状況は、むしろ大歓迎。
>
>その手を入れるチャンスを使って、
>トップPGが、大胆なリファクタリングをすることで、
>設計品質を一定にするんだ。

>XPがいかに優れたプロセスだからといって、
>プログラマの無能をカバーはしてくれない。
>そのチームの一番優秀なPGの力次第で、
>どこまでやれるかは決まってしまうのさ。


うん。よいね。この辺は実にいいと思う。
プログラミング面ではXPに文句はないよ。

>経験豊富で優秀なPGを2割は押さえておかないとね。
>そいつらが実質的に全体設計するんだよ。

>それさえできるなら、ダサイインプリでガリガリする
>レベルの低いプログラマがやはり2,3割いても
>問題にはならない。

なるほど。それはそんな感じかもしれないね。



891 :XP信者:02/06/09 22:49
>>886

>顧客の側を含めれば、何も変わってないんじゃないの?
>だからくりかえし同じだといってるんだよ。
>
>使用が確定しないのは顧客の自業自得だからしったこっちゃない、という
>感じではないの?

XPの思想としては、そういうわけではないと思います。

仕様が確定しないのも、変更されるのも、顧客のビジネス上の都合であるのは
許容していて、その上で、

・最初に言っておいてくれないからいまさら対応できない
・いまから変更するのは莫大な工数が必要になる
・最初にFixした仕様にサインがあるから最初のとおりに作る

っていう状況を発生させないことを目指している。

それにしたって、仕様の変更も追加もコストはかかるので、
どちらを選ぶにしても、いつでも顧客が適切な負担で選択できるように
オプションを提示しよう、提示できるようにしよう、っていうのがXPの思想
であると思う。

で、そのオプションを提示できるようにしているプラクティスが
・リファクタリング
・ユニットテスト
・スモールリリース
であると考えています。




892 :カイロ:02/06/09 22:52
>>888
>これだけど、一言で言えば、報告と事実とのカイリということだな。
>ウォーターフォールでやった場合の、SAの進捗どう図るんだい?
>SDの進捗どう図るんだい?
>「ClassXXX 設計進捗40%、まだ不明な点が多い。」
>
>こんな報告に何の意味があるんだい?

なかなか鋭いとこ突いてくるね・・・

つーとXPだと進捗管理がより正確にできる、ということでOK?
それには同意してもいいよ。

ただし分子(やったこと)ははっきりわかるけど、分母(やらなきゃならないこと)は
未定なんだから、進捗率は出せないだろうけどね。

XPでなくても、やったことは嬉々として答えてくれるよ。残件を聞くと表情が曇るけど。
ま、やったことが実際のプログラムやテストで確認される利点は、確かにある。
反面、設計で試行錯誤することになった場合、後の工程もそのまま振り回される。
その点は「本来の」ウォーターフォールもXPも変わらん。それがいやで、すでに
作成済みの部分をなるべく生かそうと適当にごまかすから現実のウォーター
フォールはぐちゃぐちゃになる。

でもXPでも同じことがおきないのかなぁ。だってやっぱりせっかくコーディングして
テストしたのに作り直しなんていやじゃん。って考える人は多いと思うけどね。



893 :XP狂信者:02/06/10 00:14
分母は明らかだよ。
チームレベルなら、
アクセプタンステストの項目数が分母。分子は通った数だな。

個人レベルでの責任範囲はタスクだから、
イテレーションスタート時にサインアップしたタスク数が分母で、
分子は完了数だ。

君が問題にしているのは、XPに対する問題じゃなくて、
スパイラル形式、イテレーション形式一般に対する問題のようだ。



894 :デフォルトの名無しさん:02/06/10 00:33
そういや XP の場合、
分析・設計=ストーリー・タスク作成にどれくらいかかるかは見積もるの?

895 :カイロ:02/06/10 01:07
>>893
>君が問題にしているのは、XPに対する問題じゃなくて、
>スパイラル形式、イテレーション形式一般に対する問題のようだ。

確かにそうだね。

正直、自分が顧客側のプロジェクト責任者だったら、XPを提案してきた
会社に発注するか、悩む。

例えば>>461であげられているようなプロジェクトの責任者になったと
して、俺はXP方式を提案する会社に怖くて発注できない。

俺なら、まず社内の業務形態を徹底的に分析しなおす。かなりの
リソースをかけて。その後必須の機能をウォーターフォールで作ら
せる。そして実運用開始。足りない機能は人間系が補う。
次の段階で再度必要と思われる機能を分析。同様にウォーター
フォールで作らせる。

こんな具合が俺のやり方だ。これをXPでやるとどうなる?
最初の分析&概略設計にどれくらいの時間をかけるかが知りたい。

多分俺なら全体の1/4〜1/3ぐらいの工数が、(2回の分析それぞれで)
必要と思う。


896 :デフォルトの名無しさん:02/06/10 03:28
>>889
XP自身も「変化を抱擁」の対象なんだね。
確かに、XPのプラクティスはあくまでもKent Beckたちが実践してきた中で遭遇した問題に対応して
修正し、リファクタリングしてきたものなんだな。
ということは、導入するときもKentたちの対象と完全に一致するものでない限りボロは出るし、
金科玉条のように各プラクティスに従うのではなく、修正して今後に反映していかないといけないんだ。

897 :デフォルトの名無しさん:02/06/10 10:36
>>896
XP 自体をリファクタリングするという考えには禿しく胴衣!!!!

898 :デフォルトの名無しさん:02/06/10 11:21
お邪魔します。

顧客側の要求定義をどうやってまとめるか?
どうやって設計作業の中に取り込むか?
を議論しているように見えたので一言。

ウォーターフォールでは、設計を開始する前に要求定義を完全に終了させようと
している。漏れた仕様は仕様変更でフォローする。

XPでは、要求定義、設計、実装、テストを含めて、イテレーションという
ループ作業の中に入れようとしている。

ウォーターフォールは、設計以前に完璧な要求定義を必要とし、
XPは、完璧な要求定義を持った顧客がイテレーションの中に入ることを
必要としている。

どちらも完璧な要求定義は必要であるが、その時期、タイミング、設計や実装に
与える影響などが違うと思う。

899 :898:02/06/10 11:25
>>898に追加です。

ウォーターフォールとXPの大きな違いは、設計者と顧客との距離なんだと
思います。

900 :デフォルトの名無しさん:02/06/10 12:24
|・ユーザの役割:大部分はプログラマの視点からXPについて述べた。
|(「簡単なストーリーが多く必要だ」「すべての質問に答える」
|「修了したことがわかるように多くのテストが必要だ」など)。
|ソフトウェアのユーザになることは難しい。
|このテーマに関してはもっと多くのアイデアが登場するだろう。
XP アドベンチャー pp.140

決定解はまだ持っていないということだね。
XP 本を読んだ限りでは、
日常的にさまざまなソフトウェアを使いこなしていて、
こういうソフトウェアを作りたいとビジョンが
抽象的ではなく実際のソフトウェアの形で想像でき、
できればプログラミングの経験もあるユーザが
適していると思った。

901 :デフォルトの名無しさん:02/06/10 12:33
>>897
XPをリファクタリングしたらウォーターフォールになっちゃいました。(w

>>889のリンク先見れば、アナリストはあるはQAはあるは、マネージャーはあるは。




902 :デフォルトの名無しさん:02/06/10 12:37
>>898-899
そりゃそーだが、で、何が言いたいの?



903 :デフォルトの名無しさん:02/06/10 12:41
>>900
> 日常的にさまざまなソフトウェアを使いこなしていて、
> こういうソフトウェアを作りたいとビジョンが
> 抽象的ではなく実際のソフトウェアの形で想像でき、
> できればプログラミングの経験もあるユーザが
> 適していると思った。

適しているどころか、そうでないユーザーはXPの「ユーザー」には
なれない。だって「ユーザー」が要求仕様を決定するんだぜ?
最低SE並みの分析能力は必要だよ。

904 :デフォルトの名無しさん:02/06/10 13:00
>>889のpdfを要約しとこう。反XPのバイアスをたっぷりかけて。

「XP エクストリーム・プログラミング入門」における最大の過失は、1 人のユーザだけ
を相手にしている」と想定していたことである。

モデラやテスタのスキル及び存在がチームにとってどれくらい大きな資産になるか
ということは充分わかっている。しかしXP のイメージが「プログラマチームの周囲を
旋回する1 人のユーザ」である限り、彼らの居場所は「どこにもない」ということになる。
彼らが正しいとすれば、私の持つXP のイメージが間違っているということだ。

では、テスタやモデラはどこに当てはめられるか? ビジネスチームである。リリー
スされるソフトウェアの範囲と品質によって活動に影響を受ける人々が、全員
で情報収集、記述、検証など、とにかく何でもサポートするのである。
・アナリスト
・ユーザ代表
・テスタ
・マーケティング担当者
・ユーザサポート
・営業
・モデラ
・実際のユーザが行うことを観察し「道の舗装」の手助けをするインタフェ
ース設計者
・ビジネス戦略担当者



905 :XP狂信者:02/06/10 20:45
次スレ用意した
がんがん行こうぜー。

http://pc.2ch.net/test/read.cgi/tech/1023709462/


906 :デフォルトの名無しさん:02/07/08 04:25
ホシュ

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

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)