eXtreme Programming Part.2

ドキュメント作成よりもコミュニケーションやテスティングを重視する
ライトウェイトな開発手法「XP」について語りましょう。

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

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

今だ！２ｹﾞｯﾄｵｫｫｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;

今だ！3ｹﾞｯﾄｵｫｫｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;

for (i = 3; i < 1000; n++) {
　printf("

今だ！%dｹﾞｯﾄｵｫｫｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
", i + 1);

}

>>4 数秒で1スレ埋まるな…。

改行せんでｴｴの?（ｗ

>>4
n++って･･･無限ﾙｰﾌﾟ

永遠に4ゲットを続けるコードか

永遠ループ・・・
（でも1001で例外が飛んでくる罠）

>>4-9
ﾜﾗﾀ

>4-9
なるほど、これがﾍﾟｱﾌﾟﾛか...

>>11
言われてみればこれはいい例だ。

printf("aaaaaaaaaaaaaaa
　　　　　　　bbbbbbbbbbbbbbbbbbbb");
こういう書き方って許されるの？
printf("aaaaaaaaaaaaaaaa"
　　　　　　　"bbbbbbbbbbbbbbbbb");
ならわかるけど。

>>13
細かいとこに突っ込んじゃダメれす。
4は言語指定してませんし。

確かにこりゃホノボノするな。うちもXPやろっかな...

XPを導入してる人に質問。
イテレーションと検収条件はどのように関連付けてますか？
また、分割検収には成功してますか？

最初
　今だ！nｹﾞｯﾄｵｫｫｫｫ
とした。nならfor文もnにしとこうかな…
やっぱ%dにしよう。ついでに変数もnはやめて、iに。
で、n++だけ直し忘れた。もう生きてはいけません。氏にます。

>>17

UnitTestは、しましたか？

test first

今回のケースだと、どんなtest関数書けばいいの？

>>20

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

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

　俺なら。

ケント・ベックって絶対にSIでの開発を経験したことがないとおもわれ。

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

　　　　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿
　　　 ∧,,∧ 　　　／80%程度の作業が無意味なSIでの開発経験など
　 _　ミ,,ﾟДﾟ彡_＜　　経験すればするほどバカになるけどね。
.=| |＝U＝U=| |= ＼＿＿＿＿＿＿＿＿＿＿＿
　| | .ﾐ　 　ﾐ　| |
　| |ﾉ∪''∪.　| | 俺が孫請けって廃ってた
　| |　　　　　 | | 東京階乗、住友階乗のシスの開発経験は
　　　　　　　　　やらなきゃよかったです。
　　　世の中こんなクズ開発でやっていて
　　　うまくいってるんだなという社会勉強にはなりますた。

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

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

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

>>24
（´-`）。o ○ （・・・・・）
関連書籍嫁。

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

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

>>26
蟲シレ

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

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

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

　　　　　 ∧,,∧　　　　／￣￣￣￣￣￣￣
　　　　　ミ　　 彡　 ＜　ユニットテストと受け入れテストが
　　　　　(ﾐ 　　ﾐ)　 　　＼＿＿＿＿＿＿＿
　　　　　 ﾐ 　　ﾐ　
　　　　　 ∪ ∪






　　　　　 ∧,,∧　ｻｯ　 ／￣￣￣￣￣￣￣
　　　　　ミ,,ﾟДﾟﾐ　　＜　混ぜこぜになっていませんか
　　　　⊂ 　 @m　　　＼＿＿＿＿＿＿＿
　　　　　ミ､,, ﾐ,
　　　　　 .しヾJ

ピンク本の182Pを見るといいかもね
TestFirstはﾕﾆｯﾄテスト

>>26

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

タコ部屋みたいなとこに入れられてXPさせられてみたいものだ

>>30
やっぱり異性が(･∀･)ｲｲ!!ね。
でもこのところXPに勢いを感じられない・・
やはり適用事例があまり大規模はないのだろうか。
（考え方を浸透させると言う観点から大規模に適用は厳しいのかも。）

12畳くらいの部屋にメガネデブオタが8人でXP

>>31
4人〜12人が適度な規模と聞いたことあるが。

>>32
そらキツイ（藁

俺以外はメガネっ娘でXPならサイコーだな

>>29
はぁ？

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

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

メガネっ娘がＸ人なら、（Ｘ＋１）Ｐですか？

顧客の言う事はじから聞いてったら、キメラが出来あがる場合も多いぞ…

ＸＰライクにやってると、

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

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

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

>>36
> はぁ？
> ＞もちろん、できること、できないことがあります
> これをあたりまえのことだといったんだが、何かご意見でも？
最初から、そこだけ引用するとか、強調するとかしてれば、よかったんじゃないの？
書き方が悪いよ、あんた。

>>39
コーディングで全てが済むならいいではないか

>>37 うまいこと言うね

>>27
>どーしてもコーディング中心になってしまう。今まで大体
>設計：コーディング：テスト ＝ ２：３：１で見てたから
>コーディングとテストとおなじくらい稼動がかかってかなり工数が
>増える。見た目上。

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

>>27
その比率、ﾃﾞｽﾏｰﾁを呼びそう。

>>29

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

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

ってだけのことだ。

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

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

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

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

　　　　　 ∧,,∧　ｻｯ　 ／￣￣￣￣￣￣￣
　　　　　ミ,,ﾟДﾟﾐ　　＜　シャベリ場？
　　　　⊂ 　 Ｏm　　　＼＿＿＿＿＿＿＿
　　　　　ミ､,, ﾐ,
　　　　　 .しヾJ　　

　　／⌒ヽ
　/　　●　 ヽ
（●／⌒ヽ●） ／￣￣￣￣￣
　ヽ| ´∀｀ |ノ＜　しゃぶり場。
　　.ゝ＿__ﾉ 　　＼＿＿＿＿＿

>>44
えぇ、呼ばれまくりです。全稼動の1/3くらいテストにまわしたいですが。

ｳﾆｯﾄﾃｽﾂとｳｻﾞｰﾃｽﾂごちゃ混ぜに書いてしまいましたが
Design：Coding：Unittest：Usertest=2:3:2:2な感じになりますた。

実感としてBug曲線が変わった気が致しませぬ。
ﾋﾟﾝｻﾛでも読もう・・・

XPとデスマーチ......となりあわせなのかもねー。
ぴょーこたん

>>36

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

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

って意見ですが。

>>45

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

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

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

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

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

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

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

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

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

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

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

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

　＿＿＿＿＿＿＿_
　|　52ﾀﾝが　　　　　|
　|いい事言っている|
　|気がしますた。　 |
　|＿＿＿＿＿＿＿|
　　　　　　||∧,,∧
　　　　　　||,ﾟДﾟ,,;彡
　　　　　　||⊂　~ヽ

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

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

うちらの仕事ってサービス業らしいよ、とか言ってみるテスト。

つーとあんたのところは何も納品しないのか？といってみるテスト

>>55
論理の飛躍

>>56
どこがだ？サービス業ってのを履き違えてないか？

あとつけくわえるが、サービス業であったとしても等価交換には
わかりないわけだ。そもそもキミは、（自分なりに）物事を考えたうえで人の意見を飛躍とかいっているのか？

>>55 >>58
＞つーとあんたのところは何も納品しないのか？といってみるテスト

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

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

>>55-59
ﾌﾟ)

矛盾してると見えるのはあんたがサービスをその場その場で都合がいい意味で使うからだろ。
客が何にたいして金を払ってるのかといえば、[サービス]であって[満足]に対してではない。

>>59
こんど見積もりにサービス料も加えたらどうだ（ｗ

(･∀･)!!ｽﾏｲﾙ は０円 です (･∀･)!!

客に向かっては吐けない大口を叩くスレはここですか？

ﾁﾐは卑屈に媚を売ってんだろうな

>>64
大口？そのとらえ方がそもそもおかしい。凡庸な人間だねあんたは。

>>52

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

＞これが、当たり前なんだろうか？

　おれは、そう思う。

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

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

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

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

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

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

＞ 顧客を満足させなければならないのは、競争が働いているためだし。

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

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

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

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

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

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

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

↑のﾊﾏｲﾀﾝｦﾁ から派生したやりとり見てて、ﾎﾟｶｰﾝ なんですけど、
それは、俺がしょぼいから、ついていけてないだけですか？

ついていかなくていいんじゃない？どのみち（俺は）たいした話をしてないから。
俺が言いたいのはこーゆー話にしかならないから、濱井はこの手のXPMLで
発言するなってことだ。

この手のXPMLで → この手の話をXPMLで

俺が言いたいのはこーゆー話にしかならないから、>>70（とか） はこの手の話をこのスレで発言するなってことだ。

>>72
だったら無視すればいいんじゃなの？（ｗ

こう、、、スレ奉行が多いね、ここ。

Aに対するメタ議論はAダッシュで、ってことだな。

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

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

71じゃなくて72だったーよ。すまそ。

以下、引用。

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

そんなあのコもXP

>>77
それを濱井にいってやれ。

ちなみに満足の得られないサービスってﾅﾆ？

>>70

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

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

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

＞＞ 顧客を満足させなければならないのは、競争が働いているためだし。

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

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

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

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

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

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

＞一生懸命やっているのは伝わるんだから、大目に見てやれってことだ。

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

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

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

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

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

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

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

＞私が書いたのは、記事の批判というよりもウォーターフォール一般への批判
＞になります。
＞納期が長かろうと短かろうと、ウォーターフォール型の開発では仕様をある
＞時点で固定してそれ以降の要求の追加、変更は拒否することになります。
＞仕様通りに開発されても、必須の機能が抜けていて顧客にとっては開発の意味
＞が無いというようなケースが起こり得ます。
＞
＞必要な機能を要求し損ねた顧客の責任だというような考え方もできますが、
＞コミュニケーションの失敗はほとんどの場合双方にそれなりの原因がある
＞ことを考えると、顧客だけが責任を負うというのは不公平でしょう。また、
＞ビジネス的にもまずいやり方です。
＞# 現実には、顧客は仕様の全責任を負うほど弱い立場ではありませんが……。
＞
＞仕様通りに開発するという観点からは、仕様の固定は早ければ早いほど良い
＞でしょうが、顧客の満足を高めるという観点からは、仕様の固定は遅ければ
＞遅いほど良いことになります。
＞イテレーション型ならウォーターフォール型の失敗が完全に防げるというわけ
＞ではありませんが、その確率は下げることができます。
＞
＞ウォーターフォール型の開発が生き延びてきたのは、顧客の満足を高めること
＞より、仕様通りに開発することが重視されてきたことに一因があるように
＞思えます。

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

固定概念に凝り固まってるのは濱井の方。
ガキ並みの幼稚さと老人並みの頭の硬さ。
会社でもウザがられてるんだろうなぁ。

濱井タンにとって批判とは同じ事を連呼することなんだろうか…

＞　濱井さんはビジネス的視点からウォーターフォール型プロセスを批判なさっていま
＞すが，ソフトウェアの不具合に対する法的責任という観点からはどうでしょうか。

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

XPとウォーターフォールって社会主義と資本主義みたい。

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

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

＞ウォーターフォール型の開発が生き延びてきたのは
クライアントと営業が「じゃ、今回はウォーターフォールで行きますから、よろしく」
って握手してるの想像しちゃったよ。
ウォーターフォールって、結果、だよね？
そういうのが、生き延びてるって言うのかなぁ…

ＸＰだと顧客が近くにいる、イテレーションが短い、
ユーザストーリーに書いてあることしか実装しない、などの理由で
あまり仕様のミスマッチは起きないんだと思う。

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

煽りじゃなくて純粋に質問なんだけど、

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

識者の意見希望。

＞固定概念に凝り固まってるのは濱井の方。

確かに。

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

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

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

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

最近思ったんだがデスマーチを発生させるのはプロセスではなく人だな。

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

＞も負わないことを謳っています。法的にはこのような契約でもできるという

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

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

＞最近思ったんだがデスマーチを発生させるのはプロセスではなく人だな。

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

　対策：精神を鍛錬する、とか（ｗ

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

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

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

>>98
＞ちと違うな。ちゃんと見積もりをするようになるプロセスだ。

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

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

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

＞人は育つ土壌が無いと育たないよ。
＞その土壌を意識的に作っていこうというのが XP だと思う。

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

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

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

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

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

＞自分の作業量
自分の作業能力

やはり経験第一だな。

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

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

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

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

＞見積もりはプロセスでなく経験が多くを占めるような気がする。

そうだね。

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

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

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

>>105
＞・なぜ、XPでは大規模なプロジェクトを運営する人を育てられないのか？

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

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

この辺をどうする？

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

という理解でいいかな？

>>106
> ？？？「次回の見積もりを行いやすくするもの」なら「プロセスを改善しても
> 見積もりを正確に行えるようには思わない」というのは？だが。
変ですね。訂正します。
　・見積もりを正確に行うためにはプロセスの改善を行うよりも
　　人の改善（経験を積む）を行うことが効果的
ではどうでしょう？

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

＞大規模になると「ソフトウェア→シナリオ．．．ではなく」
＞「システム→サブシステム→ソフトウェア→シナリオ．．．」となり
＞「システム→サブシステム→」の設計作業の経験ができない。
＞
＞という理解でいいかな？

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

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

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

　ソフトウェア
　プロセス
　人

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

現場レベルでプロセスについての議論ができるようになってきた
というのは XP の効果の一つじゃないかな。

そうだね。だからよけい安直なXPマンセーやろうが失敗して、
あーやっぱりこいつらにもの考えさせるとろくなことになんねー
ってことにならないように願ってる。

∧,,∧
ミ,,ﾟДﾟ彡

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

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

　　∧,,∧,,,,,,,,,,,,,,, 　　　　　／￣
　ミﾟДﾟ,,彡,,,,,,,,,,,,ヾ〜　 ＜ まちがっちゃったか…
　　　U U """"UU　　 　　＼＿
さっさと逃げ　ﾄｺﾄｺﾄｺﾄｺ

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

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

> うーん、積極的な工夫．．．難しい
> # まぁ、俺が簡単に工夫できるような代物だったら他のもっと優秀な人が
> # とっくに思いついてるな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＞第一つまらない。

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

>>100

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

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

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

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

＞でもさ、濱井氏のメールは良くも悪くもXPMLへのネタを提供して
＞くれているし、濱井氏がメーらなければ今よりマシになるかといえば
＞疑問だし。

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

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

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

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

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

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

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

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

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

漏れは29が屁理屈並べて濱井ﾀﾝを持ち上げる動機の方が知りたい。
まさか濱井ﾀﾝにならって人の神経逆なですることがスレの活性化につながるなんて
思ってないよね？

＞漏れは29が屁理屈並べて濱井ﾀﾝを持ち上げる動機の方が知りたい。

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

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

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

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

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

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

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

>>125

あなたは誰ですか？

>>126
> あなたは誰ですか？

誰ではありません。

>>126

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

>>128より>>127の方が本物っぽい。

変なもん召喚しやがって・・・
責任取れよ＞29

おれも29がなんでここまで濱井を擁護するのか不思議だね。
割り込んですまんが、

＞＞XPMLでもまともなスレが濱井がレスすると、その後はくだらん
＞＞レスしかつかなくなる。
＞
＞　そうそう、それはくだらんレスを書く奴が悪いんだろ？

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

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

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

>>127
そのレス気に入った。今度使わせてもらうよ。

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

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

＞漏れは29が屁理屈並べて濱井ﾀﾝを持ち上げる動機の方が知りたい。

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

HAMAIあげ

＞＞＞XPMLでもまともなスレが濱井がレスすると、その後はくだらん
＞＞＞レスしかつかなくなる。
＞＞
＞＞　そうそう、それはくだらんレスを書く奴が悪いんだろ？
＞
＞濱井のレスがそもそも下らんのだ。

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

つーか29はXPMLをまともに読んでないだろう？

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

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

procimprovMLなんか閑古鳥だけど。

>>136

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

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

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

>>138

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

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

>もしそうなら読まなきゃいいだけだし・・・。

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

　　∧,,∧
((ﾐﾐﾟДﾟ；ﾐﾐ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

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

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

>>141
＞あの人にも[読まなきゃいいだけ攻撃]が

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

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

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

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

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

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

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

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

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

どっち？

29 vs その他 は 濱井 vs その他 の図式とそっくりだな。29と濱井が両方とも
屁理屈っぽいとこまで。そんなに気が合うなら29が濱井の相手してやれよ。

(´-`).｡ｏＯ（XPML並につまんないスレだ…）

もしかして29は濱井の兄では？

濱井タンの家族はみんなあんなんなんですかﾊｧﾊｧ

濱井の｛母,主治医,家臣,...,飼い主｝です。この度は以下略です。

29って誰よ？説明きぼーん

＞大目に見るのは勝手だけど、腹を立てる人間もいるという認識はないの？

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

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

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

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

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

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

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

>>150

　おれもー。

＞＞「健全なスレの流れってどんなの？」ってところです。
＞それをあなたに説明する気はないね。そんなもの簡単に
＞説明できるものではないことをわかってて聞くわけだろうし。

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

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

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

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

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

＞腹を立ててない人間にとっては、濱井氏の投稿は役にたっていると思っている。
＞
＞　現にレスをつけている人間はいるわけだし。（まさか、自作自演？）
＞
＞　腹を立てる人間を優先したら、誰も発言は出来ないと思いませんか？
＞どっち？

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

HAMAIあげ

延々と激しくスレ違いの実感

Martin「激しく不吉な匂いのするスレだな」
Beck「禿同。リファクタリングが必要だね」

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

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

＞＞　腹を立てるのに正しいも正しくないもないでしょう？主観なんだし。
＞「嫌がる理由がわからない」と聞いてきたのはそっちだろ。説明するために、何が
＞わからないか聞き返しているのに、主観なんだから正しいも正しくないも
＞ない、とはなんなわけ？

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

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

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

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

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

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

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

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

＞閑古鳥の方がまだましだな。

　やっぱり、そうなの？

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

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

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

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

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

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


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

>>161
やっとｍｌ読んだの？ｗ

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

＞＞＞　腹を立てるのに正しいも正しくないもないでしょう？主観なんだし。
＞＞「嫌がる理由がわからない」と聞いてきたのはそっちだろ。説明するために、何が
＞＞わからないか聞き返しているのに、主観なんだから正しいも正しくないも
＞＞ない、とはなんなわけ？
＞
＞　正しいか正しくないかには拘ってないって意味です。
＞　「腹を立てるのは間違っている！！」って言っても仕方ないと思うし。

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


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

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

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

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

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

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

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

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

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

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

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

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

＞俺はそんな風に思えるので罵詈雑言誹謗中傷しますです。
＞だからと言って、そんな風に思えない君にとやかく言ったりはしない。
＞わかった？
＞
＞これは主観だが、言葉遊びしてるだけで本質から離れていってるような感があるなあ。
＞彼よりタチ悪い。

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

age

暇つぶしの場に決まってるじゃねーか（ﾜﾗ

＞[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] 仕様変更に打ち勝つ
ですでに指摘されているように、元の記事の内容と濱井の発言内容の
主旨はマッチしない。

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

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

濱井 をNGワードにしますた。

濱井ﾀﾝも29も軍事板の某研を見習えばいいのにね。
どんな話題でもレールガンネタに持っていくのに住人からは愛されてるよ。

浜井氏ねage

ML の話はどうでもいい。
無駄な議論をしている点であんたらが濱井とどう違うのかわからん。
このスレでも逝ってくれ。

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

>>172

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

はまいﾀﾝうおっちスレ立てようか(w

はまいﾀﾝがうざい理由は168の最後の記述がもっとも的を射ていると思う。
はまいﾀﾝの行為は荒らしと同じだからやめてほしい。

ガイシュツだが29はｍｌを読まずに発言してるに256void。

　　　　　ｵｰｼ　　　＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 ∧,,∧∩　　／
　　ミ,,ﾟДﾟ彡　＜　XPMLをヲｯチするぞ！
　　 U　　ミ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　〜ﾐ　　ﾐ
　　 ∪''∪　胸がﾑｶﾑｶﾑﾈﾑﾈしませんように。

>>168さんのｶｷｺは
とても、鋭い分析ですね。

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

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

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

＞あのさ、それなら最初から発言しないでくれないかな。
＞
＞　　１．まず、あんたは濱井に対して腹を立ててる人間がいるということは
＞　　わかっているという。
＞
＞　　２．ところが腹を立ててる人間にたいして、それは間違っている（正しくない）
＞　　のではないか、と議論することは放棄している。
＞
＞　　３．意見の相違をそのままにして双方が共存できる（幸せになれる）
＞　　方法の模索はスレ違い（だからここではやらないほうがいい）

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

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

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

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

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

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

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

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

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

　わかりました。

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

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

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

>>152
だったら自分で名乗りなよ。
俺があんたの名前をばらすのはフェアじゃないから、俺はだまってるが。ばらしたとこで、とくに意味ないし。

>>178

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

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

スレ名見て流し読みしたが、損した。

>>182

そうですね。消えます。

>>184
で、あんたんは何のためにこれだけ書き込んだんだ？
かき回すだけかき回して、何か得るものがあったのか？
口をはさんできてかき回し、これ以上議論する気はないと一方的に宣言して去っていくのが、あんたのルールなのか？

ふざけんじゃねーよ

>>185
やめとけ。
また出てこられても困る。

>>178
＞　まあ、もともとは>>29で書いているように、当たり前のことをMLに書くと
＞何故嫌われるのか疑問だったからなんだけど、

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

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

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

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

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

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

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

＞　とりあえず、濱井氏に関してはこれ以上はないです。
＞　疑問もだいたい解けたし。
＞
＞１〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
＞するが、どうなん？

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

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

＞　　２．ところが腹を立ててる人間にたいして、それは間違っている（正しくない）
＞　　のではないか、と議論することは放棄している。

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

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

＞そこに拘りがあるんでしょうね。

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

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

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

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

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

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

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

fjってこれのことか？こいつが29かどうかは知らないけど。なんとなく書き方が似てはいる。
ttp://blade.nagaokaut.ac.jp/~poffice/news2/fj.comp.oops/134

またえらく古いものを掘り出してきたね。

190=29?

>>189
違うとおもいますよ．
彼は，段落の先頭に空白でインデントしないもの．

ふむ。それに暴いたところで意味ないし。

影でうざいとか言ってないで、ＭＬで指摘すれば？

んなことしたら荒れるだろ

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

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

>>196

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

>>192
そんなこというから、ログから空白でインデントしてるメールを探しちゃったじゃないか（笑

＞１〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
＞するが、どうなん？
＞
＞　とりあえず、濱井氏に関してはこれ以上はないです。
＞　疑問もだいたい解けたし。
＞
＞１〜3やそれ以外でも何か議論する気があるなら、俺もまじめに相手
＞するが、どうなん？

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

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

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

前スレ949の発言は

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

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

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

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

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

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

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

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

こういう組み合わせの場合、ペアプログラミングは破錠します、という見本。

あ、でもいまきがついたんだけど前スレの940はスペースがないね。
940 != 29なのかなぁ。それとも29はスペースつけたりつけなかったり
するのかなぁ。

>>201
え？それ何？ネタにしても面白そう。もっと説明きぼん。

＞実は，俺の上司がそうなんだ。とっても賢い人なんだけどそうは
＞見せないないんだよね。ゆとりがあるというか。

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

いったいぜんたい、重箱の隅をつついたり、言葉遊びのような議論をする
濱井のどこに余裕があるんだか（爆笑）

>>203
一人があばたもえくぼなほどもう一人にほれ込んでりゃ、ペアプロが機能しないって
ことでは。

もしや…濱井タンが50歳過ぎで29の上司では…

29の上司です。あげ

漏れも29は長谷川さんだと思うけど。

>>209
文体が明らかに違うし，彼はもう少し抽象的な話をするとおもうけど．
想像で実名を出すのはどうかな．

俺は最近XPMLに入った人で自己紹介している人が先頭にスペースがあって
疑わしいと思うけど

>>210
同意。意味ないよ。俺はもう少し29と話がしたかったが、これじゃあもう出てこないね…

XPのスレではなくXPMLのスレでござったか。所詮XPなんてこの程度？

>>213
違う、違う。
XP自体じゃなくってXPに興味有る人間だって。＜この程度

ふむ。29よりはまだ前スレの940の方が彼らしい。（ｗ

210はピリオド＋カンマの使い方に特徴があるね。

>>216
論文を書いてる人は”，．”を使う人多いね
わざとそれを使って自慢しているふしもある

自慢してるわけではないんでは＾＾；

>>217
旧スレの938も同じスタイルだね。確かに自慢してるかも。
誰かなのかは各自の想像で。

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

>>217
こういう批判以前から聞くけど、技術系の文章にはそういうルール
があるみたいだよ。ソースは示せないんだけど。

最近の投稿で>>217の組み合わせって平鍋さんしか思い当たらないんだけど。

（　´_ゝ`）ﾌｰﾝ

落ち込んだ

おつむage

おつむの程度の高い平鍋さんでも>>219がいっちゃんつまらない発言なのはわからないってこった。

もうXPMLはほっとこうよ。考えるだけ悲しくなるから。
ここでﾏﾀｰﾘXPを語ろうよ。

XPMLの人たちとXPやれといわれたらやだな。
まだウォーターフォールの方がマシ。

＞２２１
ＭＬに投稿している人がこのスレで発言しているとは限らない
と思うのですが？？
ＸＰＭＬで発言している人でまともな人がこのスレで意見を
書くなんて無駄なことをしないと思うけどね。
馬鹿相手にするほど暇じゃないでしょう。

>>228
いや、彼だよ。（ｗ

無駄で自分の恥をうっかり晒したってことは確かだけどね。

相手のおつむの程度を見透かすような人にXPは無理です。

>>231
だからあ「おつむ」発言も平鍋なの。
平鍋に実践は無理。頭でXPをあれこれ語ってるだけ。

>>232
氏ね

思うんだけど理屈っぽい人同士でペアプロって無理なんじゃない？
と振ってみるテスト

その見本がXPML。

濱井がうざいというより
いちいち濱井を敵視して馬鹿なコメントをつけるNECの諸氏がうざい
社内で嫌われているのかどうかしらないけど大概にしてほしい

どこのmlだって浜井ぐらいのの厨房はいるから問題無し。(うざいのは確かだが）

けど、厨房の相手する人間がこのｍｌは多い気がする。

それはXPMLが厨房の集まりだからYO。

>>239 ← 馬鹿決定

あながち間違いとも言い切れない…

厨房の集まり＜あながち間違いとも

なんかまだ濱井タンSPAMを送ってきてるね…
もういいから退場してくれ。

ネタがなくなって、濱井ﾀﾝを晒し上げるだけのｽﾚはここですか？

だれか濱井ﾀﾝとペアプロしてくだちい。

あんな脊髄反射レスを繰り返すのはデンパとして晒されてもしかたないよ。日下部ﾀﾝの方がまだ中身があるんじゃないかい。

濱井は、たかがXPMLみたいに狭い世界でウォーターフォールを感情的に叩いたって意味
ないだろうに。

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

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

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

XPMLってもともとXPに興味がある人が集まってるんだから
ウォーターフォールに対する対比なんてみんな最初にやったことじゃないのか。

つーかウォーターフォールの欠点なんて、いまさら教わるまでもないんですけど（ｗ

だね。XPの利点をわかってて、ウォータフォールの欠点もわかってて、その上で
ウォータフォールにもこういう利点があるんじゃないかって、みんないってるのに
濱井の方は、みんなはなんでウォータフォールにはこんなに欠点があるのが
理解できないんだ、ってな調子なのがしらける原因だ。

>>248
濱井はその最初のまま固まってるのでうざい

＞>もちろん、繰り返し型開発でもXPに代表されるように、イテレーション注でも
＞>必要があれば"勇気"をもって対応する(変更する)ものもたくさんあります。
＞
＞XPでは、イテレーション中の変更については、変更するとも変更しないとも
＞特に言及されていなかったような……。

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

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

つづきだけど

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

>>252
よく濱井の文章読む気になるね（ｗ
俺は上から下に目を走らせて終わりだよ。頭には入れない。むかつくから。

>>252
馬鹿なちみは、ＭＬで聞かないほうがいいよ。
「イテレーション中」とあるだろう。

>>251
だからXPマンセーのおめでたい単純バカには受けがいいのかもね。平鍋さんもその口かな？

>>255
252 は ２５４の間違え

>>255
イテレーション毎の変更じゃなくて”中”の変更か。なるほどね。バカは余計だが。

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

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

濱井タンって何やってる人なんだろうね。ちょくちょくグラフィックカードの
ドライバの開発やコンシューマ製品の話を出してくるから、グラフィック
ドライバを一人でしこしこ書いてるのかな。

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

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

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

>>258

何が言いたいの？

>>259 妄想癖でもあるんじゃないの？ 馬鹿ばっか

本人登場か！？

あんなの開発者じゃねーだろ。
何もわかんねー文系が本だけ読んであれこれ理屈こねてるだけ。

アスパラ君そろそろやめなさい

濱井は

開発者
開発者じゃない

どっち？

>>264
その高圧的な物言い平鍋さんかな？

なんか両陣営とも疑心暗鬼で危険ですね。しばらくXPMLには近づかないどこ。

>>266
かもね（笑)

2chに対して高圧的な姿勢は煽りを助長するだけと思われ。

高圧的な態度が反発を招くのは2chに限らない罠
XPMLの連中にXPは無理。

階層型の組織だと機動性や情報の伝達性が悪いけど、
その分悪い情報の緩衝帯にもなってるんじゃないかな…

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

＞＞２７１
「悪い情報」と「良い情報」と分けるところががきだな

>>272 まったく
下に流す情報を選んでよいことなどないですよ。
悪い情報が怖い人は、2chで鍛えなさい。

分けてはいないよ。分けられるならよい情報だけ風通しよくできる
はずだろ？それは出来ないってことだよ。よい情報の風通しを
よくすれば、悪い情報の風通しもよくなるって事だよ。
読解力がないね。理解力がないのかな？

>>273
そうなってるのが2chとXPMLだ。キミには理想の姿だろ？

＞２７４ 馬鹿じゃないの
自分で「悪い情報の緩衝帯」と書いて
「悪い情報」という捉え方をしてるじゃない
それを分けているっていうんだよ

＞下に流す情報を選んでよいことなどないですよ。

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

>>276
よい情報を妨げると同時に悪い情報も妨げてると書いてるんだが、
どこに文句があるんだ？

＞２７８ 本当に馬鹿だな
そもそも 良い悪いと 分ける意味がないといってんだよ
お前の分は 良い悪い と分けて考えた文章になってんのがわからないの？

>>279
馬鹿を相手にするのはやめましょう

図らずも272、273のおかげで

「下に流す情報を選」ぶ

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

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

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

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

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

ひょうたんからこまだ。
XPと2chを対比させるのは面白い考えかもしれないな。

>>281
アホだなーーーー

＞＞２８２
何をもって対比させるか書かんとわからんだろう。
馬鹿ばっか。

仕事をしていれば当然多かれ少なかれ満足のいかないことがでてくる。
その対象が「上司」や「組織」ではなく、「仲間」になるわけだ。

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

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

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

>>284
うんそうだね。まだそこまで考えが進んでないんだよ。

ちょっと進んだから書くね。

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

>>285
気が振れてるんじゃないの？

>>287
「観点」の意味知ってる？
いい子は早く寝なさい

>>288
反論できないだろ？
こーゆう厳しい面を見ないでXPに浮かれられてもね。

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

>>290
論じてない文に、反論はできません。
自分の意見が通らないとだだをこねる、おこちゃまは早く寝ましょう。

＜XP推進プロジェクト ： 今月の課題＞

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

学級会だな。

３．自分の意見が通らなくてもみんなで決めたことは、一生懸命がんばりましょう。

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

ところで291とかは何マメに煽ってんの？まじめな煽りだな…

＞＞２９０

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

そうだね。XPMLは幼稚は人たちがはしゃぎまわってるけど、キミらには無理だって
いってあげなよ。＞ｘｘさん

アスパラ君そろそろ寝なさい

アスパラ（？） VS 平鍋（？）／濱井（？）の戦いは今日も続く…XPに明日はあるか？

アスパラ君のサイトにいけばわかると思いますが，
"…"を使っているものはすべてアスパラ君ですね．
"…"なんてめったに使う人いませんからね．

>>300
2chじゃピリオドとカンマよりは…の方が使われてると思うよ。

むなしい戦いだ…

どっちかつーと300の方が間抜けに見える。

とうとう平鍋ﾀﾝは2chで他人のHP批判をはじめました。
もうりっぱな2chねらーだと思いました。
こういうのをミイラ取りがミイラになるというんだよって先生が教えてくれました。

泥沼age

XPMLってのはいわば極左だね。

>300
2chで"，" "．"使ってる人も少ないよね。

>>306
自分らは革新派と思っちゃいるが，誰からも相手にされない共○党か…．

>>306

じゃあ、2chは？

XPのメンバーはチームであり、2chのメンバーは烏合の衆

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

>>310
チームの定義は？トートロジーを回避してちゃんと定義できるの？

>>309
2chは右翼も左翼も中道もいるね。ナチュラルでいいね（ｗ

>>311
トートロジーの定義は？言葉遊びをやってて楽しい？

>>313
XPML向きだろ？
トートロジーはわかるだろ？あんたの>>310でいえば、

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

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

トートロジーというよりも循環論法といったほうがいいと思われ。
所詮XPは「XPでうまくいくメンバなら他の方法でもうまくいくだろう」の呪縛から
逃れられない。

そして自分から急所に話を持っていった310の負け。つーか自爆。

>>314
> XPML向きだろ？
いいや、http://natto.2ch.net/test/read.cgi/denpa/向けだな。

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

>>315
> 所詮XPは「XPでうまくいくメンバなら他の方法でもうまくいくだろう」
でも、メンバが優秀ならば今までの方法よりはXPの方がうまくいく確率は高い。

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

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

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

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

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

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

>>319
> 優秀なメンバはXPで開発させ、優秀でないメンバはウォーターフォールで開発させる？（ｗ
戦争で例えるとXPは「機動力重視」でウォーターフォール「防衛力重視」だろうな。

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

開発メンバが仮に優秀だとして、わけわからん顧客相手にXPは通用するのかね。
顧客も優秀でないといけないんじゃないの？贅沢な方法だ。

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

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

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

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

なかなか簡潔でいいね。

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

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

SEのみなさん、今度からPGに頼むときは「仕様変更」じゃなくて「イテレーション」といいましょう。

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

応答例）
「えー、先週どうしもってうかこの部分イテレーションしましたよね。
もとに戻すんですかぁ？ほんとにこれが最後のイテレーションなんでしょうねぇ」

応答例）
「えー、先週どうしもっていうからこの部分イテレーションしましたよねぇ。
元に戻すんですかぁ？ほんとにこれが最後のイテレーションなんでしょうねぇ」

どうしもっていうから → どうしてもっていうから

>>325-327

とりあえずおちけつ。

女SE「今日、ワタシにイレテーション？」
男PG「またですか？明日起きれなくなるんで困りますよ。」
（ﾟ∀ﾟ）ｲｲ？

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

>>320
防御だと攻撃側の1/3の兵力で何とかなるんだが．．．

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

>>331
うむ、最終的に顧客利益になるようにするのがXPの本質だと思うﾅﾘ。

>>332
自分の会社の利益と衝突したときはどう解決したらよいのでしょうか。教えてください、おながいします。

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

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

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

イテエレーションするぞ。イテレーションするぞ。今週も顧客のためにがんばってイテレーションするぞ。

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

>.330
火力重視の攻撃型プロジェクトを作ったつもりが、防衛力重視になってしまう罠。

>>333や>>334には顧客が敵にしか見えないようだ
いつも中国や北朝鮮のようなユーザを相手に仕事しているのだろうか？

>>334
> XPとCMMを比較するのは経済学と宗教を比べるようなもので、ナンセンス。
え？XPとCMMは両方とも宗教だよ。

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

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

>>337
「敵」ねぇ、キミこそ正義対悪がわかりやすい漫画の見すぎじゃねーの。
「中国」や「北朝鮮」が「敵」にしかみえねーんだろ？
政治が何かわかってないな。

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

> 「敵」ねぇ、キミこそ正義対悪がわかりやすい漫画の見すぎじゃねーの。
「水戸黄門」の見過ぎという説もある。

>>339は「中国」や「北朝鮮」のような難しいユーザに
ポリティカルスキルを存分に発揮している凄いSEらしい。

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

>>341
相手が理想を掲げたから、理想で対抗しただけだよ。
実際、政治は必要だし。それともXPでやると急に顧客が物分りがよくなるのか？

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

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

おい、XP信者ども！
XPがけなされてるぞ！
Ｈ井イジメとか内ゲバやってないで、
まともな反論でもやってみろ

>>342
> 実際、政治は必要だし。それともXPでやると急に顧客が物分りがよくなるのか？

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

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

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

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

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

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

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

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

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

＞他にもXPには暗黙の前提がいくつかあって、あなたが攻撃しているのは、その前
＞提の方だという気がする。

半分当たり。

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

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

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

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

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

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

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

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

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

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

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

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

>>345
＞前提（適用範囲）が明文化されてないのが問題

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

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

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

つづき

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

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

OK、この前提には賛成しよう
・顧客が協力的でないと XP できない

　　 ＿＿＿＿＿_　　　 ＿＿＿＿＿＿＿＿＿＿
　／:＼.＿＿＿＿＼ ／
　|:￣＼.ﾐ∩ﾟДﾟﾐ＼＜　長文読むのﾀﾞﾙｲ
　|:　　 |:￣￣ U￣:|　＼＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　XPMLの車輪の再発明すんなよ…

XPのプラクティスを全部忠実にこなせば幸せになれると思ってる人なんているの？

いまより幸せになれるって思ってるひとはいるんじゃない？
余計始末が悪いけどさ。さぎでもちょっとだけリアリティがある方が引っかかりやすいし。

XPMLは幸せを求めてXPの話をするんじゃなくて、現在の不満をXPにあやかってぶつけている
人が多い。というか一人はいる。誰とは言わないが。

顧客側にもプラクティスが入るんじゃないのかな。どうなんだろ。

＞全てのプラクティスを忠実にこなせば、
ここがポイントだったんだが。
美味しいとこだけつまみ食いすればいいじゃん。
全部忠実にこなすことがXPじゃないはず。
これは勝手な解釈なんだけど、XPというのは方法論ではなく、
単なるきっかけにすぎないと思ってる。

>>354
同意。

>>354
んだね。だから最近のmlは不快。一生懸命書いてる人には悪いけど。

>>333

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

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

>>334

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

>>345

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

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

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

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

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

>>351
読まなきゃいいじゃん.

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

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

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

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

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

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

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

>>362

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

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

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

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

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

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

>>363

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

>>360

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

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

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

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

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

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

＞SEが「不可能なことを要求されている」と俺は感じている。
＞これを「変えるべき悪習」と見る人と「変えられない現実」と見る人の間では、
＞まともな議論は成り立たないと思うよ。

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

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

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

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

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

これでいい？

＞ちなみに旧来の方法では難しくXPなら可能（かもしれない）と考える
＞理由がわからない
ん？そもそも旧来のプロセスでは顧客も開発に参加するという
思想はないんじゃないかな。
何が「可能」って話？

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

＞＞ちなみに旧来の方法では難しくXPなら可能（かもしれない）と考える
＞＞理由がわからない
＞ん？そもそも旧来のプロセスでは顧客も開発に参加するという
＞思想はないんじゃないかな。
＞何が「可能」って話？

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

＞順番が逆かと。XP を選択するしないは（名目）自由。

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

>>368
漏れ的には XP 全てにこだわるよりも、取りあえず現状導入できるプラクティスを使えれば可。
XP 全体の議論になると、あまりに話が哲学的になりすぎはせんかい？

>>369
同意。

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

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

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

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

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

>>365
> ちなみに「はっきりわか」ったことを記録し、顧客なり開発者なりの評価（考課
> ですな）にもちいるのはXPの考え方に｛沿っている、反している、無関係｝？
XPでは開発者チームの評価は可能かも知れないが、開発者単位の評価は難しいと思う。

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

個々のﾌﾟﾗｸﾃｨｽごとの話は
ためになりそう。
　　　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 ∧,,∧∩　　／
　　ミ,,ﾟДﾟ彡　＜　つことで、しつもそん
　　 U　　ミ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　〜ﾐ　　ﾐ
　　 ∪''∪

最近、ﾌﾟﾗｸﾃｨｽが13とか14とかに拡張された
とか、聞いたけど、
なんでしたっけ？
ひとつは、机の場所とか家具の配置のことだったと
記憶してるんだけど。

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

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

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

>>374
リファクタリングで質問します。
１．コードの整理が付いて可読性が劇的に向上する。
２．再利用可能な汎用クラスが沢山できる。
３．コードの無理・無駄・ムラが減ってコンパイル速度が向上する(？）
等の利点が考えられますが、まだ他にも利点はあるでしょうか？

>>374
＞最近、ﾌﾟﾗｸﾃｨｽが13とか14とかに拡張された
＞とか、聞いたけど、
＞なんでしたっけ？
＞ひとつは、机の場所とか家具の配置のことだったと
＞記憶してるんだけど。

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

>>369
＞漏れ的には XP 全てにこだわるよりも、取りあえず現状導入できるプラクティスを使えれば可。

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

顧客の協力なしに(=顧客の意識変革なしに)はXPのプラクティスは、
ほとんど機能しないと思うが。

全体がウォーターフォールで最後のデバッグ&テスト工程だけが
XPの真似事ってか？（ｗ
この場合は害がないし益はすくなからずあるから反対しない。

しかし仕様を確定させないなんてことを顧客の理解なしに可能なのか？
よもや顧客とのインターフェイスは従来どおりで、PG仲間だけで
顧客とSE(?)の間でXPごっこなんてものを頭に描いて悦に入ってるんだろうか？


決められた仕様の枠の中で、

顧客とSE(?)の間で決められた仕様の枠の中で、XPごっこなんてものを頭に描いて悦に
入ってるんだろうか？

>>378
お前、関連書籍読んでないだろ。

>>380
ほう、大きく出たね。まずキミがどのレベルなのかを示してくれないか？
それがわかればキミに合わせたレベルで話をしよう。

>>376
374ではないので利点ではなく欠点を挙げてみよう。
> まだ他にも利点はあるでしょうか？

・ユニットテストが達成されていないとデグレードやエンバグの温床となる。
・プログラマのスキルに大きな差があるとある人は「改善」しているつもりだが
　他の人から見ると「改悪」しているようにしか見えないということが起こる。
・コードの共同所有が達成されていないと他の人の管理するプログラムに
　手が出せないので効果が低くなる。

よって>>372
> とかいう一つ一つのプラクティスに関する議論なら分かるけど。
XPの多くのプラクティスは他のプラクティスと密接な関係があり
単体で議論しても無駄。

# 単体で議論できるのはユニットテストぐらい

>>382
反論です。
１．リファクタリングはユニットテストを含んでいるはずですが？

>>383
> １．リファクタリングはユニットテストを含んでいるはずですが？
では何故XPでは別々のプラクティスなの？
# 含んでいるなら別々ニする必要ないんじゃない？

ちなみに俺の記憶の中ではXP本では
「リファクタリングはユニットテストを含んでいる」とかいう記述はないはず。
もしあったら指摘してくれ。

リファクタリング本の中では
「リファクタリングをするにはユニットテストを行った方がよい」という
記述はあったような記憶があるが。

>>384
> 「リファクタリングをするにはユニットテストを行った方がよい」という
ファウラーは
「堅実なテストはリファクタリングする上での事前条件です・・・リファクタリングにはテストが必須です」
とある。

>>376
一番の利点はコードの質に対する経験が高まり、次からは一段上の段階から始められること。。。。。。もあるかもしれないなぁと幻想に酔えること(w

関係者全員が幻想を共有したとき、生産性が向上する。

定説です。

>>385
> ファウラーは
> 「堅実なテストはリファクタリングする上での事前条件です・・・リファクタリングにはテストが必須です」
> とある。
指摘サンクス。俺が思っていたよりかなり強い主張だったみたい。

つまり、XPのプラクティスには前提条件の他に優先順位があるのかな？
ファウラーはそう思っていると読める。

>>388
> ファウラーはそう思っていると読める。

＠ぴぃんぽぉぉ〜ん！！大正解です！！

リファクタリング を効率化させるために、テスティングフレームワーク が誕生し、
リファクタリング テクニック が成熟するにつれ、設計に依存する体質から抜け出せるようになってきた。

これが XPプラクティス の中心部分だと漏れは勝手に推測している。

>>389
さらに言えば。。。
ファウラーはリファクタリングとコードレビューについて述べているが、
積極的コードレビューの考え方を究極に推し進めたものが XPであると述べている。

プラクティスって一見並列に見えるけど、そこには優先順位が当然あるってこと。
もしプラクティスからリファクタリングを省いたら、XPは音を立てて瓦解します。

ふーむ
>>378は
> 顧客の協力なしに(=顧客の意識変革なしに)はXPのプラクティスは、
> ほとんど機能しないと思うが。
とトップダウンからXPを導入した方がよい。と主張している。

一方、>>390は
> 積極的コードレビューの考え方を究極に推し進めたものが XPである
とボトムアップからXPを導入した方がよい。と主張している。

# 俺の読み違いだったらスマン。
うーん、どっちがいいのかな？（と煽ってみるテスト）

>>392
XPの導入過程がスパイラルとかいってみるてすと。

しかしリファクタリングテクニックの成熟で設計依存から抜け出せる、とは思い切った発言。

># 俺の読み違いだったらスマン。
>うーん、どっちがいいのかな？（と煽ってみるテスト）

残念ながら煽りになってません。
XPの教義に従っていれば、どっちから始めても、
そして最終形態がまるで違っていても、XPです。

じゃあ、XPの教義とはなにかというと、XPの4つの価値を認めることです。

>>365

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

そんな感じ。実際には、チェックするためってよりも、目標を兼ねていると思う。

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

他の方法論では重要視している部分が違うから、自然とXPのチェック内容とは異なります。
XPの利点はXPが重要視している価値に最適化されている、または最適化されうる方向性
をもっている、ってところ。

例えばウォータフォールは、「出来るだけ早く顧客にリリースする」ことをXPほど重要視して
いない。XPのプラクティスは、「出来るだけ早く顧客にリリースする」を満たすために構成
されているし、そのものずばりのプラクティスもある（小規模リリース）。
だから、XPのプラクティスの面から、他の方法論と比較するのは無意味です。

宗教で言えば、キリスト教と仏教を比較するのに、葬式の方法を比べているようなものになる。

http://pc.2ch.net/test/read.cgi/prog/1000130870/461-463
こんな感じに解り易くメタファで解説きぼんぬ

>>365

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

無関係だと思うけど、どうかな？
XPのプラクティスは、プロジェクトのハンドリングに用いるもので、
成績に用いるものじゃないと思うけど。

>>396
＞ 行くのじゃ勇者よ！そして変化を抱擁せよ ！！！」

ﾜﾗﾀ

XPクエストきぼんぬ。


＞しかしムリカイナジョウシとは生理的に合わなかった
＞ペアプログラミングの心得は音も無く崩れ去った

ま、ムリカイジョウシがいれば成功しないのは当たり前だが、
いなければ成功するというものでもない。当たり前か＞俺。逝くね。

勇者はプロペラ帽を装備した。

ムリカイジョウシの表情がさらにこわばった。

どわはは

はじめまして。XPの初心者です。ひとつ質問をさせてください。
「抱擁」ってなんて読むんですか？

「ほうよう」です

モニタ小さいのでよく見えず、擁護だと思ってた

>>393
> しかしリファクタリングテクニックの成熟で設計依存から抜け出せる、とは思い切った発言。

OOP の最大の問題点は 「オブジェクトを発見するのが難しい！」 であるのは通説と思われ。
設計段階での混乱が実装に影響およぼすし、オブジェクトの設計のミスが実装にしわ寄せを及ぼす。
これが リファクタリング によって 「実装しながら設計」 が可能になったのはでかいと思われ。

>>404

同意。リファクタリングは、シンプルさを保つための必須技術ですな。
リファクタリングとユニットテストの効果を疑問視している人は、自分で
ちいさなツールでも作って試したらいいと思う。

すっごい大変なプロジェクトで、気付いたらXPみたいになってたことってない？
内部設計なしでコミュニケーションでカバーしてたり･･･。

元々設計段階で完璧にオブジェクトを定義するのは不可能なのよね。
そこに リファクタリング の意義がある。

あと リファクタリング と デザインパターン の関係だが、
「デザインパターンはリファクタリングの提供する」とは GOF 自身も認める所。
ある程度実装が進んだ段階で、始めて効果的なオブジェクトやインターフェイスを
定義できると思われ。
大体 State や Strategy パターンを導入する場合なんかは、
実装段階でないと全然見えてこないだろ。

>「デザインパターンはリファクタリングの提供する」
じゃなくて・・・
>「デザインパターンはリファクタリングの目標を提供する」
だった。スマソ。

>>408
んんん？？？どういう意味じゃ？？？

>>406
>すっごい大変なプロジェクトで、気付いたらXPみたいになってたことってない？

XPのプラクティスは、XPで開発されたわけでなく、それまでで有効と言われた
方法を極端に適用したものだから、当然、XPを意識しなくてもXPみたいになる
ことはある。

「オンサイト顧客」なんて、結局、顧客の張り付きのことだから、納期が守れずに
品質が悪い成果物しか出来ないみこみが高くなり顧客の信用を失いかけたとき
によくやられるんじゃない？

XPでは、それをプロジェクトが暗礁にのりあげてからでなく、
最初からやっておけって考えだと思う。

>>410
まえからぼんやり思ってたことがひとつ。

実際XPは火を吹いたプロジェクトの末期症状をモデル化したものそのものだ。
XPが要求する前提条件はこういった状況でないと成立しないのではないかと思っている。

言い方を変えると、過去にこうした状況を乗り越えた、顧客-開発者同士ならXPを
やってもいいかと思っているが、見ず知らずの相手い顧客の立場でも開発者の
立場でもXPでやりたいとは思わない。

またXPは本当に効率がよいのだろうか？上のような状況ではメンバが必死だから、
高い効率になるのはいわば当たり前。しかしその状態をXPを用いたからといって
日常的に維持できるとは思えないし、維持すべきだとも思わない。

火を噴いたプロジェクトの末期症状だと効率は良くならないよ…
ペアプログラミングなんてやってる余裕はないし、テストをしょっ
ちゅうやったりもできない。情報を共有している暇がないのであち
こちで不一致が生じて泥沼にはまっていく。

>>411
>XPは火を吹いたプロジェクトの末期症状をモデル化したもの

理論に飛躍がありすぎ。
思い込みを吐露する前に関連書籍の一冊でも読んでよ。

＞理論に飛躍がありすぎ。
＞思い込みを吐露する前に関連書籍の一冊でも読んでよ。

だからキミのレヴェルを示せば、それにあわせたレヴェルで話すと
いうとろーが。＞本嫁厨房

＞ペアプログラミングなんてやってる余裕はないし、テストをしょっ

そりゃそうだろうね。が上級者がリアルタイムで見回って（なんかいい表現が
見つからないが）、要所要所でチェックを入れるってのは多々ある。
対等の関係のペアプロなんてものがあるのかね。

＞ちゅうやったりもできない。情報を共有している暇がないのであち

そりゃやり方が悪いんだろ。火を吹いたプロジェクトを収束させるには、
テストは必要。これも要所要所に絞られるのは確かだが。時間をかけて
テストプログラムを作っている暇がないのはそのとおりだね。この場合
人間という便利なテストプログラムを人海戦術で代用することがあるけど、
人間は高価だから、その意味では効率がすごく悪いだろうね。

＞こちで不一致が生じて泥沼にはまっていく。

それは火を吹いたプロジェクトから抜け出せずどんどん深みにはまっていく
パターン。火消し人はそういうプロジェクトに投入されると、まっさきに情報の
交通整理からはじめる。

>XPは火を吹いたプロジェクトの末期症状をモデル化したもの

表現を変えよう（ｗ

XPは火を吹いたプロジェクトから脱出できた状況をモデル化したもの

>>416
うま！！座布団三枚あげて〜！！
大体 火の付いた C3プロジェクト でやったノウハウをまとめたものが、XP と思われ。

飛躍というなら

＞XPでは、それをプロジェクトが暗礁にのりあげてからでなく、
＞最初からやっておけって考えだと思う。

それがうまくいくと考えるのが一番の飛躍だろうな。いわばXP公理
だから、これがただしか否かはXP内では論証できないはず。

XP信者は、かっこのいいお題目じゃなくて、これこそがXPのセントラルドグマ
だって宣伝すべし。

一応いっとくけど411=416=俺なんだけど。
厨房が誤解するから、書き換えただけ。

411の後半が俺がいいたいことだ。

>>418の論理の必要条件は、
「最初からXPを導入した事例がまだ存在しない。」
という命題が真であることである。
これには同意する？

どのXP本か忘れたけど、実装時間の見積もりを各開発メンバに出させてさ、
進捗チェックに使ってたことあったじゃない。
それで、早めにメンバが煮詰まっていることをPLが見つけて、相談してさ。
結局、なにもしないまま手遅れになることを事前に防止できた。

これを、日常的な光景にしたいんだろうね。

上司と部下、開発者と顧客。
「なにもしないまま手遅れになる」ことを否定して、
そうならないために取るべき行動を列挙したもの。
XPってそういうのじゃないかな？
房なんでよくわからないけどね。　:p

>>420
ん？
「最初からXPを導入した事例がまだ数多くは存在しない。」
なら同意する余地はあるが
「最初からXPを導入した事例が１つも存在しない。」
で同意すれば、否定されるだけだから同意しないけど（ｗ

そんなむちゃな論法なら俺もいえるよ。
「XPを導入して失敗した事例がひとつもない」ことがXPが有効である条件であると。

つまらんよ。

＞それで、早めにメンバが煮詰まっていることをPLが見つけて、相談してさ。
＞これを、日常的な光景にしたいんだろうね。

自分の進捗について寡黙な姿勢を好むPGは多い。もちろん
進捗状況の把握面ではもちろん困ったことなんだけど、可能な
範囲で本人の好みを尊重している。（結構見誤りのリスクが高いから
つらいんだけど、やっぱ本人に気持ちよく仕事してもらうのが効率
がいいから。）

XPだと、そういうPGでも気持ちよく語ってくれるのだろうか。
それともそうでないPGは去れと？

＞上司と部下、開発者と顧客。
＞「なにもしないまま手遅れになる」ことを否定して、
＞そうならないために取るべき行動を列挙したもの。
＞XPってそういうのじゃないかな？
＞房なんでよくわからないけどね。　:p

だからXPに合わないってPGも多く出てくるんじゃないかな。
ま、どんな方法でも相性はあるから当たり前だけどね。

>>422
422=411として話を進めるけど、結局あんたはXPは役に立たないと言いたいの？
スタンスがハッキリしないのでどうレスしていいか悩むんだけど。
ちなみに俺はXP肯定派です。

>>404
だからOOPはスパイラルが不可欠ってのがOOPの考えだと思うけど。
スパイラルに比べてXPは急進過ぎ。少なくとも設計面では。

＞自分の進捗について寡黙な姿勢を好むPGは多い。

好んでるわけじゃない。
遅れてると言えば糾弾されるし、進んでいれば仕事を増やされるしで正直者が馬鹿
を見るシステムになってるから。
だからいつも「スケジュール通りです。」って答えざるを得ない。
イテレーション単位でタスクを分割すればPGの心理的負担はかなり減少するよ。

>>424
＞スタンスがハッキリしないのでどうレスしていいか悩むんだけど。

悪かった。ここでは否定派の立場で発言している。

ウォーターフォールが長い歴史をもつ仏教やキリスト教とすれば
XPは新興宗教だから、”売り出す”ための過激な教義に満ち満ちている。
「民衆を惑わず怪しげな宗教」の化けの皮を剥ごうじゃないか、というのが
ここでの俺のスタンスだ。

一方でXPの考え方を評価している部分もあるから、スタンスがわかりにくかった
かもしれないけどね。ここでの基本スタンスは否定派だ。

>>426
＞遅れてると言えば糾弾されるし、進んでいれば仕事を増やされるしで正直者が馬鹿
＞を見るシステムになってるから。

これを根底から覆すのがXP。
遅れてると言えば普通に助ける(マイナス評価にはしない)し、
こなしたタスクの合計難易度が評価に直結するから、
やればやるほど得することになるシステムってことになる。

正直者が否定されて開発効率が低下するのが従来の方法なら、
正直者が肯定されるのがXPだね。

（自主的に）増やすか（マネージャーに）増やされるかの違いってことでいいわけ？
この程度を根本的な変革と喜ぶんならお手軽でいいね。どんどん自主的に仕事を片付けてくれたまえ。
もちろん君の努力を正当に評価するよ。ついては正当に評価するためにまめな進捗報告よろしく。
おや、君は今月｢助け合い｣がすくないようだね。君の助け合いの目標値と達成率をせつめいしてもらえないかな。

>>411
>実際XPは火を吹いたプロジェクトの末期症状をモデル化したものそのものだ。

これは鋭いと思う。どの会社にも「火消しのエース」とか呼ばれる奴がいるだろ。
そういう奴のすることを「モデル化」したものだ。

> またXPは本当に効率がよいのだろうか？上のような状況ではメンバが必死だから、
> 高い効率になるのはいわば当たり前。しかしその状態をXPを用いたからといって
> 日常的に維持できるとは思えないし、維持すべきだとも思わない。

末期症状で目がつりあがったような状態、よくも悪くも「ハイ」な状態を継続す
ることはできない。しかし、そこで何が起きてるか、何が普段と違うのかを抽出
することはできる。「モデル化」っていうのはそういうことだろ。うまく抽出し
たものなら日常的に維持できる。それがXPなんだと俺は思う。

ただ、それでも非常に疲れることではあるから週４０時間になってるんじゃない
の？

>>430
そうなんだろうね。
でも週40時間のほうが開発効率がいいということが、
理解できない上司も多い。
時間かけりゃいいってわけじゃないことくらい、
何度か徹夜したことあれば、わかるとは思うんだが。

>>429
あえて皮肉を書いたってことは分かるんだが、あえてマジレス。
正当な評価ってのは、（それぞれのタスクの難易度が等しいと仮定するなら、）
10個のタスク終わらせた奴には、
1個しか終わらせない奴の10倍の給料払うってことだぞ。
それと、助け合いにノルマなどない。
あるのは、情報伝達の漏れによって開発が滞ったか、そうでないか、だ。
納品が遅れれば企業はダメージを受けるし、
納品が早ければ企業は優位に立てるわけだからな。

>>431
> でも週40時間のほうが開発効率がいいということが、
> 理解できない上司も多い。

理解はしてるけど、開発効率を上げる（納期どおりに開発する）ことより優先す
べきことがあるんだよ。そして、週４０時間でさっさか帰るってことがそれに反
してるんだろ。

>>431
> 10個・・・10倍の給料

ほお、それでは0個の月は給料ゼロでいいわけだな。そんなんで落ち着いて作業できるのか知らんが、それが君の理想ってことでいいな？

結局、作業量と給料の問題が解決しない限りは、
すなわち、残業やるー＞一生懸命な出来るプログラマという
大嘘に傾きがちな一般人を再教育するシステムが必要なのだ。

ＸＰマンセー。週４０時間マンセー。
「その日程ではできません。」
こういう勇気をもとうよ。＞ＰＧ諸君。
これをいえない環境で仕事しているから、
みんな不幸なのだ。

ボッタクリ価格マンセー。
それが余裕を生むのだ。

どの道結局、余裕のないプロジェクトは火を吹いて、
結局は払わされるんだぜ。＞顧客の皆さん。

値切れば、安くなるという教育ループをまわしているから、
ウォーターフォールな発想はいかんのだ。

実際、マージンの部分はいくらでも削る見積もりだせるわけだし、
火を吹いたら、そこで交渉に持ち込めばよいというのが、
ひとつの知恵なわけだし。

でも、それをやってるから、ＰＧ側が嘘つきに見えるんで、
余計に厳しい価格と日程を指示するほうに学習しているんだよ。

ということで、オーダーメードなソフトウェアの値段は高いのだ。
それを受容しないから失敗する。

ＳＵＩＴ’Ｓカンパニーのスーツと、
一流オーダーメードと二流オーダーメードと、
近くのテーラーのオーダースーツと一緒に考えるのが
一般人。違いを認識させてやれー（爆）。

>>431
> 情報伝達・・・

そういってくるやつは多い。そいつには望みどおりすべての情報を渡してやる。
たいてい次にくる文句は情報を整理して渡せだ。

>>433
勝手に解釈すんなや。
一月で終わったタスクが0個なんてありえないよ。
実装作業の小さな単位としてタスクという概念があるんだから。
結局、0タスクしかこなせないってのは、
一ヶ月まるまる休んだ場合くらいにしかあてはまらない。

>>436
あまり賢くないね。完全歩合性の給料こそが望みってことでいいのか聞いてるんだが？

>>434
＞「その日程ではできません。」
と言う以前に、客の求めるものがいつできるのか・どこまでできるのか
XPだと事前には何も言えないと思うのだが。

それでちゃんと「金を払おうと」言ってくれる客って一体どんな客なの
かが俺にとってXPの一番の謎。XPは確かに魅力的だが、顧客にはこれを
理解する洞察力と非常な勇気がいるように思う。

>>431
＞でも週40時間のほうが開発効率がいいということが、
＞理解できない上司も多い。

最大化しようとしているのが「効率」ではなく「総仕事量」だから
なだけだろ。残業費なんてのは会社としてそんなにプライオリティ
は高くない。火を吹いているようなプロジェクトでは特にね。
いくら人件費がかかって破綻だけはさせたくないってのが、
正直なところ。破綻なんてさせたら次から仕事の受注に差し障る
からね。

PG諸君は気兼ねなく残業して、多少効率が悪くても
作業時間でカバーしてくれたまい。（ｗ

一応形だけは残業時間削減を指示することはあるが、あくまで
仕事量を維持した上だってことを肝に銘じて置くように。

たまに残業する分には効率が上がるにしろ、
残業が常態化すると定時内はだらだらやるようになって
仕事量は残業をしなかったころと変わらなくなってしまう、
とは「ゆとりの法則」だっけ?

>>438
例えば2社でコンペさせて、作業もしてもらう。最終的によい方を採用。
それぞれの会社に払う金額は従来の1/2（採用した方には多少色をつける）。

顧客が払う金額は従来とかわらない。XPがそんなに効率がいいなら1/2の
金で十分だろう。（ｗ

どうよ？

ＨＴＭＬのことなんですけど、
ページを開くと他にも次々にページがでるようにしたいんですけど
どうやるかわかる人いますか？
いたらおしえてほしいです！お願いします！！

ちょっとだけムリカイジョウシを返上してマジレスするが

火を吹いた状態だと、作業時間を抑えようとしても、PG自身が
プレッシャーから、作業をやめようとしないことが多々。
「いまそんな余裕はありません！」って逆に怒られてしまう。
そんな状態になった時点で現場が十分不健康になった証拠なんだけどね。

考えようによっちゃ、残業する/しないの文句がでる間はまだ健全。（苦笑）

>顧客が払う金額は従来とかわらない。XPがそんなに効率がいいなら1/2の
>金で十分だろう。（ｗ

でも品質が2倍いいから、料金は変わりません。

ほんじゃ、品質は1倍でいいから、料金を1/2にしてちょ。

最後までコンペってのは難しくても、早いリリースを利用して途中まで
コンペ。期待できそうな会社の方を採用ってのはありかも。
なんにせよ顧客に目に見えるメリットがないとね。

>>438
営業が「できますできます」と言うのを
話 8 分目くらいに顧客が聞くという現状と比べて大して変わらないと思うね。

>>445

それはメニューにありません。

品質が1/2で料金が1/2はどうです？

XPでは顧客はいつでもプロジェクトを中断できるはずだし、コンペも禁止してないはずだし、
結構XPの精神に沿った上で現実に取り組んでもらうにはよい方法って気がする。
よもや短期のリリースだけで評価されるのが不満だとは言わないだろうしね。

勘違いしてる奴はいないだろうけど、一応確認させてくれ。

●XPでは開発速度が上がり、顧客に高品質な製品を、納期通りに納品できるメリットがある
●PGの評価は労働時間ではなく、こなしたタスクの総難易度によって決定される

適正なスキル評価と、速い納品サイクル
これが大前提ってことでいいんだよね？

>よもや短期のリリースだけで評価されるのが不満だとは言わないだろうしね。

言わないに決まってます。
一つ一つのリリースが真剣勝負ですから。

各機能が本当に必要なのかイテレーションごとに現実的に交渉し、削減できることは重要でんな

>>448
それを望むと、どんなもんが出てくるの？

客が交渉の結果、納得して削った半分の機能は実装されないまま納品されます

>>453

全日程のうちで顧客が重要だと考えている機能の上位半分が完成したものです。
つまり、XPでは顧客の重要度順に小規模リリースするから、半分いったところで
プロジェクトを終了させれば、半分の品質（コストで半分の機能のみ実装）の製品
を納めて完了します。

顧客は、もっと金をだしてもっと続けたければ続けられるし、もう十分だと考えれば
それで終了できます。

XPの本じゃないけど、「the Goal」って本の内容はまさにXPの実践そのものだよ。
かなりおすすめ。

機能と品質を混同してるような。
半分の品質を提示するためには品質を定量化できる必要があるけど
どうすればいいのか。バグの数を倍残すのか?

XPの目指すところは承知しているつもりだしなるほどと
思う点も多々ある。

しかし、俺が今まで受けてきた仕事は、最初に期間と金額
と機能が決定するものがほとんどだ。

実際にXPを使う場合、「月々いくらで、翌月継続するかど
うかは前々月に決める」とかいう契約になるのか？

顧客の方に理解があったとしても、それで上司に支払いを
決済してもらうのは大変だろうと思うんだが。

>458
そうだよ。
だから日本でブレイクしないんじゃないか。
ソースコードの行数アップなんてのはＸＰの狙いじゃない。
その意味で最大最高効率のソフト開発なるものをＸＰは狙っては射ない。
機能が決定しているなら、ウォーターフォールでよかろうさ。

ただ、機能の概要は決定していても、詳細まですでに決定しているというのは
普通ありえないだろう？だから、機能の詳細を検討する必要がある。

問題は、ソフトウェアの機能が非常に難しくなってきていて、
ユーザ側にも、必要なんだかいらないんだか、わからない機能が増えすぎているのが
本当の意味では金の無駄だというのが、ＸＰの前提のひとつだ。
Ｗｏｒｄの資格、ＭＯＵＳとか持っているだけで就職有利になるのが、
パンピーの世界らしいぜ（苦笑）。
だから、ソフトウェアの仕様を学習するための期間が必要で、
それには、小規模リリースされたソフトウェアを使えないと
学習できないのさ。
そういう問題領域のときにＸＰが有効。

ソフトウェアの機能の８０％は無駄。
これが、ＸＰの前提としている２０−８０ルールだ。

まぁ、しかし、
３ヶ月ぐらいの試験プロジェクトとして開始して、
３人＊１００万円＊３ヶ月＝１０００万円ぐらいの予算規模で
開始する約束でスタートして、
一ヶ月ごとに真剣勝負するスタイルなら別に問題なかろうさ。
機能が作りきれなかったら、ごめんなさい。
だけど、でもまぁ、多少ない機能があるぐらいのことなら、
よくある話じゃないか。許容しようぜ。大した機能じゃないんだから。

品質が安定していることと、
仕事を引き継ぐときのストレスがないのがＸＰのいいところだ。

３万行以上のソフトウェアのメンテナンスで、
１００行毎に、なんじゃこりゃという驚かざるおえない事実を
発見するハメにかかわるなら、
おれはＸＰスタイルのもののメンテやりたいね。
だって楽だもん。
ゴミ仕様書なんていらないさぁ。

>>457
>機能と品質を混同してるような。

そうだよな。
そもそもXPでちゃんとテスティングとリファクタリングの過程を経て作られたプロ
グラムに品質1/2なんてあり得んのだが。

>>459

無駄な機能で思い出したんで最近やった仕事の例を紹介しておく。

顧客はある大手電機メーカー。
品質管理のためのデータウェアハウス系システム構築での事。
顧客側では製造ラインから品質管理部門まで多岐にわたる部署から上がってくる要
求をシステム部門が一手に引き受けてうちのチームと仕様を決めていた。
しかし、ご多分に漏れずシステム部門の担当者がオーバーフローして仕様を絞りき
れなくなった。結局は各部門からの要求をほとんどそのまま仕様に載せてしまい開
発工数もうなぎ上り。
そしたらシステム部門は経営層から相当叩かれたらしく、「機能ごとの使用頻度統
計をとるためのログ機能」なるものを追加しようとした。しかしそんな物を実装す
る時間も予算もあるはずが無く、当然のごとく却下。
そろそろ客もウォーターフォール型に嫌気が差してきた様子なので、次の仕事では
XPを提案してみようかと思う。

>>457、>>460よく言った!!

XP批判をすると宣言しながら俺はまだまだだな（ｗ

いや、ちょっとね。某信者のXPに関する造詣に気負いして、突っ込み損ねた。
深く深く反省してもっとXPを叩くぞ（爆

>>458
期間と金額と大雑把な機能は決めるけど、詳細はプロジェクトを
進めながら検討ってものもある。この種のプロジェクトははっきり
いって面白いが難しい。

お互い最善を尽くすという信頼関係がないとできない。信頼にこた
えられなくても打ち切られることは（よほどのことがない限り）ない
けど、おそらく次のプロジェクトはこないと覚悟する必要がある。

うまく工程表に当てはまらないので、外見上はウォーターフォールを
多段に繰り返すような形にし、さらに１つの段階内でも設計をわざと
あいまいにしてコーディング段階の自由度を増して対処している。

もちろん顧客とはどの段階でも頻繁に打ち合わせを行う。だいたい
プロジェクトの期間は半年〜2年ぐらい。

ウォーターフォール型で一番XPに近い形になるのかな。でもこれ以上は
歩み寄れないと思う。

んで、なまじこの手のプロジェクトの厳しさを知っているので、お気楽に
XPマンセーしてるのが許せないってのが俺の心情。（我ながら鼻持ち
ならない書き方スマソ。）

>>461
相手のシステム担当者がそのレベルだと、XPにしてもやっぱ破綻するんじゃない？

＞３人＊１００万円＊３ヶ月＝１０００万円ぐらいの予算規模で
＞開始する約束でスタートして、

まあ確かに1000万ぐらいのプロジェクトだとXPはいいかもね。
もうひとつ桁が上がると無理だと思う。

>>464

担当者自身は無駄な機能を実装しているという自覚や問題意識を持っているからこ
そ「ログ機能」を実装したいと言ってきたわけで、無能なのではない。
XPを導入することになれば当然顧客社内の意思決定プロセスも見直す必要が有るの
で、担当には相当汗をかいてもらう事になるだろうけど、それを補って余りあるほ
ど改善のメリットは大きいと思う。

>485
ん？勘違いしていないか？
１０００万円ぐらいからスタートして、
結局うん億円ふんだくるんだぞ？
ただ、そんな約束は最初にはしないだけ。

ＸＰでは、長い約束はしない。
所詮、お互い気分が変わるからな。
だけど、軌道に乗り出せば、安定した開発になるので、
外側から見ると管理しやすい。

無能ならクビ切るだけだし、有能ならそのままキープしとけばよい。
判断が早くできる。

ＸＰにすれば管理しやすくはなるんだが、
それで儲かるかどうか？本当に他社より安く良いものを
作っているかは別のことだからな。

ただいずれにせよ、納品後メンテナンスを発注側がやるなら、
ＸＰで納品してもらったほうが断然良い。
コードが一定規則で書かれていて、
コードが一定の品質に保たれていて、
自分がもし機能拡張しようとして、
ミスをしても、ソフトのほうが教えてくれるんだぜ？

受け取るソフトとしてほぼ期待以上の水準だわな。

>>466
煽りじゃなくてマジな質問なんだけど、XPだとどの辺が改善されると考えてるの？
例えば最初に実装する機能をどの部署の意見に基づいてどう決めるの？
XPといえども顧客側に分析力は必要だと思うけど。

ウォーターフォールで仕様が膨らむのは顧客側が積み残しを恐れるあまり、
いらないかもしれないけど、いるかもしれない機能を全部突っ込むから。

一度で分析できないような複雑かつ大規模なものは2段階とかに普通分けるはず。
ものの道理がわかった顧客+SEならね。それを一段階で済まそうと考えた人たちは、
その点やはり無能だと俺は思うんだけど？

ということでだな。

おれとしては、
元請のほうは、旧来の基準で受注しといて、
次の下請けにおろすときに、
ＸＰのユーザの役割を元請けのほうでやれば良いと思うぞ。
これが現実的な解決策さ。

元請様なんだから、当然受け入れテストぐらいは書けるわけだし。
仕様書沢山書いてお客をケムリにまくのも得意じゃろ。

ついでに、ＸＰスタイルで発注しとけば、
別の下請けに引き継ぐのも容易だ。

元請けーＲＵＰ＆ＣＭＭで、権威づけして高くふんだくる。
下請けーＸＰで楽々に開発。高速に学習できるプロセスを採用しているので、
技術力があがって、いずれは単価アップでハッピーだ。

このスレなんだかものすごく面白くなってきた。

ただ2段階に分けたときの落とし穴として、1段階目の稼動が遅れに遅れ、
当初予定した2段階目の開発開始時期を追い抜いてしまう場合。
この時2段階目の開始の延期を押し通せないと、1段階目のメンテをしつつ
2段階目の開発を開始するという地獄の苦しみを味わう。

>>469
元請が顧客に出す「仕様書」はごまかしきれるものなのか？
XPなら仕様は確定しないわけだから、顧客にはでっち上げの仕様書を
渡して、元請の責任でつじつまを合わせることになると思うが、大丈夫？

逆につじつまが合わせられるような仕様書が作れるなら、ようは仕様が
最初から読みきれるわけで、ウォーターフォールでいいんじゃないの？

>>466

まず機能の優先順位についてだけど、顧客側担当者もうちもどの機能が最優先かに
ついては実はちゃんと解っている。
それは製造ラインからDBへデータをストアする機能。
問題はそこからデータ参照系をどう作るかという部分で仕様作成が紛糾する事なん
だよ。
製造ラインから上がってくるデータは検査装置のハード的な制約が大きいからER図
が大きく変わることなんかまず無いし、変更が有ったとしてもせいぜいカラムのサ
イズがちょっと変わるぐらい。
ところが参照系となると、現場の人間ですらどのようなデータが見たいかを把握し
ていない。そんな状態で無理やり仕様をFIXしようとするもんだから機能てんこも
りのゴテゴテ画面がたくさんできてしまう。
というわけで、契約の段階ではデータ登録系の着手だけを確約しておいて、参照系
についてはイテレーションを使ってはどうかと考えている。

ちなみに、

>複雑かつ大規模なものは2段階とかに普通分けるはず

に関して言うと、今までも複数フェーズに分割してたんだよ。
ところが分割した各フェーズで仕様が膨らむといういたちごっこに陥ってしまって
いるとうわけ。
各フェーズは3ヶ月程度の期間があるのだけれど、そのうち1ヶ月は仕様作成に費や
されているんだよな。しかもFIXしたはずなのに変更が多発するし・・・

仕様は確定しない？
そんなことはないぞ。
ＸＰだって、作っている最中は仕様は確定している。
最初に全部の仕様をガチガチにしないだけだ。
開発項目になるものに関しては、外部仕様（受け入れテスト項目）
事態は確定しなくてはならん。

少なくとも、その項目の開発のイテレーションの終了までには、
受け入れテストという形で仕様は確定せねばならんのだ。

仕様が読みきれると見積もりが正確に出せるというのか？
それは本当なのか？

ソフトウェア職人気質によれば、
仕様があいまいな初期の見積もりは４倍の誤差がある。
２０％設計作業が進行して、２倍の誤差になる。

ということで、シンプルにいえば、
元請けがきっちり４倍から５倍の費用を請求しておけば、
基本的には大丈夫のだよ。
だから、ボッタクレと言っているんだ。

＞というわけで、契約の段階ではデータ登録系の着手だけを確約しておいて、参照系
＞についてはイテレーションを使ってはどうかと考えている。

なるほど、面白そうだ。（つい応援したくなってしまった。）

しかし

＞ところが参照系となると、現場の人間ですらどのようなデータが見たいかを把握し
＞ていない。

これはやっぱり（設計重視派の俺としては）分析に力をいれた方がいいと思う
けどなぁ。こんな状況でXPで顧客とPGを直結したら、振り回されっぱなしにな
るんじゃないの？（っていう考えがそもそも反XPなんだろうか？）

＞各フェーズは3ヶ月程度の期間があるのだけれど、そのうち1ヶ月は仕様作成に費や
＞されているんだよな。しかもFIXしたはずなのに変更が多発するし・・・

3ヶ月単位でも仕様変更が多発するのか。それは気の毒としか言いようがない。

俺に言わせれば顧客の担当者サイドのリソース増強か、外部コンサルタントを
雇うべきと思うんだけどね。どうしても重厚長大の方向で考えてしまう俺。

ま、でも興味深い話サンクス。

>>474-475
横レスだが、XPで何度もプロトタイプをリリースして
仕様を固めていく(やっぱりあれも見たい、これはいらない)
ってことじゃないの？

各部署からの顧客がみんな常駐するわけじゃなくて。

なんとなく効果をあげそうな気がする。おれも応援したい。

>>474
？よくわからんのだけど、元請がエンドユーザに対して出す
仕様書はいつ、どの程度の粒度のものを提出するのだ？

>>476
レス番号書き忘れたが、>>475は>>473に対するレス。>>474は別の話。

ん？
別に以前と同じようにやってる振りしてればぁ？

ただし、重要なことは、機能の間の優先順位を常に把握するような
インタビューをして、開発側に指示することだ。

機能の詳細をきっちりつめて同意したハンコもらったというタイプの
仕様書を作る必要はない。

完全な矛盾なき仕様書の呪縛から逃れられるのなら、仕様作成もそれほど
負担じゃなかろうさ。

>>479
君の言ってることは、わけわからん。

>>479
雑に書きすぎ。意思疎通が図れてないぞ（ｗ

朝一にスタンダップミーティングって必須なんですか？

XPに興味わいてたんですが、Next Engineerとかいう雑誌で
「XPでは朝一番に全員揃ってスタンダップミーティングをするので
フレックス通勤などはできなくなる」
と書いてあったので社内ではXP反対派になりました。

しかし本当にフレックスやめてスタンダップミーティングなんかしてるの？？

＞まず機能の優先順位についてだけど、顧客側担当者もうちもどの機能が最優先かに
＞ついては実はちゃんと解っている。
＞それは製造ラインからDBへデータをストアする機能。
＞問題はそこからデータ参照系をどう作るかという部分で仕様作成が紛糾する事なん
＞だよ。

優先順位が2段階なのは荒すぎるのでは（ｗ
データ参照系の中でも優先順位をつけられないと、XPは無理と思われ。
（つけた優先順位が後になって変更されるのはよいけど。）

>>483

確かにちょっと表現が乱暴だったかも。
一応参照系の中でも優先順位は有るには有るんだけど、守秘義務を破らずに説明す
るのが難しいもんで（ｗ
当り障りの無いところで言えば、機能は帳票とグラフ表示とに大別できて、製造の
工程ごとに詳細部分がカスタマイズされているという感じかな。
そのなかでもグラフ表示のデータをどのように扱うかという部分がなかなか決まら
ない傾向にあるね。
多分グラフ表示だけXPに持ち込んでも相当な工数削減が望めると思うよ。

思ったんだけど、XPには顧客側にコンサルタントが必要なんじゃないのかな。
そうじゃないと顧客は怖くてOKできない気が。

>>485
コーチってそういう役じゃないの？

>>486
コーチは開発サイドだよね。

>>482 つかペアプロだと相手がフレックスとか言って遅れてきたら
ペアプロできないだろ（ｗ

あと最近このスレ面白くなってきたけど、つまるところ客の予算に対する
考え方が非常に大きいと感じる。年度末決算で予算消化、とか、上期・下期で
事業部再編なんてのが当たり前だと、技術論と無縁のところで予算枠や
使い道が決まるから、XPはその辺で理解を得辛いかもなー。

要するに>>467のいうような形だと、年度内の「枠」を設定するお題目を
作り辛いから（えらいさんへの言い訳考えるの大変だわな）、開発費なのに
ランニングコストとして計上するような形になってしまうんだろうな。
稟議を通し辛いのは間違いないな。長文スマソ

「つまるところ〜」と総括的な話にすると面白くなくなるのだよ。

つまるところ、
ＸＰのユーザというのは、
プロダクトマネージャに相当する仕事だ。
作業量が半端じゃないなら、チームを構成するしかないがな。
エンドユーザという意味だけでないことは確かだ。
ドシロウトには無理というのも確かかも知れん。
というより、怖いわな。そういう仕事は。

>>482
スタンダップミーティング自体はかなり有効だと思う。
自分のなすべきタスクを把握できてないPGや新人がプロジェクトにいる場合はなおのこと。
しかし、XP自体はある程度以上のスキルをメンバーに要求しているので、
つまるところ、必須ではないと思われる。
12のプラクティスにも入ってないし。

つーか、やった方が効果あるならやればいいし、やるだけ時間の無駄ならやらなければいい。
それだけのことだと思うが。

>>488
サインアップ後、作業を始めてから遅れてくる奴はほんと困る。

ところでさ、PGが奇数だったらペアプロどうするの？
何か書いてあったっけ？

JUnitを使いたいんだけど、
解説ページない？
いまいちよくわからない。

>>492
http://objectclub.esm.co.jp/eXtremeProgramming/TestInfected-J.html

>>457
>機能と品質を混同してるような。

いい返しを思いつかなかったので、外部品質としてみました。

>そもそもXPでちゃんとテスティングとリファクタリングの過程を経て作られたプロ
>グラムに品質1/2なんてあり得んのだが。

もしXPが他の手法にくらべて効率が上がる場合、その品質保証によるところが
大きいと思うので、1倍の品質で効率だけアップっていうのもありえないと思うのです。

＞もしXPが他の手法にくらべて効率が上がる場合、その品質保証によるところが
＞大きいと思うので、

なるほど。ってものわかりよすぎ＞俺

>>495
このスレ、２ちゃんのスレにしとくの勿体無さ過ぎ（ｗ

http://diary.cgiboy.com/d01/tsugeikuhito/

29は豆の皆○わ だ。

>>488
＞考え方が非常に大きいと感じる。年度末決算で予算消化、とか、上期・下期で
＞事業部再編なんてのが当たり前だと、技術論と無縁のところで予算枠や
＞使い道が決まるから、XPはその辺で理解を得辛いかもなー。

顧客から見ればXPは予算内で顧客＆開発両者がベストを尽くすわけだから、
ある意味ぴったりという気もするけどね。従来のように必要な機能とその実装
にかかる費用を加算して金額を決めるよりは。従来の方法でも、そこから予算
に合わせて機能の取捨選択を行って発注するのだから、最終的には同じ結果
になるはずだが。（もちろん違いは機能の決定を最初にするか、開発途上で
するかだ。）

ま、顧客＆開発とも「仕様はこうですから〜」という安易な逃げが使えなくなるの
だから、常にエキサイティングなものになるだろうね。良くも悪くも。

今だ！500ｹﾞｯﾄｵｫｫｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;

＞>電車の中吊り広告が気になったので初めて東洋経済を購入しました。特集は
＞
＞>です。いろいろ面白いことも書いてありますが、そことなく強調されているのは
＞>「ビジネス主導で開発を進めていくこと」です。
＞
＞みずほの場合は、むしろビジネス主導というか発注側の都合優先で失敗した例
＞だと思います。
＞
＞システムダウンなどの動作しないという種類のトラブルを回避するだけなら、
＞ビジネス主導よりも技術主導の方が確実性が高いです。

相変わらず馬鹿の一つ覚えでつまらん。うぉっちする気力を萎えさせる作戦か？

東洋経済の話は合併に伴う勢力争いよりもビジネスを重視しろって話なんでは
ないのかね。読んでないから確かなこといえんけど、記事の紹介を読む限りは。

少なくともHAMAIタンがいうような技術よりもビジネスを優先させろなんて話じゃないだろうし。

>>499
> ま、顧客＆開発とも「仕様はこうですから〜」という安易な逃げが使えなくなるの
> だから、常にエキサイティングなものになるだろうね。良くも悪くも。
顧客は常に「仕様とはかくあるべきだ」と提示し続けなければならないし、
開発は常に「その仕様を実装するのにはどれくらいかかるのか」を見積もり続ける必要があるね。

今まではそれらはＳＥというある種の独裁者が決定していて、顧客は納品物、
開発は仕様書を口をあけて待っているいわゆる「専制政治」だったからね。

個人的な妄想を行うと、ＸＰは貴族政治、開発とテスタが分離していない、
立法を顧客が行い、行政を開発が行い、司法をテスタが行う３権分立が
俺の理想と妄想してみる。

>>502
＞今まではそれらはＳＥというある種の独裁者が決定していて、顧客は納品物、
＞開発は仕様書を口をあけて待っているいわゆる「専制政治」だったからね。

おかしいな。専制政治の方が効率が機動性があって効率もいいはずなんだが。
といってみるテスト。

＞人的な妄想を行うと、ＸＰは貴族政治、開発とテスタが分離していない、

XPは原始共産制じゃないのかね。
ウォーターフォールは良くも悪くも官僚主義にどっぷり使った民主主義だと思うよ。
それとも立憲君主制かな。

＞立法を顧客が行い、行政を開発が行い、司法をテスタが行う３権分立が
＞俺の理想と妄想してみる。

俺の感覚では首相がSEだと思うんだけどね。民主主義の場合権限が大きければ
大きいほどそれを実際に行使する自由度は少なくなる。SEにもPGが思うほど自由度
はないよ。

> おかしいな。専制政治の方が効率が機動性があって効率もいいはずなんだが。
> といってみるテスト。
「優秀な」専制君主の場合は効率も機動性も高い。
なぜなら自分＝顧客であり、自分＝開発者だから。

> ウォーターフォールは良くも悪くも官僚主義にどっぷり使った民主主義だと思うよ。
> それとも立憲君主制かな。
現在のウォーターフォールは立憲君主制説に１票。
特にこの板で「Ｓヨ」と呼ばれる人は君臨するだけで
統治はしていないのではないかと思う。

> 俺の感覚では首相がSEだと思うんだけどね。
仕様の決定　＝法律の決定権
仕様の実装　＝法律の執行
仕様のテスト＝法律のチェックと考えていたのでそれでは違和感がある。

>>499

XPは受託よりも派遣として扱ったほうがギャップが少ないと思われ。
チームごと相手会社に派遣ですな。作業場所は自社のままだけど。

ずいぶんいいスレになったな・・1weekで・・・

つまるところスレにもイテレーションが大切ということか

XPは派遣か。考えようによっちゃそうかもね。時間で拘束して
作業内容は顧客の言いなりだから。

だから40時間労働なわけだ。

Σ(ﾟﾛﾟ;)ｶﾞｰﾝ

>>507
スレにもリファクタリングが必要かといってみるテスト。

>>508

真理かも知れない・・・と思うと萎えー(w

ということでXPは派遣社員の管理に有効であるとの結論がでました。
同じ会社から集団で派遣にくるやつららにXPを実践させてみてください。

>>513
集団で派遣にくるやつらに知識が蓄積
↓
開発完了
↓
そいつら撤収
↓
ドキュメント残せや、ｺﾞﾙｧ!!

だめだ、こりゃ。

>>514
逆に独りで XP やる場合を想像してみれ。

>>514
顧客からみたらドキュメントのない成果物は、それと同じでゴルァなんだけどなぁ。
ま、派遣の場合保守契約が出来ないから、その点が違うか。でも発注先がつぶれれば
同じこと。

>>516
しかし顧客でどれだけ真面目に ﾄﾞｷｭﾒﾝﾄ 読んでるのか？と言って見るテスト

>>517
そりゃ必要になるまで読まないんじゃない？
俺もソフトのドキュメントとかは必要になるまで読まないし。

XPを使えば「僕は先のことをちゃんと考えて〜してるんです」とかいう
小生意気なPGを黙らせることが出来るってホントですか？

>>511
レスはユニットテストを通してから書き込むべしと逝ってみるテスト

>>501
案の定[XP-jp:03486]で突っ込まれてるし。必死で「僕のいうことが正しいんだぞー」とか
わめいてるガキだな。HAMAIは。

リファクタリングすると確かにソフトウェアの保守能力は向上すると思われますが、
やはりパフォーマンスが落ちるという問題がありますね。
VC++ なんかだと国内版でもプロファイラはいくつか出てますが、
Delphi のプロファイラでお勧めのやつはありますか？できれば国内版がいいのですが・・・

>やはりパフォーマンスが落ちるという問題がありますね。
ハツミミです。ほんと？

>>522
なんでやねん。説明きぼーん。つーかどういうリファクタリングやったの？

>>523
リファクタリング以前のソースは、１メソッド300行程度はざら。
凄まじいのは　１メソッド 800行以上ってあったっけか。しかも 条件分岐の嵐 （ｗ
構造化型の可読性無視速度重視のロジックを

１．メソッドの徹底分割→当然CALLのオーバーヘッドが発生。
２．グローバル関数のメソッドオブジェクト化
３．一時変数の徹底削除によるメソッド、プロパティ呼び出しによるオーバーヘッドの発生。
４．パターンの導入によるクラスの大量発生（爆発まではしてない）
　　それに伴う生成と破棄のオーバーヘッドの発生。

としましたッス。

ファウラーもこの問題は「リファクタリング」のなかで挙げてますね。
最終的に可読性が増す事により、真のオーバーヘッド発生箇所が
容易に追跡できるようになるとは述べているが、他のツールだとプロファイラは相当あるようですが
どうも Del だと国内ではプロファイラはないようで・・・

>>525
盲目的に行うパフォーマンス落とす様な変更はリファクタリングとは
言えないと思う。

>>520 レス書くときは、やはりペアレスか？

>>525

＞リファクタリング以前のソースは、１メソッド300行程度はざら。
＞凄まじいのは　１メソッド 800行以上ってあったっけか。しかも 条件分岐の嵐 （ｗ
＞構造化型の可読性無視速度重視のロジックを

メソッド呼び出しのオーバーヘッドは相当な頻度で呼び出されるメソッド以外、
無視できると思うけどね。たとえば気にしなきゃならない相当な頻度とは
たとえばビットマップデータを1ピクセルごとに処理する部分とか（ｗ

ま、そのメソッドが1秒間に何回ぐらい呼び出されるかは、リファクタリング
中も気にしたほうがよいと思われ。たとえば1秒間に高々1000回のメソッド
と100万回のメソッドを同一のポリシーでリファクタリングは不可と思う。

800行ってのは論外だけど。なんだそりゃ（ｗ

＞１．メソッドの徹底分割→当然CALLのオーバーヘッドが発生。

だからよほど高頻度で呼び出される処理でなければCALLのオーバーヘッドは
それほどないはず。

＞２．グローバル関数のメソッドオブジェクト化

これも同様に普通は影響ないと思われる。

＞３．一時変数の徹底削除によるメソッド、プロパティ呼び出しによるオーバーヘッドの発生。

ここが重要だと思う。一時変数を徹底削除というのは無謀だと思う。
使用頻度を考えないと。何も考えず「機械的に」何かやるのは
リファクタリングではない。

＞４．パターンの導入によるクラスの大量発生（爆発まではしてない）
＞　　それに伴う生成と破棄のオーバーヘッドの発生。

生成&破棄のオーバーヘッドは非常に大きいから、高頻度で実行される
部分は使い回しをする必要があると思う。可読性とパフォーマンスのバランス
をとるときに一番注意しなければならない点。

アスパラタンのサイトから。
http://tcup7006.tripod.co.jp/aspara_2000/bbs

やはりXP信者さんは高慢な口調が抜けないようでうねぇ。
HAMAIタンとアスパラタンの議論を見てみたい（ｗ

残念ながら削除前の発言は保存してない。

--------------------------------------------------------------------------------

Ｒｅ：やれやれ　投稿者：アスパラ（管理者） 　投稿日： 5月28日(火)09時45分13秒

「ヴォケ」とか書いたら消されるのは当たり前です。

この誰でも解かりきった記事と「ＳＥ的視点」、それから「ＸＰ」と
どのような関係が御ありだと考えますでしょうか？
何故これが「ＳＥ的視点」なのか解からないのですが・・。

記事に挙げられたこれらの問題を解決するには
どのようにしたら良いと思われますか？
あなた自身の御意見を具体的に意見をお聞かせください。


ＳＥといっても、ピンからキリまでいますので・・・。
半分以上は一般人かプログラマらしいですね。



--------------------------------------------------------------------------------
やれやれ　投稿者：ＸＰ信者 　投稿日： 5月28日(火)07時47分13秒

消しちゃったな（苦笑）。
http://www.cqpub.co.jp/dwm/column/ito/dwm0039itom16.htm

ＳＥ的視点はこういうものだ。
乖離しないよう注意しなさい。

でうねぇage

-------風俗の総合商社・ＭＴＴどこでも-------

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！
●楽しく遊べます！　090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
　 http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入（日払い）月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://www.mttdocomo.jp/
------------------------------------------------

XP信者は2chで行儀がよくて他の掲示板では「ヴォケ」とか平気で書く不思議な人です。
地は後のほうなんでしょう。

>>528
> ま、そのメソッドが1秒間に何回ぐらい呼び出されるかは、リファクタリング
> 中も気にしたほうがよいと思われ。たとえば1秒間に高々1000回のメソッド
> と100万回のメソッドを同一のポリシーでリファクタリングは不可と思う。
後半は同意するが前半は同意できない。
たとえそのメソッドが１秒間に１億回呼ばれようが同じオブジェクトが
１億個生成されようが、まず考えられる最もシンプルな実装を行うべき。
まずは正しく動作するコードを手に入れるべきで、
チューニングは「本当に」そのコードが性能に影響を与えていることを
確認できてからでも遅くはない。

>>533

＞チューニングは「本当に」そのコードが性能に影響を与えていることを
＞確認できてからでも遅くはない。

遅いと思うけど。煽るわけじゃないので念のため。
パフォーマンスをまったく無視したリファクタリングなど現実的に意味ない。

もちろん実行頻度が1000か1000000かも予想できない（低い）レベルの人
なら確認しながら進めるのに賛成だけどね。そんな人に実行頻度を
意識してコーディングしろなんていった日には、見当違いなことやりだすから。

いいたいことは1000か1000000かの見当ぐらいはつけるべきってこと。
だいたいそれでなきゃデータをメモリに置くかDBに置くかさえ、検討が
つけられないわけだから。

ははは、アスパラたんのサイトのＸＰ信者は私だ。
２ｃｈのＸＰ信者さんとは別人だろう。

で、削除された内容は、大筋大体このとおり、

うーむ＾２
必要な分析やってるだって？
その前に基本的な分析にミスがあるだろう。

書籍と作者の関係だが、
複数の作者によって書かれる書籍がある以上、
そこは、ｎ対ｎ関係でなければならんだろう。

ちゃんと分析できているようには見えない。
それなのに、廃棄日付などの枝葉末節に行くのは
しっかりしろや、ヴォケーと言った文脈だ。

ついでに、
同姓同名の別人が作者にはある可能性が高いので、
それらを区別するために、キー指定が必要になる。

入力データの処理のところで、どちらの同姓同名を選ぶかの
選択が必要になってくるが、ユースケースにきちんと反映されているのか？

書籍データも同様で、廃却日付のようなデータが必要なら、
同じ本を複数買う考慮が必要で、
すなわち個々の本を管理する必要があって、
ＩＳＢＮではキーの役割を果たせない。

分析分析というなら、そういうところでの
コボシとかミスはまずすぎるということだ。
以下は追加。

ｎ対ｎとか１対ｎとかの関係に無頓着すぎだな。
デザイン工程に入れない分析仕様を一生懸命書くタイプだな。
ＰＧが従わないんじゃないかなぁ。

まぁ、これもあれも正規化やると決めた時点で
はまってしまった罠なんだが、
まだ気づいてはいないようだ。

>>535
漏れはそれ、正しいとおもう、が、そういうのが理解（というより実感）出来てないアスパラたんに、それをぶつけても・・・

予想通りの結果になった、というわけですな。

＞ははは、アスパラたんのサイトのＸＰ信者は私だ。
＞２ｃｈのＸＰ信者さんとは別人だろう。

いやぁ同じだと思うよ。（笑

>>535
＞ｎ対ｎとか１対ｎとかの関係に無頓着すぎだな。

ん〜単にそういった話じゃないから書いてないんじゃないの？
純粋にどう分析していくかを考えてるわけだから、分析するのが
正しいかとかは、少なくとも同じ話題とはいえないし。

あるテーマに対してはそのテーマを中心に議論すべきで、そもそ
もテーマに議論すべき価値があるか、とかは別なスレでやるべき。
さらにいえばそういったスレは元のスレの議論が一段落した後に、
一呼吸おいて提出するぐらいの心配りがほしいけどね。

これは脊髄反射のHAMAIにもいえることだけどね。

ちょっとだけ補足

>>533

＞＞４．パターンの導入によるクラスの大量発生（爆発まではしてない）
＞＞　　それに伴う生成と破棄のオーバーヘッドの発生。
＞
＞生成&破棄のオーバーヘッドは非常に大きいから、高頻度で実行される
＞部分は使い回しをする必要があると思う。可読性とパフォーマンスのバランス
＞をとるときに一番注意しなければならない点。

この部分だけは、まずパフォーマンスが悪くてもシンプルでちゃんと動く
ものを先ず作ることに賛成。

>>534

>もちろん実行頻度が1000か1000000かも予想できない（低い）レベルの人
>なら確認しながら進めるのに賛成だけどね。そんな人に実行頻度を
>意識してコーディングしろなんていった日には、見当違いなことやりだすから。

相当高いレベルの人でも、パフォーマンスにクリティカルな処理の位置を
見誤る例が、XP本かリファクタリング本に載ってなかったっけ？

>>537

＞いやぁ同じだと思うよ。（笑

別の信仰を持つ方には理解できないとは思われますが、
同じ信者にもいろいろな宗派があるのです。

>>540
例えばどの話？
あげてくれれば同意するなり反論するなりマジにお付き合いするけど。
実はこれ話題に出したかったから。

今週のいてレーションは失敗しました（・∀・）！

>>542

たぶんリファクタリング本の方だと思うんだけど（いま手元に無いので）
C3のプロジェクトで計算のパフォーマンスの原因が、特定のオブジェクトの
生成に集中してたって話。

プロファイルを取る前に数人のミーティングで想定したボトルネックは全て
本物のボトルネックでは無かった、というのが印象的だったので、
「計測してみるまでは分からない」って感じがあるんだけど。

>>544
あーそういうレベルのやつであれば、すごく残念だけど俺の方に反論の余地ない。
外から表面だけ見てあれこれ考えてるだけじゃ絶対わからないネックはある。
こういうのは実際に各所の処理時間を計測していくしかない。あれこれソースを見て当てずっぽに直していくのは具の骨頂だ。散々苦労しても全然速度が変わらない。

しかしレアケースで予測が外れるからといって最初から予想さえしないのはどうかと思う。予測は必要。予測が外れる予測も必要ってのが俺の考えだ。

それにしてもオブジェクト生成のコストは本当に予測しにくい。ある程度の規模のOOPではプロファイラが必須と思ったり。

>しかしレアケースで予測が外れるからといって最初から予想さえしないのはどうかと思う。予測は必要。予測が外れる予測も必要ってのが俺の考えだ。

予測が必要ってのは同意。
でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
方が上だと思う。
これは、表面的なパフォーマンスに囚われやすい自分を戒めるためでもあるんだけど。

>それにしてもオブジェクト生成のコストは本当に予測しにくい。ある程度の規模のOOPではプロファイラが必須と思ったり。

で、Delのプロファイラはないのか、という話に戻る…。

>>541
＞別の信仰を持つ方には理解できないとは思われますが、
＞同じ信者にもいろいろな宗派があるのです。

ﾜﾗﾀ

http://www.airclub.org/diary/

こいつでどや？　Delphi Profiler

つーことで、アスパラたんのサイトのＸＰ信者は
こちらでは、ＸＰ狂信者と名乗ることにした。

ＸＰマンセー。マンセー。マンセー。

ハイル　ベック、ハイル　ベック、ハイル　ベック。

>>548
ほーあるんだ。あとAirWebってDelphiで書かれてたんだー。2度びっくり。

＞　あきらめて、自前のデバッグルーチンを埋め込んで、プログラムの
＞どの部分に処理のウェイトがかかっているのかを探っては、パフォー
＞マンスのチューニングを行ってきたのですが、これはまるで printf で
＞デバッグを行うのと同様な原始的な方法でした（不可能ではありませ
＞んが）。そのため、僕のプログラムには 無数の EnterProfile 関数と
＞ExitProfile 関数が埋め込まれています。３０万行もあるコードになると、
＞途方に暮れてしまいます。まさに干草の中から針を探す心境です。

いやぁ、身につまされる話ですな。俺もやったよ。

じゃあ2chでは区別しやすいように「無印」と「狂」とでも呼ぼうか。

XP信者=鍋タン
XP狂信者=手タン
でいいですか？

無神論者ですが何か。
現世（プロセス）がすべてです。水が高きより低きへ流れるがごとく。

>>553

アスパラたん、いらっしゃーい！

にしても、やっぱりアスパラたん終わってるねぇ。

ドシロウトー＞アラシと決め付けられちゃったよ（笑）。
保守やったことないやつに、保守の大変さ教授されちゃったさ（シクシク）。

まぁ、プロセスだけじゃソフトウェアなんざ作れない。
机上の分析だけでソフトは作れない。
知識だけが必要なのではない。知恵が必要なのだ。

ドシロウトにはわからない領域のようだけどね（爆）。

>>555
おれはアスパラではないが、

机上の分析を研究(?)してる学生相手に、机上の分析じゃ現実の仕事は
できない、と説教たれるのもどうかと思うけど。

まぁ、どうかとは思うんだが、
ほうっておくと、そのまま変な方向走っていくからねぇ。
ちょっと修正かけてやろうかとおせっかいしてみただけさ。

分析は重要さ。だけど、それを実装コードまで落とさないと、
分析の学習は完了しない。

分析段階であのレベルのモデリングでは、
設計段階で、どんどん変な構造に行き着くのは見えているんだが？
その点どうよ？

おそらく完了しないプロジェクトになる。
例の分析マヒってやつな。

ＲＵＰには、私もしんどい思いをした経験があるので（笑）、
予定通りそれにはまることになるやろうね。
まぁ、あたたかく失敗を見守ってやるしかないかな？
予定では、そこでＸＰに改宗するんだがなぁ。
アレルギーがあるのがどうにも（苦笑）。

DBの辺りってあまり経験ないんだけどついでに聞いていい？

XPでもスパイラルでもウォーターフォールでも何でもいいんだけど、
当初の設計じゃどうにもならなくなって、あれこれ変更せざるをえなく
なったとする。

プログラムを変更は、まあさておき、DBの変更はどう考えれば
よいざんしょ？とくに変化ヲ抱擁しなければならないXPとかは、
DBの構造も柔軟に変更するのかな。

コンバーターをつくるってのが月並みな発想だと思うんだけど。
なんかそれ以外に変化に対応しやすい設計のコツとかがやっぱ
あるのかしらん？

ＤＢまわりは１４番目のプラクティス

最新のスキームで日々作業

というのが、標語。

結局、ＸＰの場合は、常にＮＯＷ　（フッルー）
Up to dateな状態が必要と考えられているわけよね。

まとめてドーンという発想は嫌われる。

>>548
おぉ！サンクスコ！！

http://www.turbopower.com/products/sleuthqa/

見にいったら QA Suite 3 が出てたね。
しかし日本語版を売り出そうってところはないのかだろうか。。。鬱
Delphi　関連のこの手のツールって、よほど売れんと考えてんのかね？

>>560
ついでだが。。。

> でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
方が上だと思う。

同意！
漏れ的には、リファクタリングを行なっている際には、徹底してソースの可読性のみにこだわってもいいと考えてる。
その後、パフォーマンスを計測して問題箇所をつぶして行けばいいだろうに。。。

＞> でも優先順位としては、プロファイルがとれるように、シンプルな確実に動作する設計の
＞方が上だと思う。
＞
＞同意！
＞漏れ的には、リファクタリングを行なっている際には、徹底してソースの可読性のみにこだわってもいいと考えてる。
＞その後、パフォーマンスを計測して問題箇所をつぶして行けばいいだろうに。。。

なんか微妙に違うような気が

>>562
「リファクタリング」読んでる？

>>563
でた！本嫁厨房

どこのｍｌ/bbsにもいるな。教科書の内容を踏まえた上で実践編の
話をしてる時に、教科書から一歩も出ない内容を力説してしらけさせるやつ。
HAMAIのようやつってのが一番わかりやすいが。

>>558-559
「スキーマ進化」とかってどうなのかね。
こういうのって実際に使われてるのかな。

>>563
何事も一気にやるのがXPに反しているといってる。
リファクタリングにしても可読性&パフォーマンスを常にチェックしながら行うべきということ。

濱井ってmemo-mlとoosquare-mlにも出没してるけど、やつの発言にレスが
つくのはxpmlだけなんだよなぁ。なんでだろ。

>>567
> 何事も一気にやるのがXPに反しているといってる。

なるほど。といっても XP 自体には全然こだわってなかったりして （ｗ
個人的には使えそうなプロファイラ教えてもらったんでよしとしときます。

だめだ〜。このXP信者の恩を受けた以上、お前もXP信者になるのだ〜

XPはフリーメーソン。
半分マジ

>>570
ん〜・・・と、独りで作業してるんで、ペアプロできません。
こんな漏れでも XP 信者になれますか？ （ｗ

>>568
濱井タンにも困ったもんだね。

誰かに相手してもらいたいんだよ。
2chに飽きたらmlに投稿するのさ。
きっと会社じゃ干されてるんだろうよ。

>>572
ってことは800行のメソッドも自分で書いたのか。なんとまあ。

>>575
それは4年前、今よりもっと厨房だった時代に書いたもんです。。。あぁ！

>>557

＞まぁ、どうかとは思うんだが、
＞ほうっておくと、そのまま変な方向走っていくからねぇ。
＞ちょっと修正かけてやろうかとおせっかいしてみただけさ。

アスパラタンが考察してるのは彼が言うところの

｜ファウラー氏の文献、「分析パターン」やら「エッセンス」などの、
｜良い設計では、属性を書き出してから判断基準に基づいて分割せず、
｜実体のみを直感的に分割してしまうという、離れ技をやっている。

この「直感」の部分を人間が頭の中でどう処理しているのか？
って部分だと思うよ。要件の分析じゃなくて分析を行う人間の
思考の分析。

引用部分が正しいとも思ってないし、彼の考えを支持するわけでもないけど、
まあ”研究”テーマとしては面白い。いまの延長で何らかの成果を残せるかも
懐疑的だけど、研究しちゃいけないわけじゃないし。

＞分析は重要さ。だけど、それを実装コードまで落とさないと、
＞分析の学習は完了しない。

彼がしたいのは学習ではないんでしょうな。きっと。

＞分析段階であのレベルのモデリングでは、
＞設計段階で、どんどん変な構造に行き着くのは見えているんだが？
＞その点どうよ？

くりかえしになっちゃうけど彼がやろうとしているのはデータの
モデリングじゃなくて、人間の分析のモデリングではないかと。

＞おそらく完了しないプロジェクトになる。

だから完了なんてするわけないし、完了するか否かなんてのは
眼中にないんじゃないかと。

＞例の分析マヒってやつな。

そうね。同じプロジェクトのメンバがこんなこと考えてりゃ、
ひっぱたいて目を覚まさせるけど。

＞ＲＵＰには、私もしんどい思いをした経験があるので（笑）、
＞予定通りそれにはまることになるやろうね。

設計＆実装にたどり着けばそうなるだろうね。

＞まぁ、あたたかく失敗を見守ってやるしかないかな？
＞予定では、そこでＸＰに改宗するんだがなぁ。
＞アレルギーがあるのがどうにも（苦笑）。

いやいや、一度や2度の失敗でへこたれるようじゃダメ。
なんどもなんども失敗を繰り返し反省を繰り返し、どんなに
時間と情報と知能があったところで、人間の分析&設計能力には
本質的に限界がある、と絶望しないとね。そこからが出発点。
それでこそ筋金入りのXP信者に（ｗ

ＤＢまわりの設計。

基本的にＳＱＬはあまり多用しないほうが、ＯＯＰでは楽だね。
ＲＤＢは、ＲＤＢでＥＲ図に発展してくわけで、
ＥＲ図は、ＵＭＬのクラス図だから、自然な対応関係はある。

そこを基本におさえた上で、クラス定義を行う。

で、単にＲＤＢは、シリアライズ（あるいはPersistant Object)コンテナ
だと思って扱うのが、僕の趣味だなぁ。

これで、きっちりクラス定義しとけば、
単純なスキームの変更はじょじょに対応可能かと。

じょじょに変更していく、いっきにドーンを避ける。
やる前とやる後にバックアップをとる。
やる前とやった後で動作に違いがないことを
確認するためのテストプログラムを書く。

こんなとこじゃない？ＸＰスタイルは。

ところでリリース間隔はどうなってるの？
運用ＤＢをどーんはやっぱり怖いと思うよ。
特に、ＳＱＬをばらまいた設計やってると。

だから、データ構造設計は、きちんとという
分析屋の意見にも一理あるわけだし。

、

オレがＸＰ狂信者になった理由だけど、
話題だからという理由で本を買って読んだわけさ。

微妙に近いところにいながら、オレさまには欠けているポイントを
いくつも羅列させられていて頭痛くなったのさ。

ところが、どれもこれもよく考察していくと、
「おばあちゃんの知恵」なんよねぇ。
そういうことぐらいは理解できる賢さはあったので（自爆）
もう参りましたさ。
今ではぞっこんラブラブです。

ＸＰには知識はそんなにはない。
でも、知恵の宝庫なのだ。

結局、ここにつきるのよね。

>>577
了解。わかったよ。
結局、若いってことなんだよね。
大昔コンピュータを勉強しはじめたころ、
全てが計算できると信じてた（爆笑）。
数学の定理をコンピュータでばんばん発見できると思ってた。

彼の場合は、それが全部自分の頭で分析できると信じているわけだよね。

おれは、将棋もやるんだが、せいぜい１５手ぐらいの詰め将棋解けるぐらいさ。
でも、２００手以上の詰め将棋解けるプロ棋士ってのもいるわけで、
アスパラたんはそれになろうとしているらしいってことかね（苦笑）。

右脳の使い方が下手そうなのが危惧している部分なんだけどね。

ageとこ

>>580

漏れは青木淳さんの本に引用されていた
「デザインはフォルムの実現にあるのではなく，『ぴったりしないもの』の排除にある。」 ----Alexander
が転機だったよ。

bestは得られない。できるのはbetterの積み重ね。

>>576
プロファイル&チューニングに成功したら、どんなとこがネックになってたのか
レポートきぼん。

あとオブジェクトの生成のコストを避けるための使い回しとか
単純なメソッド呼び出しのオーバーヘッドの削減は、将来的には
言語自身が行うべきと思う。オブジェクトのキャッシング（？）

CやC++の場合プログラマが行っていたオブジェクトの解放を
javaとかが自動で行うように。（まgcの技術は大昔からあるわ
けだけど。）

10年ぐらいしたらオブジェクトのキャッシュはシステムに任せるか
プログラマが行うべきかの論争が起きたりして。

＞右脳の使い方が下手そうなのが危惧している部分なんだけどね。

漏れもそう思う。（右脳/左脳って言い方は好きじゃないけど）

ところで、ＣＭＭに詳しい人に質問だが
アスパラたん、
ＰＳＰで１万行っておっしゃってますが、
一日で一万行の意味？
どのくらいの期間の話？

一万行って、別に設計書いらない水準の話だけど、
そんなにプロセスいるんだっけ？
あー、わからん（＾＾＾；
そんな大げさな話なの？

>>583
りょうかい〜ん！！
ちゅうても QA Suirt すんなり導入できるんだかは未定だったりして（ｗ

ここは宗教ｽﾚですか？信者ってナニ？狂信者って狂ってるの？

合理的な判断努力の積み重ねだと思うけど...。
合理的な判断の結果信者になるのは、敗北だと思うが。

俺が個人で書いた最大はだいたい200万行。半年かけた。（過去に書いた
コードを流用した部分もあるある。）プロジェクトに参加したのは俺一人では
ないが、主要コードの大半は俺が書き、残りもすべて把握していた。

そのうちUIや単純なデータ処理の部分（早い話コピペ＆手直しですむ部分。
処理は複雑ではないが量がかさばる部分。)は1/3ぐらい。後はアルゴリズム
が売りの部分。（どういった分野かは話せないが）

顧客は非常に優秀でかつ協力的。要求分析やアルゴリズムについても相互に
相談しあえる良好な関係だった。これは俺ではなく顧客の人徳に負うところが多い。
打ち合わせは頻繁に行われ、（アルゴリズム勝負のソフトゆえ）常に試行錯誤の
繰り返しだった。

そのプロジェクトは成功した。が、はっきりいえば自分の頭の限界を自覚もした。
どうがんばってもこれの10倍のコードは自分の頭に入りきらないだろう。コード
のすべてを把握し高い機動性をもって仕様変更に柔軟に対応することは、一人
の人間では（時間の制限がなくても）無理だ。と。

一般に開発は少数精鋭の方が効率がよいといわれている。俺もそうおもう。
しかしどうなのだろうか？時間さえ無限にあればどんな大規模かつ複雑な
ソフトでも、少人数で開発可能なのだろうか。

人間の頭の中に入りきる容量には限界があり、それを一次キャッシュとみな
せば、それを上回る規模のソフトは、効率が落ちるのではないだろうか。

XPでしばしば、少人数でも徐々に拡張していけば大規模なプロジェクトも
可能ではないか、という。自分のつたない経験でそれを否定するつもりはな
いが。。。

>>586
1万行か。個人で請け負うなら手ごろな大きさだね。

イテレーションを繰り返せばXPで大規模ソフトも開発可能なんて与太話
信じているやつはいない。

>>590
そうそう、その手ごろな領域のところだよね。
まぁ、標準プロセスなんだから、
そんな大げさな話はあるわけもないとも思うのだが、
ちと志が低すぎないかと（苦笑）。

スペースシャトルのソフトは420,000行らしいよ。

>>593

そんなに少ない行数なの？ すごいなぁ〜。
スペースシャトルの空調管理システムのソフトとかじゃないよね？
つーか、ソフトって何をさしてるの？　システム？

行数が少ないほうが安全なんだろ。

漏れだったら、可読性の良いシステムに命をあずけるけどな。

スペースシャトルって行数あたりのコストがものすごく高いんだったよね。

>>593
あれって5台ぐらい同じ処理するコンピュータのせてて多数決するんじゃなかったっけ。

＞5台ぐらい同じ処理するコンピュータのせてて多数決
アウトプットは同じだと思う。

>>598
ん？どういう意味？故障とかバグを多数決で回避するってことだよ。

CMMで開発されたシャトルとXPで開発されたシャトルのどっちに乗りたいですか？

大気圏外は宇宙線による誤動作がすごいからね。

>>600
どっちでやっていようが、ソフトウェアテストは、通常のアプリのそれとは全く比較にならんよ。

そういやNASAが保守部品として8086をかき集めてるよね。PC9801のV30でもいいのかな。

>5台。。。

科学者としてのスペースシャトル、母としてのスペースシャトル、以下略としての
スペースシャトル、極寒ネタとしてのスペースシャトル。。。

>>604
なんと・・・NASAって実は「補完」を企んでいたのか。

>>593
原発もそうだけどそういった人命に関わるシステムは
ソフトは限りなく少なくして、
多重冗長化構成にしたハードによってリスクを抑えてる。

>>605
密かに エヴァシリーズ を開発しているという話もある。

惑星間ネットワーク（とりあえず地球と火星だったｋな）の構想を
練ってるワーキンググループがあったような。

地球と火星でペアプロするにはどうすればいいんですか？
リアルタイム通信がだんだん辛くなってくるんですけど。
てゆーか日本<->アメリカでペアプロするには？

>>604
自爆装置は5台が一致しないと作動しない設計ですか？

>>609
どこでもドアー 常時接続バージョン を使いましょう。

>>611
漏れはまだ深夜のどあほーだいなので、昼間は接続料金が気になります。

>>609
日本伝統のプロトコル、以心伝心と阿吽の呼吸を使います。

>>600
XPだな

>>613
そのプロトコルにはまだ国際化対応の部分にバグがあるそうです。

>>614
顧客がストーリーを書き忘れたので、そのシャトルには帰還プログラムが実装
されていなかった。キミは軌道上をさまよう人工衛星となった。

-- Game Over --

XP（狂）信者の人にお伺いします。HAMAIタンとアスパラタンで
ペアプロさせるにはどうしたらいいでしょうか。

改宗させる。

http://www-6.ibm.com/jp/developerworks/java/020125/j_j-diag0911.html#8

の記事で、

>そして、この疑問に代えて、「どうしたら、テストできる方法でこのコードを書け
>るか？」と自分自身にしばしば、テストを容易にするという目的だけに寄与する
>機能を多く追加することになります。

というのがあります。

個人的には、テストのみにしか使用できない機能を付加するのは非常に抵抗が
あるんですが、テストのためのテストって気がしませんか？

テストをし易い構造にするってのが正道だとは思うんですが。

プログラムの品質って、どうやって計るの？、どうやって見せるの？

>>619
テストしやすい構造にするってのと
テストのみにしか必要のない機能を追加するということは
同じことだと思っている。

テストが容易になるのなら構造をバンバンいじるべき
最初は抵抗があったけどね。

>>620
その辺のまっとうなプログラマに見せれば、それなりに判断してくれると思う。
何らかの手法で計測したくなったりするかもしれないけど、
それは悪魔の囁きなので気をつけること。

>>620
顧客が「使える」と思うかどうか。

テストコードを埋め込むってのは、突き詰めれば、起こりえないはずの状態が起こるか否か
をチェックすると思う。アサートとかはね。

外部のテストコードによるテストは、起こりえるすべての状態においてプログラムが期待通り
動くか否かをチェックする。

性質的に一方が他方で代用できるものじゃないと思うけど。

事前条件、事後条件、不変条件とかはコンパイラがすごく賢くなって、これらの静的な
整合性のチェック（方チェックみたいに）まで出来るようになると面白いんだけどね。
これにはまだ時間がかかりそう。

方チェック->型チェック

品質=（稼働時間）/（クレーム数）

ひゃひゃひゃ。（クレームゼロの場合困るな。）

>>617-618
改宗しても一日の大半はお互いの価値観の議論に消費されそうだ。
一般に別々の人間が本当の意味でペアプロできるほど価値を共有する
なんてことはありえん。ペアプロがうまくいくなんてのは、所詮ごまかしだよ。
まあ、そうなると結婚なんてのもありえないはずだけど、それはごまかしの
許容範囲内ってことだな。

つまり相性がよい相手としか開発できないわけだよ。小学校で好きな人と
グループを作りなさいってのとおんなじ。そのうち仲間はずれにされて
「会社がXPを採用したため不当な精神的苦痛を受けた。XPは労働基準法
違反である」とかって会社が訴えられたりして。

＞まあ、そうなると結婚なんてのもありえないはずだけど、それはごまかしの
＞許容範囲内ってことだな。

なるほど、面白い結婚観をお持ちですね。
続きは、結婚板で議論しましょう！！

>>623
テストを容易にするための機能であって、アサートじゃないのでは？

あと、勝手にアサートしてくれるコンパイラがあるということは、
コンパイラがプログラムの文脈を理解するということで、
大部分のプログラマが必要なくなる一歩手前なような気がする。
俺はとても困ります。

>>628

文脈の理解は必要ない。そんなことが出来るならAIとかの話になっちゃう。
俺が言ってるのは前段のメソッドの事後条件が後段のメソッドの事前条件と矛盾しないか否かのチェック。
矛盾すれば間違っていることがわかる。矛盾しないからといって正しいとは限らないって程度の話。

>>629
Eiffel や D みたいなやつ？

>>628
テストを容易にするための機能ってのは、あとどんなものがあるの？

>>630
そゆこと。

>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を使用
してテストするのでは、意味合いが異なると思います。
これは、自分が組み込み系のせいで、リリースコードにテストコードを入れてお
きたくないという想いが強いせいかもしれません。

>>633
テストも製品の一部であると考えれば、
パフォーマンスに影響なければテストがしやすいように
テストのみにしか必要のない機能を追加することに躊躇すべきではないとも言える。
機能追加を避けることでテストが不十分になる可能性があるならね。

ただ、「テスト・コードの製品コードからの分離」 を謳うならば
やはりスタブを使うのが正しいか。

>>633

＞上の記事の例でいえば、Sender、 GreeterにRecorder機能を持たせる
＞変わりに、Sender、Greeterと交換可能なRecorder機能のみを持つ
＞SenderRecorder、GreeterRecorderを定義し、Coordinatorのユニットテストでは、
＞そっちの方を使用します。

呼び出し順序がSenderやGreeterの状態に依存しないなら、それでいいと思うけど、
やり取りするデータによって流れが変わる場合、テストできないんじゃない？

そこまでシミュレートするXXRecorderをテスト用に作るんじゃ、それこそテストのため
のテストのような気がするし。

＞これは、自分が組み込み系のせいで、リリースコードにテストコードを入れてお
＞きたくないという想いが強いせいかもしれません。

俺ならそうゆー場合条件付コンパイルの方法を探すけど（ツール使うなりその他
もろもろの方法で）。けど、まずはRecoder機能をなるべく軽く実装するように努力するかな。

結婚は人生のペアプロです。（ｗ

>>625
品質 = 1 - (クレーム数) / (稼働時間)

＞呼び出し順序がSenderやGreeterの状態に依存しないなら、それでいいと思うけど、
＞やり取りするデータによって流れが変わる場合、テストできないんじゃない？

そうかも。
で、呼び出される側のオブジェクトの状態によって、呼び出し順序が変わらないように
するのがテストしやすい構造なのではないかと。

そして、テストしやすい構造を目指すと、自然に良い構造になる効果があるのでは
ないかと期待しているのです。

＞そこまでシミュレートするXXRecorderをテスト用に作るんじゃ、それこそテストのため
＞のテストのような気がするし。

そこまでして、その部分のテストを重要視していることが示せていいんじゃないかなと。
屁理屈かもしれないけど。

実際に作ってみると、マルチスレッドが絡まなければ、それほど複雑なスタブは必要
ありませんし。

＞俺ならそうゆー場合条件付コンパイルの方法を探すけど（ツール使うなりその他
＞もろもろの方法で）。けど、まずはRecoder機能をなるべく軽く実装するように努力するかな。

条件付コンパイルは、その中に副作用を紛れ込ませたときに恐いので、テスト環境では
使用したくないな。
デバッグコードの分離には使うけど。

>>634
>パフォーマンスに影響なければテストがしやすいように
>テストのみにしか必要のない機能を追加することに躊躇すべきではないとも言える。

パフォーマンスの関係も、もちろんあるんだけど、例えば、テストのためだけに、
隠蔽されている内部構造を取得できるGetterを付けてもいいかとか、そんな感じ。

>>639

＞で、呼び出される側のオブジェクトの状態によって、呼び出し順序が変わらないように
＞するのがテストしやすい構造なのではないかと。

でも、それって（そういう構造に）実装するという実装の問題ではなくて、
実現する（要求される）機能によって決まっちゃうと思うけど。。。

大昔の本「Microsoft Code Complete」にもあったけど、Excelの再計算
処理を実現するとき、全体を計算しなおすと確実だけど効率が悪い。
部分的な計算だけで済ませば速いけど、バグが生じやすい。だから
Microsoftの技術者は常に両者の結果が一致するかのチェックルーチン
を組み込んで部分的な計算ルーチンのデバッグをした。といった話
が書かれている。

俺もそれをイメージしていまレスを書いてるんだけど。俺も似たようなことはする。
パフォーマンスをチューニングする時に馬鹿正直に書いた処理といろいろ小技を
使った処理を同時に動かして、プログラム自身でチェックさせる。

＞そこまでして、その部分のテストを重要視していることが示せていいんじゃないかなと。
＞屁理屈かもしれないけど。

というとXXとXXRecorderの状態遷移が見かけ上一致するか否かのテストもするって
こと？まあ、そこまでするのであればそれはそれで一理ある。でもこれはテストのための
テストだよね。

＞条件付コンパイルは、その中に副作用を紛れ込ませたときに恐いので、テスト環境では
＞使用したくないな。

副作用があるかないかをテストすべきでと思うけど。それがテストのためのテスト
ってことでいやなのかな。ま、それはそれで共感する部分もある。俺も条件付コン
パイルはあまり多用したくない。

けどどの方法を使うにしろ上に書いたようにテストのためのテストは避けられないと
思うけど。

＞パフォーマンスの関係も、もちろんあるんだけど、例えば、テストのためだけに、
＞隠蔽されている内部構造を取得できるGetterを付けてもいいかとか、そんな感じ。

というわけで俺はGetterをつけるべきと思う。例えば電気回路にもテスト用のピン
が出てるよね。

つづき

カプセル化が崩れるのは、いかんともしがたいと思うけど。コードの上でそれが
チェック/デバッグのために用意されたメソッドだってことは、コメントで伝えるか、
あるいは条件付コンパイルの記述とかで伝えるしかないんじゃないかな。

大筋テストしやすい構造にできる場合はそういう構造にするってのは賛成。
「よい設計」と「テストしやすい設計」はほとんど同義。

>>640
>例えば電気回路にもテスト用のピンが出てるよね。

なかなかうまい例えだと思う。
そこから一歩踏み込んで、テストコードを実環境での動作チェック機能としてリリ
ースコード化してしまうという手もありでは？
ストーリーカードに載せられるかどうかが微妙ではあるけど。

>>636
XPなのにデスマーチになりましたが、何か？

>>643
どういう経緯ですか?

>>644
リンク先を見てネタだと気付こう（ｗ

ＸＰなのにデスマーチが回避できないの？
ウニットテストとイテレーションが足りないのでは？

XPでペアとけんかしたときも、やっぱりセックスすれば仲直りできますか？

>>647
激しくないと効き目が無いので早急にイテレーションしてください。

>>647
まめにペアを入れ替えるようにしていろいろと共有するよう心がけましょう。

人生にユニットテストかけたら、絶望しました。どうしたらいいですか?

時には全てを破棄して最初からやり直す勇気も必要です。

>>649
まじで聞きたいんだけど、ペア同士喧嘩にならないのかな？
XPの（数少ない）レポートでも、なんかこの辺は特にきれいごとでまとめられてる
気がするんだけど。

生なましペアプロの実体レポートってないの？

・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
　インデントを書き直す。
・１日中議論だけで終わってしまった。
・１週間口も聞かなかった。
・もう2度とキミとは組みたくないといわれて落ち込んだ。
・相手は一歩も譲らず、自分はまるで相手の部下のようにはいはい従うしかない。

とか。

>>652
>・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
>　インデントを書き直す。
これはpractice説明でもいましめられてるね。だからコーディング規約を
あらかじめ統一しておくこと、と。

>>653
うーん、やっぱつっこみが入ったか。
規約を決めても、そのちょっと外側辺りでそれぞれのポリシーの相違がある
じゃん。言いたかったのはそういうこと。

ついでに追加

・あいつはいつも派手で面白そうなところを作りたがる。だけどバグだらけで
　尻拭いはいつも俺の方。
・ｘｘとペアを組むといつもどうでもいい箇所にこだわるから効率が悪くてしょがない。

>652
> ・ペア組んでる人間同士がインデントのつけ方で争って、お互い相手の
> 　インデントを書き直す。

コーディング標準の導入は当然。
インデントは、フォーマッタで機械的に整形するのが吉。
文句のつけようがない。


> ・１日中議論だけで終わってしまった。

ペアプロ中はなかった。
おそらく、”実現方法がわからないから議論する”という状況ではなく、
ポリシーの相違が問題になっている状況であると思うが、
そんな時は他のメンバーに判断を仰ぐね。
それがシンプルかどうかを基準に、客観的に判断してくれる。


> ・１週間口も聞かなかった。
> ・もう2度とキミとは組みたくないといわれて落ち込んだ。
> ・相手は一歩も譲らず、自分はまるで相手の部下のようにはいはい従うしかない。

その辺は大人だからね、普通は何とか折り合いをつけるんじゃないかなぁ。

でもまあ、どうしても合わなかったり、XPを理解しなかったりの問題児さんはサッサと辞めてもらえ
ってケント・ベックもXP本のっどこかでで言っていたような覚えがあるなあ。

あのぅ〜個人でプログラムやってますが、XPの導入は可能ですか？

部分的にならひとりでも。

ペアになった相手を説得するのも、技術（コミュニケーション）の１つでしょ。
ちゃんと理由を説明すれば、納得してもらえるかと。
それでもダメなら辞めれ。

>>659
ここ数日でいきなりこのスレ盛り上がってるようだけど、一体何が起きたんだよ〜！！！！！といって見るテスト

>>657

信じさえすれば。

いや、マジな話、XPはXPの思想に共感するかどうかで大違いだし、
便利なツールとしては使用できないと思うよ。

ただし、プラクティス自体は、XPの思想とは関係なくツールとして
使用できるから、UnitTestをやってみれ。

＞でもまあ、どうしても合わなかったり、XPを理解しなかったりの問題児さんはサッサと辞めてもらえ

相手がやめるか自分がやめるか大きな問題がある気がするが。
それともチキンレース方式で先に根をあげた方が敗者？

>>657

そして（XPをやるものが）誰もいなくなった

>>659の間違い

>662
最終的にはマネージャが邪魔だと判断した方を排除するだろ。
そこに到達するまでの過程は知らんがね。

少人数のチームで毎日顔を突き合わせるんだから、判断できないことはないでしょ。

>>655
ペアプロ強制するのは、まだ時期尚早じゃないかな？

ただ、教科書的には、
「ペアプロの原則は、頼まれたら断らない。」
だから、これを断ったり、協力姿勢が見られないなら排除でしょう。

その上で人間関係がマズイペアの場合は、
要請しないという形でクッションおいていると思われます。

多少ソロ開発の余地もあっていいんじゃないかな。
馴染むまではさ。

ついでに新入りの場合は、当然左も右もわからない状態から
スタートだから、自然にペアプロだわなぁ。

>>666
ペアプロを外すと情報の共有に激しく支障が出ると思うが。
XPはただ単にみんなが好き勝手やってるだけになるんじゃないの？

例えばｘｘの部分の追加や変更はyyさんじゃないとだめだから。。。って話に
すぐなると思うがどうよ？

そこはそれ、
ＸＰコア信者がやはり、ペアプロを要請して、
改宗させていくしか方法はないと思われ。
「ペアプロを断るな。」
最低原則はあるわけだから、後は運用でしょう？
ペアプロ実施率見てコーチは、対策採らないとならないんじゃないかな？
いずれにせよ、強制するのはスジが多少違うと思う。

>>669

＞いずれにせよ、強制するのはスジが多少違うと思う。

うーん。それは納得いかん。「ペアプロをしないならXPではない」のでは。

情報が共有されているからこそドキュメントとかにかかるコストを減らしても
よいわけで、ある部分の「担当者」が病気になったら何も進まないって
事態になるんじゃないの。

表面的な効率だけ考えれば特定の部分は特定の人が常に担当していた
方が効率がいいわけだから、歯止めがなくなれば、情報の独占の方向に
チームのチューニングが進んでしまうと思うけど。

うーん、ところで、
そのソロ開発者。自分ひとりでタスク処理できるのかなぁ？
必ずしも、効率優先じゃないのがＸＰだしさぁ。
自分以外の部分もドキュメントレスなんだよ？？

ＸＰ実践編では、受け入れテストができてなかった。
論文集では、計画ゲームが機能してないが、ＸＰ成功例というべき
プロジェクトの例が載っていた。
メタファが機能しているＸＰプロジェクトは多くないらしい。
オンサイトユーザ実施に頭痛めているのも多い。

そういうわけで理想的ＸＰプロジェクトってそんなに多くはないのでは？
やれることからやってこうよ。

ペアプロしないと、ＸＰスタイルだと開発効率は下がるのは確かなんだから、
ソロ開発でやってると、ほかの連中よりタスクポイントのあがり
少なくなるでしょ？
そこらへんが、ＸＰプラクティスの組み方の秘密なんだと思う。

＞必ずしも、効率優先じゃないのがＸＰだしさぁ。

うん。効率優先の弊害に歯止めをかけるためにいくつかのプラクティスが
用意されていると思う。ペアプロもその一つと思う。

俺の感覚では、確かに実際に2人が顔つき合わせてプログラムするのが
必要とはいわない。けど、コードや情報の独占を防止するための方法が
かなり気になる。ペアプロしないなら、ある部分を常に同じ人が担当するこ
とがないようにいっそう神経を使うひつようがあるんじゃないかな。

開発をやってればよくこういう場面に出くわすよね。xxの部分はyyyさんで
ないと直せません。けどyyyさんは今zzの部分をやっているのでそれが終
わるまでxxの部分は変更できません。xxの部分はyyyさんがうんといわ
ない限り変更できませんが、うんといってくれないので、私の作業ができま
せん。

こういった事態を防止する立場の人間がXPだといないか、極めて希薄なの
だから、こういった事態にならないようにかなり神経を使う必要があると
思うけど、どう？

＞やれることからやってこうよ。

ま、それを否定するつもりはないけどね。

おれはペアプロじゃないと不安でしかたがないです。
一人でコード書くのが怖いです。依存ぎみかも。

おれはペアプロは情報共有の効果よりも、実装が素敵になる効果のほうが
大きいとおもっているんだけど、どうだろう？理想的なプログラムなら
読めば何をやっているかは自明のはずだし。

あとペアプロとコード共有がごっちゃになってるような？

＞あとペアプロとコード共有がごっちゃになってるような？

そうだよ。だめ？

これだけだとあんまりだから、補足するけど

「コード共有」を具体的にどう推進＆維持してる？

もともとコードの所有権という概念がなく、誰がコードを修正してもよいという
やり方だったのであまり困ることはなかった。

ＣＶＳの類を使う、頻繁に変更を反映する、
変えられたくはない場所はコメントではなくテストを書く、
などですんでいる。
ひょっとしたら、幸せなことなのか？

＞もともとコードの所有権という概念がなく、誰がコードを修正してもよいという
＞やり方だったのであまり困ることはなかった。

長くやってるとだんだん「担当者」が偏ってこない？

メンバーのレベルのばらつきはどんなかんじ？みんな同じレベルなのかな。
レベルの高いメンバーがいると複雑な箇所はいつもその人が担当する傾向が
徐々に出てこない？

大統領とかの再選禁止みたいに、１回担当したら必ず次は別の人が担当しなきゃならない、
とかするといいかも。

そんなんじゃマジで布石を打てねえな。ホントにその場その場のタスクを
わき目も振らずにコーディングするだけ。それがXPの姿なんだろうけど、
そんなのやってて楽しい？

>>679
XPは悩みすぎるなって言ってるんだよ
あれはある程度のスキル保有者のチームじゃないと成り立たない
初心者だらけのXP大会ポロリばっかだョ

というか、そこの偏りがあるから、ペアプロ要請を行えると考えるべし。
「そこのところは、ｘｘさんと一緒でなければ。」
こうやって、持ち上げて、ペアプロに巻き込むのがテクニック。

これが教科書的な答えだなぁ。

自分の会社を見渡して、XPでうまくいきそうなやつってどれくらいいる？
俺の独断

上位から
1割のうち半分ははやり方さえ教えれば、結構うまくいきそう。半分は絶対XPに向かない人間。
2割はXPをやらせると、そこそこやると思うが、せっかくの主戦力が逆に低下して、会社が維持できなくなる気がする。
4割のうち半分はXPで能率アップ。半分はダウン。どっちかというとダウンが多そう。
2割はもともとだめだからXPでもやって遊んでていいよ。
1割はXPの真似事も無理。勝手に暇つぶして。けどXPで大化けする人も中にはいるかもしれない。

>>681
XPはペアプロの狙いがいまいち整理できてない気がする。
　情報の共有
　教育
　コードの品質アップ
これらがないまぜになってる気がする。俺のXPに対する理解が浅いからかもしれないが。

>>677
実際には全員がすべてのコードを把握しているわけにもいかないので
担当者みたいなものは出てきます。そのほうが効率いいだろうし。
ただしそのことに対して「所有権」みたいなものを主張することは、
なんというか、文化として許されていません。特に制度的なものはないっす。

ただ人のコードを勝手にレビュー、リファクタリング、テストを行う人が
それなりにいるので、所有化の歯止めになっているのかも。

スキルはそれなりにバラけているだろうけど、あんまりな馬鹿は
チームにいれないようにしている。

もうひとつは、パワーの落ちた経験豊富な古株の再利用効果。
体力的に落ちてきているので量は無理なんだが、
若手とかませることで、作業量を増やせる。

まぁ、ＳＥとＰＧがべったりでコーディングしていると見れば
ペアプロってのは、あながちひどいもんでもない。
（異常な形態に見えるけど。）

ついでに、ソーシャルな部分の教育効果もあるので、
自然に、対人関係的、管理的職務に対する準備効果もある。
限界まで自分の能力を使い切る必要もないし、
Ｈｅｌｐを通じて、別のスキルを磨くこともできる。

ペアプロに隠された意味は結構深いものがあるよ。

>>684
>実際には全員がすべてのコードを把握しているわけにもいかないので

全員が把握している必要はないと思うけど、複数の人が把握している必要は
あるよね。

>担当者みたいなものは出てきます。そのほうが効率いいだろうし。

短期的な効率だけ考えれば、共同所有やペアプロとか多くは否定されると思う。
短期的な効率にとらわれず、長期的な効率のためにこれらがあると思う。

で、俺が言いたいのは特にルールとかなくても、短期的な効率に惑わされずに
長期的な効率を見据えられるものなのか？ってこと。（できないだろうといってる
んじゃなくて、質問なので誤解ないように。）

>ただしそのことに対して「所有権」みたいなものを主張することは、
>なんというか、文化として許されていません。特に制度的なものはないっす。

すばらしい。そういう考えのメンバーだけ集めたわけじゃなくて自然に
みんながそういう方向に考える土壌が生まれたの？それならうらやましい。

>ただ人のコードを勝手にレビュー、リファクタリング、テストを行う人が
>それなりにいるので、所有化の歯止めになっているのかも。

それは確かにあるかもしれないね。

>スキルはそれなりにバラけているだろうけど、あんまりな馬鹿は
>チームにいれないようにしている。

逆は？あんまり優秀だけどチームには入れられないと思う人間は
いるよね？それはやっぱ入れない？

>>685

＞まぁ、ＳＥとＰＧがべったりでコーディングしていると見れば
＞ペアプロってのは、あながちひどいもんでもない。

うーむ。なかなか考えさせられるね。

>>686
短期間でも、ペアプロ、共同所有は効果的だと信じている（信者的発言）

経験上、共同所有じゃない状態に利益があったとは思えない。
ペアプロは設計の止揚（大げさか？）と簡潔なコードによって、
短期的にも効果がある、はず。

プログラムの質 = 人間の質と考えているように見えるため、
社内から評価の良くない人もチームにいるけど、
チームでは少々性格の悪い人程度に思われているような。

ルールを守って、コードが書ければ人格的なことは
あまり気にしないようにしているけど、どうなんだろう。

>>688
>短期間でも、ペアプロ、共同所有は効果的だと信じている（信者的発言）

そういうことを聞いてるんじゃないんだけど。
元の発言全体を読めばわかるだろ？

>経験上、共同所有じゃない状態に利益があったとは思えない。
>ペアプロは設計の止揚（大げさか？）と簡潔なコードによって、
>短期的にも効果がある、はず。

同上。教科書どおりの発言にはあまりお付き合いするつもりはない。

>プログラムの質 = 人間の質と考えているように見えるため、
>社内から評価の良くない人もチームにいるけど、
>チームでは少々性格の悪い人程度に思われているような。
>
>ルールを守って、コードが書ければ人格的なことは
>あまり気にしないようにしているけど、どうなんだろう。

だから、ルールを守らないでコードを書く人の話をしてるんだけど。
そしてそのルールには共同所有を妨げる行為を陰に陽に禁止する
ものがなくても大丈夫なのかということ。
それ以外の人格なんて気にしだしたら果てしないから。

つづき

ほとんどの場合優秀な人間ほど紳士的に振舞うだろう。相手の考えを
尊重し、多少の価値観の相違は相手の判断を優先する。

問題なのは、そういう人間が、あえてこだわる箇所。めったにないことだが、
逆に言えば頻度は少ないものの、必ずある。そして紳士的なもの同士が
あえて妥協できない箇所なのだから、それは並大抵のことじゃ譲れない
部分なわけ。

その時他にこれといって明確な理由がなければ、「担当者」の意見が通るの
が最もありそうなことと思う。で、聞きたい。こうした場合「担当者」の意見を
尊重するのが妥当か否か。（優劣を決める他の条件はまったく同等とする。）

それともむしろ担当者ではない意見を取り入れるべきか。あるいは純粋に
さいころでも振って平等にするか？

担当者の意見を尊重する
　これまでやってきたのだからいろいろ経験もあり、この先いろいろ考えている
　こともあるだろう。という判断。非常にもっともな話だ。けどこれを認めれば、
　今後さらに人とプログラムのその部分の結びつきが固定され、だんだんと
　ほかの人にとってプログラムのその部分に意見をさしはさめないような雰囲気
　になっていくのではないか？

あえて担当者でない意見を尊重する
　新しい考えが入って、ブレイクスルーがおきるかもしれない。しかし前「担当者」
　は不満かもしれない。また感情的なものを抜きにしても、「担当者」が暖めてい
　た腹案は日の目を見なくなる。また、こういったことが普通なら、あまり先のこと
　を考えるのは損ということになる。XPの趣旨にも沿っているのかもしれない。
　そして共同所有の精神にもそっているかもしれない。

さいころで決める
　案外これが一番平和？

そこまでいくと、ほとんどYAGNIだなぁ。
あんまり考えすぎないこと。

ペアで意見が対立するようなら、
その設計、アイデアはたいしたことはない。

全員で設計レビューの会議を行うこと。
もし、問題がはっきりしていて、解決策として適当なら支持が得られるだろう。

＞ペアで意見が対立するようなら、
＞その設計、アイデアはたいしたことはない。

それはちょっと短絡的過ぎると思う。つーかそう考えたいだけでは。

おれは案外さいころがいいんじゃないかと思ったりしてる。表面的には
何か理由をこじつけると思うけどね。

「常に担当者の意見を尊重する」も「常に担当者でない意見を尊重する」も、
予測がつくと結局人間って無意識にそれを避けるようになるから。ランダムな
要素を入れて適度にかき回したいという思いがある。

リーダーならそれをリーダーが判断すればいいけど、XPの場合リーダー
的立場の人があまりイニシアチブをとらないほうがむしろいいんだよね。
場合によりけりだと思うけど。それともこういう場合はやった方がいいのかな。

チームの誰もが賛成しないコードを作るということなら、
当然排除の対象だなぁ。
ペアで賛成しないならというのはそういう意味。
プロペラ帽をかぶるしかない。

まぁ、なんかの機会にリファクタリングされちゃって、
跡形もなくなるんじゃないかな？

＞チームの誰もが賛成しないコードを作るということなら、
＞当然排除の対象だなぁ。

しつこくて悪いけど「誰もが賛成しない」ほどじゃないときの話。

なんつーかこういうどっちでもいいようにみえる、１つ１つは取るに足らない
ような微妙な時の判断の積み重ねが、雰囲気というか文化というか、そいうい
ものを作っていくと思うんだ。

＃君の意見に難癖つけてるわけじゃないよ。レスありがとね。

>なんつーかこういうどっちでもいいようにみえる、１つ１つは取るに足らない
>ような微妙な時の判断の積み重ねが、雰囲気というか文化というか、そいうい
>ものを作っていくと思うんだ。

自分で答えているように、どっちかとかどう決める、とか決めないで、
そのチームの雰囲気とか文化に従って判断するしかないんじゃない？

サイコロで決めるって文化ならそれもそれでいいけど、別に優れているって
わけでもない。

うちなら、アミダクジだな。

じゃんけんでいいじゃん

＞サイコロで決めるって文化ならそれもそれでいいけど、別に優れているって
＞わけでもない。

さいころが文化なんじゃなくて、前担当者が同じモジュールを次も担当するか
否かの比率が1でも0でもなくて1/2ぐらい、ってなスタイルがXPにあってるんじゃ
ないのか、という話。

1だと共同所有が圧迫される気がする。0だとコードに対する愛着がなさ過ぎ。

だから、教科書的な答えで申し訳ないんだけど、
次も担当するかってのは０でもかまわないのがＸＰ。
ただし、ヘルプ要請を受け入れて、結局は半分くらいを担当するのが基本。

タスクは個人で受け入れる。
実際には、助けあって開発する。
これでペアプロを推進していこうというのが、
教科書の記述だね。