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

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

eXtreme Programming Part.3

1 :XP狂信者:02/06/10 20:44
前すれ
http://pc.2ch.net/test/read.cgi/tech/1021009213/l50

Part1
http://pc.2ch.net/tech/kako/989/989482113.html

参考
http://objectclub.esm.co.jp/eXtremeProgramming/


2 :デフォルトの名無しさん:02/06/10 20:46
乙カレー

3 :デフォルトの名無しさん:02/06/10 21:18
ハヤシもあるでよ

4 :デフォルトの名無しさん:02/06/10 21:29
エキセントリックプログラミングのスレはここですか?

5 :デフォルトの名無しさん:02/06/10 21:39
WindowsXPのスレはここですか?

6 :Coffee:02/06/10 21:47
前スレで振っといた話題、客の要求を迅速に整理する方法。語らせてね。

ステップ1:リストアップ
客の要求(現状システムへの愚痴)を、箇条書きにする。
(このとき、最低50個は箇条書きにする。)

・名前変更機能が欲しい。
・ネームスペース機能が欲しい。


7 :Coffee:02/06/10 21:50
ステップ2:プレゼンテーション(思考のフローチャート)の構築
客の前で問題を付箋に書いて、IF〜THEN関係を明示する。
ツリー状である必要はないので、可能な限りIF〜THEN関係を書き足していく。
このとき、問題の原因となる問題、問題から発生する問題に気が付いたら、
忘れずに書き足す。
最後には、矢印で結ばれた図ができる。
(実際にはホワイトボードに付箋を張って、
 矢印でIF〜THENを示すようにすると、わかりやすい。)

※小さな例
[IF 情報を整理したい。(追加した問題)]

[THEN 名前変更機能が欲しい。]
[THEN ネームスペース機能が欲しい。]


8 :デフォルトの名無しさん:02/06/10 21:52
>>4
ここはエクスクルーシブプログラミングのスレです。

9 :Coffee:02/06/10 21:54
ステップ3:最終確認
完成した図を、客と一緒に関係を読みあげて確認する。
(実際は、客と一緒に図を書くべきなんだけれどね。)
「もし 『情報を整理したい』ならば、『名前変更機能が欲しい』」
客は納得する。(しないわけがない。彼の意見そのままなんだから)
そしてこのとき、(驚いたことに!)客は自分の要求を理解する。

このプレゼンテーションが効果的な理由はこうだ。
「思考の結果でなく、思考の過程を提示している。」

これを打ち合わせの度に毎回行えれば、XPはさらに素敵な方法になると信じたい。

10 :デフォルトの名無しさん:02/06/10 22:24
ホワイトボードだと漢字が書けないのがばれてしまう罠。

11 :HAMAIタンうぉっち:02/06/10 22:31
実は、問題はそれ以前の段階にあるのではないでしょうか?

最近読んだ『はじめてのOR』(講談社ブルーバックス)という本に、
「評価は目的に依存し、目的をどう捉えるかによって評価が変わる」
ということが書かれていました。目的を正しく捉えていないと正しい
評価はできないということです。

第2次世界大戦中のイギリスにおいて、商船に対空火砲を装備すべきか
否かという問題を検討するため、対空火砲による撃墜率のデータをとった
ところ、あまりにも低い撃墜率のデータしか得られず、対空火砲は敵機を
これを無限後退といいます。
いいですね?
はーい、先生。

(省AA強化月間)

--------------------------------
撃墜するためには実質役に立たないことがわかりました。
しかし、対空火砲の目的は敵機を撃墜することではないという意見が出され、
その意見を基にデータを取り直したところ、対空火砲の有効性が立証され、
商船に対空火砲を装備すべきという結論になったそうです。


ソフトウェア開発の目的を正しく認識していないのはないでしょうか?
対空火砲の目的が敵機を撃墜することであると考えるような錯覚をしている
のではないでしょうか?


12 :HAMAIタンうぉっち:02/06/10 22:32
これを無限後退といいます。
いいですね?
はーい、先生。

(省AA強化月間)

--------------------------------
実は、問題はそれ以前の段階にあるのではないでしょうか?

最近読んだ『はじめてのOR』(講談社ブルーバックス)という本に、
「評価は目的に依存し、目的をどう捉えるかによって評価が変わる」
ということが書かれていました。目的を正しく捉えていないと正しい
評価はできないということです。

第2次世界大戦中のイギリスにおいて、商船に対空火砲を装備すべきか
否かという問題を検討するため、対空火砲による撃墜率のデータをとった
ところ、あまりにも低い撃墜率のデータしか得られず、対空火砲は敵機を
撃墜するためには実質役に立たないことがわかりました。

しかし、対空火砲の目的は敵機を撃墜することではないという意見が出され、
その意見を基にデータを取り直したところ、対空火砲の有効性が立証され、
商船に対空火砲を装備すべきという結論になったそうです。


ソフトウェア開発の目的を正しく認識していないのはないでしょうか?
対空火砲の目的が敵機を撃墜することであると考えるような錯覚をしている
のではないでしょうか?


13 :デフォルトの名無しさん:02/06/10 22:38
>しかし、対空火砲の目的は敵機を撃墜することではないという意見が出され、
>その意見を基にデータを取り直したところ、対空火砲の有効性が立証され、

ここまですればすばらしい見識だが、

>しかし、対空火砲の目的は敵機を撃墜することではないという意見が出され、

でうじうじしている限り、寝言だな。

14 :デフォルトの名無しさん:02/06/10 23:07
やつが会社でどれだけうざがられてるか想像できる。
多分会社で会話する相手もいないんじゃないかな。


15 :デフォルトの名無しさん:02/06/10 23:13
はーい、はまいたんウォッチャー御一行様、こちらですよー。

http://pc.2ch.net/test/read.cgi/prog/1023422827/


16 :デフォルトの名無しさん:02/06/10 23:38
いわゆる宇宙人はいるって立証したやつと、
宇宙人はいないとは言い切れないとかいってるやつの違いだな。

17 :デフォルトの名無しさん:02/06/10 23:41
>>15
それほど大物じゃないよ。

18 :デフォルトの名無しさん:02/06/11 01:16
前スレのこれってほとんどXP否定じゃないの?

889 :XP狂信者 [mailto:sage]:02/06/09 22:17
http://www.tech-arts.co.jp/xp/OneTeamJ.pdf

最近のBeckのユーザに対する考え方は上のとおり。
XPも色々変わっていくんだよね(^^)。

19 :デフォルトの名無しさん:02/06/11 01:30
だからXPは共産主義と同じで滅びる運命なんだよ。

20 :デフォルトの名無しさん:02/06/11 01:41
>>18
従来よりも大規模なプロジェクトに適応した変化でしょ。
バリエーションでいいんじゃないかなあ。

21 :デフォルトの名無しさん:02/06/11 02:20
つーか従来だと適応できるプロジェクトはゼロに近いと思われ。

22 :デフォルトの名無しさん:02/06/11 02:49
XPはけんとべっくタンがウォーターフォールを学習する日記でした。

23 :デフォルトの名無しさん:02/06/11 03:23
単一のユーザではなく、ユーザというインターフェイスを
満たした何かと考えるべきなのかな?
あんなの個人で満たすのむりだよね。



24 :デフォルトの名無しさん:02/06/11 03:36
XP早くも自滅の予感

25 :デフォルトの名無しさん:02/06/11 03:42

前スレの904から
>では、テスタやモデラはどこに当てはめられるか? ビジネスチームである。リリー
>スされるソフトウェアの範囲と品質によって活動に影響を受ける人々が、全員
>で情報収集、記述、検証など、とにかく何でもサポートするのである。

さて、工程表を立てようか。


26 :XP狂信者:02/06/11 05:19
>>23
いや、無理じゃないよ。
だからシステムとしていくつも作られてきているわけだ。

できあがったユーザを想定すると難しい。
でも、XPは学習する組織をもとにしているので、
ユーザ自身を教育することで、それができるようにする力がある。
コミュニケーションの力を実感している人って少ないんだねぇ。
ふーむ。

おれがあげた例だけど、あれはフルセットのXPチーム。
プログラマの人数が20とか30に増えた例でしょ。

XPチームの構成の場合、ネックがどこかによって、
当然対策が変わるわけで、ネックがユーザ側にあると
して、そのユーザの事情に応じて、予算があるのであれば、
対策をとる例だよね。

アクセプタンステストが書けないー>QAチームを構成しよう。
ストーリがまとめられないー>ユーザグループを構成しよう。
本質的なシステム要件をつかみたいー>アナリストを雇おう

こんな調子。

プログラマが5人程度なら、一人のユーザでドライブできるし、
しないと経済的にやばいでしょ。XP本が想定しているのは
そのレベルの世界。

古いたとえなんで嫌いだけど、そのぐらいの構成で、
大体、3万ステップから12万ステップを半年から1年で
最高品質で最高に有効なソフトウェアを作るためのプロセス
それがXPってことでOK?






27 :デフォルトの名無しさん:02/06/11 05:27
>(省略されました・・全てを読むにはここを押してください)

「ここ」を押したことないのは、俺だけじゃないはず。

28 :XP狂信者:02/06/11 05:27
http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.html

まぁ、いずれよせよXP創始者のお言葉だ。
こういう問題認識のある人だけXPに来ればよいよ。

ではー(^^)


29 :カイロ:02/06/11 05:33
>できあがったユーザを想定すると難しい。
>でも、XPは学習する組織をもとにしているので、
>ユーザ自身を教育することで、それができるようにする力がある。
>コミュニケーションの力を実感している人って少ないんだねぇ。
>ふーむ。

XPをドライブできるユーザーってのは実質的にSEなんだよ。
ユーザーをSEに育てるなんてことを実感できないからねぇ。
なかにはユーザーにもすごいやつがいて舌を巻くが、めったに出会わないね。

いずれにしても開発側でSEを抱え込むか、ユーザー側でSEを抱え込むかの違いだけだ。


30 :カイロ:02/06/11 05:51
XPとウォーターフォールはある点で同じ誤りを犯している。
人間の頭ではどこまで設計が可能なのか?について両方とも答えていない。
かたやとことん設計するのをよしとし、かたや設計を機械的に断片化している。

前スレでちょっといったが、どこまでを設計し、どこから先は設計してはいけないか、の
見極めがプロジェクトの勝敗を決める。ただしこの見極めの方法が体系化されていない
のが現在の不幸だ。XPはウォーターフォールに対するアンチテーゼとしてのみ価値が
ある。生みの苦しみはまだまだ続く^^;

31 :XP狂信者:02/06/11 05:59
SEに執着しているねぇ(苦笑)。
XPのユーザはプロダクションマネージャだよ。
まぎれもなくね。
それをSEの亜種だというならそうだろう。

ただ、SEには果たせない機能を要求されている

ビジネスに対する知識。
ユーザ自身の組織としての代表者としての顔。

で、もっとも求められているのが、決断力。

決断力があり、それなりに聡明であれば、
あとはどうにかなるね。

分析力は必須ではない。それはチームのほうである程度肩代わりできるから。
分析しないと決断できないって?
それは、頭が良すぎるんだよ(苦笑)。XPのユーザ向きではないね。



32 :XP狂信者:02/06/11 06:04
すまん
プロダクションマネージャじゃないね。
プロダクトマネージャだ(苦笑)。

プロダクションマネージャだと美人モデルを沢山集めてそう(^^;
そっちのほうが楽しそうな仕事ではある。


33 :カイロ:02/06/11 06:11
>>31
>ただ、SEには果たせない機能を要求されている
>
>ビジネスに対する知識。
>ユーザ自身の組織としての代表者としての顔。
>
>で、もっとも求められているのが、決断力。

なるほど。
ユーザーの代表はともかく、
君の周りにはそういうことのできないSEばかりなんだ。
ま、確かに少ないね。そういうSEは期待できないと考える
一方で

>決断力があり、それなりに聡明であれば、
>あとはどうにかなるね。

というユーザーは期待しているようだけど、なぜ?

>分析力は必須ではない。それはチームのほうである程度肩代わりできるから。
>分析しないと決断できないって?

分析できなきゃ、決断できないだろうに。誰の意見を元に決断するんだい?



34 :カイロ:02/06/11 06:12

分析できなきゃ、決断できないだろうに。誰の意見を元に決断するんだい?
↑これはユーザー側の要求の取りまとめについてね。


35 :XP狂信者:02/06/11 06:24
だからぁ、君の想定している例は、XPベーッシックの範疇外だと
言っておるでしょ。それで終わりだよ。

XPプラクティスは、開発側コントロールはほぼ完璧。
その上でユーザ側、ビジネス側の責任について明らかにしているのが特徴。
これまでのプロセスでは、ビジネスと開発の切り分けさえ怪しかったのだ。

分析は、チームと計画ゲームするときにやれるんだよ。
やらなきゃわからないだろうけど。
何でも分析して知っている人間を想定はしていない。

一番困っていることについて話してくれれば良い。
プログラマ側が、こういう案でどうだと提案するから、
「うん、それだ。」
そういってくれれば良い。
XPチームが必要としているのはそういうユーザなんだ。



36 :デフォルトの名無しさん:02/06/11 06:56
>>35
>だからぁ、君の想定している例は、XPベーッシックの範疇外だと
>言っておるでしょ。それで終わりだよ。

確かにそうだったね。ただキミがXPベーシックでの話しをしたいように
俺はベーシックの範囲外の話をしたかったりする。

異論がなかったんでコメントしなかったが

>プログラマが5人程度なら、一人のユーザでドライブできるし、
>しないと経済的にやばいでしょ。XP本が想定しているのは
>そのレベルの世界。

この辺は同意してもよいよ。この規模ならXPでも問題ない。
ただXPじゃなくてもこの規模ならうまくいくと思うけど。

ここでいうXPかXPでないかは全体設計を最初にするか否かの点。
全体設計が可能な範囲がXPの適用範囲というなら、ちょっと看板に偽りありと
思うけどね。

ユーザーの要求が確定しないからXPじゃないとだめ?
そんなユーザーにプロジェクトをドライブできるのかねぇ。
プロジェクトをドライブできるなら、多分そのユーザはやる気になれば
最初に仕様確定できると思うんだけどね。いかが?



37 :カイロ:02/06/11 07:00
つづき

>XPプラクティスは、開発側コントロールはほぼ完璧。
>その上でユーザ側、ビジネス側の責任について明らかにしているのが特徴。

その表現でいうならユーザ側、ビジネス側のコントロールに対する考察が
放棄されてるってことだよね。ま、キミのあげたリンク先にもその点が
課題として上がっているたのだから、キミはとっくにわかっていると思うけど。

>これまでのプロセスでは、ビジネスと開発の切り分けさえ怪しかったのだ。

俺がXPで気に入らないのはこの部分かもしれない。切り分けている
箇所が開発者から見て手前過ぎる。極端な話ほんとうに教科書どおり
XPをやるなら、開発者側のメンバには要求分析の能力とかが育たないよね。

それでいいのかねぇ。この考えがすでに既存の考えに毒されている
といわれればそこまでだけど。

XPだけやってると、XPでうまくいく小規模なプロジェクトしかできない開発者しか
育たないなんてことはないの?



38 :XP狂信者:02/06/11 07:28
20万行が小規模というのならね(苦笑)。
君の大規模って何?
終わらないプロジェクトのこと?


39 :腐海在住の名無しさん:02/06/11 07:50
>>37

>俺がXPで気に入らないのはこの部分かもしれない。切り分けている
>箇所が開発者から見て手前過ぎる。極端な話ほんとうに教科書どおり
>XPをやるなら、開発者側のメンバには要求分析の能力とかが育たないよね。

仕様書をSEに押し付けられるだけの開発側メンバが
クライアントの愚痴を聞くチャンスが増えるというのに?
客に仕様を全部作らせるのではなくて、
後から仕様書をでっちあげるのではなくて、
その場で仕様をタスクに分割していくのに?
それでも開発者側のメンバの要求分析の能力が育たないと?

>XPだけやってると、XPでうまくいく小規模なプロジェクトしかできない開発者しか
>育たないなんてことはないの?

逆に聞くが、
ウォーターフルーだけやってると、ウォーターフルーでうまくいく仕様変更が少なく、
設計に取れる日数が長いプロジェクトしかできない開発者しか育たないなんてことはないの?(w

結局、育たないのは、育てないからだと思う。
誰が教育係になるかで議論が発生する職場って、少ないよね?なあなあで教育係決めてない?
こういう風習がスキル低下を生む。これ常識。

40 :デフォルトの名無しさん:02/06/11 12:33
>>39
> 結局、育たないのは、育てないからだと思う。
禿胴!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

41 :デフォルトの名無しさん:02/06/11 12:36
おらおら、SE/PGネタやったらここでやったれ
http://www20.big.or.jp/~o-shin/bbs/common/complain/bbs.cgi

42 :カイロ:02/06/11 12:40
>>38
>20万行が小規模というのならね(苦笑)。
>君の大規模って何?
>終わらないプロジェクトのこと?

なんかだんだん発言内容が内容が厨房化してない?
君自身

>プログラマが5人程度なら、一人のユーザでドライブできるし、
>しないと経済的にやばいでしょ。XP本が想定しているのは
>そのレベルの世界。

とか、いろんな表現でいってるじゃん。


43 :デフォルトの名無しさん:02/06/11 12:57
XPはあくまでも少人数でうまくまわる手法だと思う。
そして開発できる規模は、その少人数のメンバー合計の力量次第かなと。

大規模なものを複数のXPチームに分割するときは、
それぞれのチーム(顧客入り)にかなりの仕様決定の裁量権が与えられないといけないので、
チームが独立した単位になるように分割しないとうまくまわらないと思うけど、その場合
チーム間の連絡が薄いことによる仕様の矛盾や重複が起きそう。

ある程度の人数で開発することになるのなら、中央集権(笑)、ウォーターフォールが適切だと思うな。

44 :カイロ:02/06/11 13:00
>>39
>
> 仕様書をSEに押し付けられるだけの開発側メンバが
> クライアントの愚痴を聞くチャンスが増えるというのに?

XPが期待してるのは顧客の愚痴を聞くことなのか?

> 客に仕様を全部作らせるのではなくて、
> 後から仕様書をでっちあげるのではなくて、
> その場で仕様をタスクに分割していくのに?
> それでも開発者側のメンバの要求分析の能力が育たないと?

うん。キミがいってるのは仕様をタスクに分解する能力だ。
俺がいってるのは要求仕様をまとめ上げる能力だよ。
これをお客にやってもらうわけだろ。

「いや、そんなことを開発者側がやってたのが間違いだ」ってんなら、
まあそうかもしれないがね。

顧客が何を一番望んでおり、本当は何を要求しているのか、
開発で一番厄介なことを、よくもわるくも顧客(もしくは顧客側が雇った
コンサルタント?)に押し付けるのがXPだ。

もしXPしかしない、という開発会社があれば社内にそういうことが
できるエンジニアは育たないし、そもそも育てないのが正しいのだろう。
したがって身近な社内ではそういう能力は学べないということだ。
学ぼうとするなら、別な会社にいくしかない。

一生プログラミングしてるなら、まあそれでいいと思うけどね。
もちろん一生プログラミングしている人生はそれなりに幸せだから、
何もわるいことじゃない。

> >XPだけやってると、XPでうまくいく小規模なプロジェクトしかできない開発者しか
> >育たないなんてことはないの?
>
> 逆に聞くが、
> ウォーターフルーだけやってると、ウォーターフルーでうまくいく仕様変更が少なく、
> 設計に取れる日数が長いプロジェクトしかできない開発者しか育たないなんてことはないの?(w

どうなんだろうね。なかなか興味深いけど。俺は今のところそうは思わないけどね。
XPでリーダーとして振舞うには偉くスキルがいると思うが、オミソ的にチームの
端っこに加わるのは、ウォーターフォールをこなしている人間なら、可能だと思うけどね。

> 結局、育たないのは、育てないからだと思う。
> 誰が教育係になるかで議論が発生する職場って、少ないよね?なあなあで教育係決めてない?
> こういう風習がスキル低下を生む。これ常識。

ん?それはどんな開発方式をとっても同じだろ?



45 :カイロ:02/06/11 13:08
>>43
>
>大規模なものを複数のXPチームに分割するときは、
>それぞれのチーム(顧客入り)にかなりの仕様決定の裁量権が与えられないといけないので、
>チームが独立した単位になるように分割しないとうまくまわらないと思うけど、その場合
>チーム間の連絡が薄いことによる仕様の矛盾や重複が起きそう。

要求仕様の決定メカニズムがXPには欠如しているからね。
これは顧客側の意思が複雑な場合にXPがうまく機能しない(と思う)のと同根だ。


46 :デフォルトの名無しさん:02/06/11 13:14
>>41


47 :デフォルトの名無しさん:02/06/11 13:26
>>43
>そして開発できる規模は、その少人数のメンバー合計の力量次第かなと。
ここだけど、ウォーターフォールではこれが単純な合計ではなく、すこし低くなるよね。

XPは仕様を随時細分化してどんどん詰め込んでスケジュールしてゆくのに対し、
普通のウォーターフォールではもうすこし大きな単位であらかじめまとめてできそうな予測に
基づいて進行する。
そういう点でXPは「作業効率は」良いよね。

この、細分化して随時数人で分担し、テストファーストのユニットテスト付きで開発してゆく手法は
ウォーターフォールに取り込んで実践してもおもしろそう。
その結果スケジュールの線は頻繁に伸び縮みするだろうけど、進捗ははっきりするし、
より現実に則したものになるわけだし。

48 :デフォルトの名無しさん:02/06/11 13:30
>XPは仕様を随時細分化してどんどん詰め込んでスケジュールしてゆくのに対し、

詰め込んでスケジュールしていくの?
なんかやだな、


49 :デフォルトの名無しさん:02/06/11 13:32
>>48
そのかわり残業なし。これ。

50 :腐海在住の名無しさん:02/06/11 13:34
>>44
>俺がいってるのは要求仕様をまとめ上げる能力だよ。
>これをお客にやってもらうわけだろ。

なんだか激しく誤解されているようだ。
俺は客の前で愚痴から要求仕様を紡ぎ上げろといっているのだよ。
開発者たるもの、「彼の愚痴」→「その理由」→「その目的」
くらいの論理的推論ができるべきではないかな。
それともまさか、仕様に関するクライアントの愚痴を聞き流すのか?

あとは、「目的」→「XP開発者側の提案」ってやればいいんじゃないのか?

>>6-9の誰かさんの発言に追加するなら、
「もし情報を分類したいなら、カテゴリ機能よりも
 フォルダ機能を実装したほうが費用が安く、効果的だと思います。」
みたいにさ。

51 :カイロ:02/06/11 13:44
>>50
>
> なんだか激しく誤解されているようだ。

失礼した。

> 俺は客の前で愚痴から要求仕様を紡ぎ上げろといっているのだよ。
> 開発者たるもの、「彼の愚痴」→「その理由」→「その目的」
> くらいの論理的推論ができるべきではないかな。
> それともまさか、仕様に関するクライアントの愚痴を聞き流すのか?

簡単にいうと、顧客:開発者が、1対多、または多対1の場合は、
そこそこまとまると思うのだが、多対多の場合にはまとまりにくいと思うんだがどうよ。

1対多はXPそのものだね。多対1は主に顧客先に出向いていろいろ意見を聞いて
来る感じかな。これが多対多ってのはなかなか難しいとおもうけどね。



52 :XP狂信者:02/06/11 20:39
ツーか、多対多の構成にした時点で負けだろ(苦笑)。
いまだにどうしてそんな構成になるのか首を傾げているよ。

制約がソフトウェア開発側なら、予算の追加で制約の緩和は可能だ。
全社的グループウェアシステムを作成という企画だったとしても、
各部単位にXPチームを貼り付ければ、1対数人にすぐ落とせる。
それで駄目なプロジェクトはどうやっても無理。

みずほのような政治的な問題を抱えているプロジェクトの解決策ではないんだよ。
XPはね。





53 :XP狂信者:02/06/11 20:43
>>47
少しじゃない、めちゃくちゃ少なくなる。
ケーススタディをしよう。

カイロはウォーターフローで行けるといったプロジェクトの例だ。
期間は半年。5*6=30人月の予算規模だとしよう。
どういう工程配分にするね?
LOCどの程度のソフトウェアを開発できる?
ちと、ウォーターフローのプロの方概算してくれよ。


54 :XP狂信者:02/06/11 20:57
>>6から9
ありがとね。
ザゴールのインタビュー技術に通じるものがあって素敵だよ。

XPのデフォルトプラクティスでは、図のかわりに
沢山のカードを使うんだ。
ひとつひとつ書き溜めていって、
全部を見渡せるようにする。
その中で一番困っている点、
今度のシステムでブレイクスルーをしたい点を
明らかにしてもらう。

そこからは、いくつかの提案と見積もりの議論をしながら、
優先順位をつけていく。

ストーリーカードを並べるときに、論理の順序関係を
顧客と一緒にみていけば、XPでもそのまま使えそうだよ。

では、また何かアドバイスあったらよろしく。



55 :カイロ:02/06/11 22:18
>>52
>ツーか、多対多の構成にした時点で負けだろ(苦笑)。
>いまだにどうしてそんな構成になるのか首を傾げているよ。

いやだから、何度も言うように顧客側の対開発者窓口が
一本化可能な否か話をしてるんだけど?

で、キミはそれはベーシックなXPではないから、とコメントを逃げてるわけだろ?

>>26
>プログラマが5人程度なら、一人のユーザでドライブできるし、
>しないと経済的にやばいでしょ。XP本が想定しているのは
>そのレベルの世界。

とか

>>35
>だからぁ、君の想定している例は、XPベーッシックの範疇外だと
>言っておるでしょ。それで終わりだよ。

とか。逃げるのは勝手だけど、それが負けとか首を傾げるはないと思うが。

キミは、結局XPでできる程度の小規模なものはXPでできるし、できないもの
はそもそもやるのが負けといってるわけだ。なんだか。。。

>制約がソフトウェア開発側なら、予算の追加で制約の緩和は可能だ。
>全社的グループウェアシステムを作成という企画だったとしても、
>各部単位にXPチームを貼り付ければ、1対数人にすぐ落とせる。
>それで駄目なプロジェクトはどうやっても無理。

例えば各部署で共通に利用する部分とかはどーすんのよ?
各部署の担当者が集まって決めるんじゃないの?部署間を
またがる稟議書の流れの構成とかは、各部署の担当者プラス
開発者(たち)とかの打ち合わせになるんじゃないの?

どうも話がかみ合わないが。。。


56 :XP狂信者:02/06/11 22:43
かみあわないのは当然だが?
XP開発者は無理なことはしないんだ。
人生ヒマじゃないからね。

XPが使えないとわかってるなら素直に撤退する。
COBOLで組み込みやるような話はそく逃げるよ。
アジャイルというのはそういう精神を含むんだ。

共通部分のフォーマット程度でそんなに紛糾するのかい?
本当にヒマというか無駄な会議になりそうだね。

もう一度言うが、XPでは優先順位がついてくれれば、
どこの部署の意見だろうがかまわない。

全員集めて話の調整する必要があるような部分は、
そんなに多いはずがない。

ソフトウェア開発の基本は、分割して統治せよ。
当たり前のお話。

もう一度聞くよ。優先順位でもめるのか?
それとも表示する情報内容程度の話でもめるのかい?
どっちなんだい?

個別撃破できない問題なのかい?
本当に何を問題にしているんだ?

さっぱりわからないんだよ。



優先順位でもめるようなら手のうちようはない。撤退だ。
画面内容程度でもめるのも







57 :カイロ:02/06/11 23:13
>>56
ふーん。画面内用程度で顧客側の部所
間で意見調整できないような客をXPは
相手にしない、と。自分たちで要求仕様を
まとめ優先順位のつけられる相手でない
と仕事をしないってことだよね。

ま、それはひとつの考えだから、いいけ
どね。

例えば部署間での意見調整はプロジェク
ト開始のごく初期であっさりついた。
順調に出発したが、途中である部署が、
やっぱりワークフローの一部を変更して
くれと要望を出してきた。それは別の部署
にも影響するものだった。

こういった変化は抱擁しないってことでいい?

58 :デフォルトの名無しさん:02/06/11 23:52
ケントが言ってたように、単一のユーザというイメージは無理があると思う。

で、いままでユーザといっていたものを要求定義チームとか、
ビジネスチームとかに置き換えてみたらどうかな?
それなりにうまくいくような気がする。

あと、要求定義の方法をうまく盛り込んだ方法論ってあるのか?
要求定義ってのは、政治的だったり人間的だったりでMethodとして
組み込むにはあまりに泥臭いような気がする。

59 :デフォルトの名無しさん:02/06/12 00:48
>>57
>こういった変化は抱擁しないってことでいい?

全然よくねーよ(w

60 :カイロ:02/06/12 01:04
>>58
>ケントが言ってたように、単一のユーザというイメージは無理があると思う。

当たり前だ。いまごろ気づいたってんだから、ケントってトーシロだね。
といってみるテスト。

>で、いままでユーザといっていたものを要求定義チームとか、
>ビジネスチームとかに置き換えてみたらどうかな?
>それなりにうまくいくような気がする。

チーム間での打ち合わせはそれぞれの代表同士で行うしかなかろう。
それで多対1とか1対多とか言う話をしてるんだが、どうよ?

ビジネスチームの代表1名と開発チームの代表1名が話しある。
チームの代表1名が相手チームの全員と話し合う。(ベーシックなXPはこうなるね。)
両チーム全員が話し合いの場に参加する。(うまくいくとは思えん。すくなくともパフォーマンスは
すごく下がるだろう)

>あと、要求定義の方法をうまく盛り込んだ方法論ってあるのか?
>要求定義ってのは、政治的だったり人間的だったりでMethodとして
>組み込むにはあまりに泥臭いような気がする。

開発なんてすべて泥臭いもんだよ。XPはその泥臭さが身上ではないの?(w


61 :カイロ:02/06/12 01:07
>>59
よくねーなら、何とか抱擁しろ。さあ、その場面に直面した場合、まずどうする?

62 :デフォルトの名無しさん:02/06/12 01:14
>>61

まずも何も、「ワークフローの変更」ってストーリーを一つ定義するだけだろ。
優先度が高いなら他のストーリを後回しにして先に片付けるだけの事。
大騒ぎするほどの事か?

63 :カイロ:02/06/12 01:20
>>62
>まずも何も、「ワークフローの変更」ってストーリーを一つ定義するだけだろ。

そのストーリを定義するのは誰かという話。

64 :58:02/06/12 02:47
>>60
ビジネスチーム(ユーザ)の代表が何人かと、開発チーム全員じゃないかな。> 計画ゲーム
あまり効率が悪いとは思わなかった。

>>63
それはさすがに最終的にはユーザ(ビジネスチーム)だろう。
政治的なこと(部署の意見の対立)はどうにもならなくない?
こちらでできることは、アナリストをビジネスチームに加えて
知恵を貸すくらいじゃないかなあ。


65 :XP狂信者:02/06/12 03:03
はぁ、本当に何言ってるんだかさっぱりわからんよね。
つーか、何でそんなとこでモメルのかわからない。
普通ありえない話を無理やり作ってるよな。

オレが言っている状況は、ごくごくシンプルだ。
営業部の代表のA君と総務部代表のB君が、
私たちのユーザだとする。

会社のシステム運営思想について、
全体会議で二人の意見が紛糾しはじめてしまう。

なぁ、対会社同士の打ち合わせの席でだぜ、
取っ組み合いやののしりあいをしはじめる会社だぜ?
素直に撤退だろ。
金払うかどうかでまた紛糾するに決まってる。

実際、ユーザの意見がかち合うのなら、
誰かまとめられる人間をユーザ代表として入れるだけだろ。
最悪社長を入れとけよ。










66 :デフォルトの名無しさん:02/06/12 03:06
>普通ありえない話を無理やり作ってるよな。

ふーん。キミは幸せな仕事してるね。
つーか君の仕事なら何も考えなくてもうまくいくんじゃないの?

67 :デフォルトの名無しさん:02/06/12 03:08
参考までに聞きたいんだけど、キミがいままでプロジェクトで苦労したところってどんなとこ?


68 :カイロ:02/06/12 03:08
66=67=俺ね。

69 :カイロ:02/06/12 03:10
>>64
>>>60
>ビジネスチーム(ユーザ)の代表が何人かと、開発チーム全員じゃないかな。> 計画ゲーム
>あまり効率が悪いとは思わなかった。

全員とは2つの部署担当の開発チーム全員ということでよい?


70 :デフォルトの名無しさん:02/06/12 03:22
XPは、タスク(要件)を提示してくれるならば、
正確な見積もりとシンプルな設計実装をすばやく提供しますよ
といった方法論なんじゃないか?

XP本をいくつか読んだ限りでは、
要件定義、ましてや意思決定については、開発者のやることではない、
と書いてあるように俺には思えた。

71 :XP狂信者:02/06/12 03:24
そんなことはない。残念ながらね(苦笑)。
ウォーターフォールがなんとか回るのは余裕がある場合だけだ。
カツカツになってる仕事ばかりなので、ヒーコラいう話ばっかりさ。

で、半年5年で君のところの会社はどの程度の規模までやるんだい?
それにしてもすごいよね。

1/3が分析でしょ。
半分はテストなはずなんだけどあってる?

設計と実装に残された時間が1ヶ月だものね。

それで、作り上げられるシステムなんて、すごく生産性低くてよい領域
に見えるので僕は逆にうらやましいね。






72 :58:02/06/12 03:38
>>69
すみません。

>全員とは2つの部署担当の開発チーム全員ということでよい?
の<2つの部署>というのが何を指すのかが理解できませんでした。

で、もう少し具体的に書くと、計画ゲームの参加者は、
ユーザ = 顧客の業務担当*n、顧客のSE、うちのSE
開発チーム = プログラマ10前後
でした。

73 :XP狂信者:02/06/12 03:39
半年5年は間違い。半年5人ね。


74 :カイロ:02/06/12 03:56
>>72
俺は>>57の後半辺りの話をしているつもりだった。

75 :カイロ:02/06/12 04:16
>>71
>ウォーターフォールがなんとか回るのは余裕がある場合だけだ。

ある意味そうだね。変化を抱擁するために(笑)あちこちに調整用の
工数を入れとかないとならない。

>カツカツになってる仕事ばかりなので、ヒーコラいう話ばっかりさ。
>
>で、半年5年で君のところの会社はどの程度の規模までやるんだい?
>それにしてもすごいよね。
>
>1/3が分析でしょ。
>半分はテストなはずなんだけどあってる?
>
>設計と実装に残された時間が1ヶ月だものね。
>
>それで、作り上げられるシステムなんて、すごく生産性低くてよい領域
>に見えるので僕は逆にうらやましいね。

要するにちんたら分析とか設計とかしてる暇があったら
さっさとコーディングしようぜ、ってことだよね。それは基本的に賛成だがね。
ある点を越えたらそれ以上時間をかけて分析や設計しても無意味だから。

だから繰り返し、どこまで設計するべきか、どこからは設計すべきでないか、
の見極めが大事だと言ってるんだがね。

で、キミがメインにしている仕事はたまたまほとんど設計する必要のない
ものが多いってことで、まあそれはそれでいいんじゃない?


76 :XP狂信者:02/06/12 04:22
あほか(苦笑)。

で、どの程度の規模のものが作れるの?
半年、5人。ちょっと教えてよ。




77 :カイロ:02/06/12 04:28
>>76
>あほか(苦笑)。
>
>で、どの程度の規模のものが作れるの?
>半年、5人。ちょっと教えてよ。

?どう答えりゃいんだ?上の方でLOCを聞いてたみたいだが。。。
XP信者なら、プログラマの成果物はLOCなんぞで測れないとかいわんの?(w

そろそろつまらなくなってきたので一旦切り上げるよ。多分お互い語ることは
語りつくしただろうから。

78 :XP狂信者:02/06/12 04:30
いやいや、LOCで図るのは本位じゃないんだがね。
旧式の人間と話すときは、LOCで話すのさ。

見積もりやったことあるなら、簡単な問題がか?
ちゃんと答えたらアスパラ君。


79 :デフォルトの名無しさん:02/06/12 04:33
>>72
>で、もう少し具体的に書くと、計画ゲームの参加者は、
>ユーザ = 顧客の業務担当*n、顧客のSE、うちのSE
>開発チーム = プログラマ10前後
>でした。

なるほど。よく見られる風景って感じだね。ちょっと多めの気がするけど。
小さな会議室だと入らない(w

会議室が小さいほど効率いい打ち合わせができる。。。

80 :デフォルトの名無しさん:02/06/12 04:50
>>78
俺はLOCでは見積もらない。各フェーズの人x月x単価が基本だ。
ま、これも当然目安に過ぎないけどね。

81 :HAMAIタンうぉっち:02/06/12 14:53

くだらねー会話。まるで「幸福とは」を話し合ってるようなもんだ。
哲学科にもソフト開発研究室をつくれよ。

-----------------------------------
>話がずれますが、ソフトウェア開発の目的は、本質的な意味では、「儲けること」
>であっても不思議はないんぢゃないかなと思います。
>
>だって金のために開発してるんでしょ。

フリーソフトなどを例外として、ソフトウェア開発の目的が「儲けること」
でないという方が不思議ですが……。

>#少なくとも管理者は。

開発担当者だって、給料やボーナスやストックオプションのために
開発しているのでは。

>#全部が、って〜と、もちろんおかしいわけですが。

「儲けること」だけがソフトウェア開発の目的であるとは言いませんが、
「儲けること」が目的でないソフトウェア開発というのはそれ以上に変です。
営利企業ではあってはならないはずです。
長期的な儲けや間接的な儲けを重視する場合は、短期的かつ直接的な儲けのみ
を見ていると儲けを目的としていないかのように見えることもあるでしょう
けど。


>だから、少ない人月(あえて、この単語を使うけど)で開発できる手法として
>XPって「経営者」層にもアピールできるもんだと思ってました。
>#ここ重要。とりわけ私には。

私はどちらかというと、XPの利点は予測困難な開発コスト開発期間のリスクを
低減できることだと考えています。

>私的には、ソフトウェア開発での失敗のほとんどは「経営」の
>失敗だと思ってるので、特にそう思うのです。

確かに、技術的原因によるソフトウェア開発の失敗というのはあまり無い
ように思います。


82 :HAMAIタンうぉっち:02/06/12 14:56
>私的には、ソフトウェア開発での失敗のほとんどは「経営」の
>失敗だと思ってるので、特にそう思うのです。

これはだな、どんな病気でも最終的に心臓が止まるから、死因は心臓麻痺ってのと
同じだな。掘り下げりゃそれなりに面白いだろうが両者ともそんなことを話すつもりは
ないだろうから。

83 :デフォルトの名無しさん:02/06/13 00:37
哲学は人の数だけあるからねぇ。
お、XPは哲学かも。

84 :デフォルトの名無しさん:02/06/13 00:44
>私はどちらかというと、XPの利点は予測困難な開発コスト開発期間のリスクを
>低減できることだと考えています。

顧客にリスクをかぶせてるだけ。そんなんで顧客つくとは、どんな馬鹿な
経営層でも思わないから、結論として経営層へのアピールにはならない。

自己中の開発者が考えるほど、世間は都合よくまわってはくれないのだよ。

85 :デフォルトの名無しさん:02/06/13 01:02
要するにチミはだめプログラマだね(・・)

86 :デフォルトの名無しさん:02/06/13 01:11
濱井はまだうだうだいってんのか?
だれか殴って来い。ろくな仕事も出来ず同僚に食わせてもらってる身分のやつが、
何えらそうなことほざいてるんだ。来期リストラ候補のトップに上がってるのに本人は
わかってるんだかわかってねーんだか。


87 :XP信者:02/06/13 01:35
>お、XPは哲学かも。

だーかーらー、以下略。

88 :デフォルトの名無しさん:02/06/13 01:42
XPは宗教なのか哲学なのか、小一時間(略)

89 :デフォルトの名無しさん:02/06/13 01:49
プログラミングは哲学です。
書かれたコードにはその人の人生が表れます。

90 :デフォルトの名無しさん:02/06/13 02:14
プログラムは著作物なんだよ
著作物は「思想」又は「感情」を「創作的」に表現したものなんだよ

も前ら「プログラム」作ってますか?

91 :デフォルトの名無しさん:02/06/13 02:26
>>89
いえプログラミングは宗教です。
イテレートのたびに魂がより高いステージに上がるのです。

リファクタリングするぞ、リファクタリングするぞ、
もっともっとリファクタリングするぞ。



92 :カイロ:02/06/13 02:34
XP自己啓発セミナー


あなたのプログラムは輝いていますか?
本当の仕様書はどこにありますか?

あなたのコメントからはあなたの言葉が全く見えてきません。
方法論の受け売りではなく、あなた自身の言葉で要求仕様を語ってください。

どうしてバグが取れないのですか?
なぜ仕様変更ができないのですか?

コスト?労働時間?効率?
あなたは誰のためにプログラミングしているのですか?

プログラムはあなたの心を映す鏡です。
プログラムがバグるのはあなたの心にごまかしがあるからです。

本当のあなたはプロセスのどこにいるのですか?
本当にあなたは必要とされているのですか?
あなたは誰(役職)ですか?

さあ、もう一度考えて見ましょう。
プログラムは誰のためにするのですか?
仕様書はどこにあるのですか?
本当にあるのですか?
あると思い込んでいるだけではないですか?
あって欲しいと思い込んでいるだけではないですか?



93 :カイロ:02/06/13 02:43
セミナーでもペアを組んだり、少人数のグループに分かれてゲームをするなな(w

94 :デフォルトの名無しさん:02/06/13 02:44
するなな→するなぁ

95 :58:02/06/13 03:34
幸いに、計画ゲームまでに要求はタスクになっている状態にあり、
やることは、タスクに対する技術的評価と大雑把な見積もり、
サインアップくらいだったので、そんなに濃い会議にする必要がなかったです。

要求定義が困難な場合においても、
ユーザが要求(タスク)を小出しにすることが可能なら、
多少の変形はあるにせよ、XPスタイルは可能だと思うんだけど、どう?

96 :58:02/06/13 04:07
半ば蒸し返しになるけれど、
要求定義自体がソフトウェア商売とはいっても
要求定義の失敗が実装に与える影響の少ないやり方っていうのは
かなり魅力的じゃないですか?

自分の見てきたプロジェクトの失敗例は、
実装の駄目さがネックになっていた例が多いんで
そう思うのだけなのかもしれませんが!

97 :カイロ:02/06/13 04:42
>>95
>幸いに、計画ゲームまでに要求はタスクになっている状態にあり、
>やることは、タスクに対する技術的評価と大雑把な見積もり、
>サインアップくらいだったので、そんなに濃い会議にする必要がなかったです。

それは喜ばしい。俺もそんな感じで進めたプロジェクトもある。
XPとは呼ばなかったけど。つーか当時はXPなんてなかったし。
最近は俺はそういう軽量なやつはないなぁ。

>要求定義が困難な場合においても、
>ユーザが要求(タスク)を小出しにすることが可能なら、
>多少の変形はあるにせよ、XPスタイルは可能だと思うんだけど、どう?

可能だと思うよ。というか開発者の立場としてなら、小規模のプロジェクト
をXPを拒む理由はない。顧客の立場では逆にXPを選択する理由が
正直見つからないね。(だからといってありきたりの利点を挙げて
反論されても困るけど。)

>>96
>半ば蒸し返しになるけれど、
>要求定義自体がソフトウェア商売とはいっても
>要求定義の失敗が実装に与える影響の少ないやり方っていうのは
>かなり魅力的じゃないですか?

ほんとうに影響は少ないの?作っていない部分は無駄にならないって
だけだよね。作ってしまった部分は作り直しになる。当たり前だけど。

従来型でも修正の入りそうなところは後半に回すとか、いろいろ
工夫のやりようはあるし、実際やってるし。ウォーターフォール型は
全盛期を超え、今後衰退こそしても発展することはないとは俺も
思うよ。でも現時点ではまだ若きXPは老いゆく巨人に勝てない。(w
いずれ老人が退場するのは確実だろうけど、その時の勝者はXPかも
しれないし、XPでないかもしれない。

詰まるところ顧客への訴求力の欠如だね。

>自分の見てきたプロジェクトの失敗例は、
>実装の駄目さがネックになっていた例が多いんで
>そう思うのだけなのかもしれませんが!

んーようはプログラマの技術力不足ってこと?
XPって見方をかえればOJTや新人研修だよね(w


98 :カイロ:02/06/13 04:49
いってみればXPってのはバブルなんだよ。実力はまだまだだ。

だからやたら煽って流行らせようとする。流行ればそれだけ多くの
知恵が終結するから、現在のXPの欠点も克服されるかもしれないって
希望を抱いてね。その可能性はゼロじゃない。だからこそバブルに
なり得る。


99 :XP狂信者:02/06/13 05:24
んー?まだウォーターフォールのほうが有利だなんて寝言いってるのか?
というより、ウォーターフォールをまじめにやってないんだろうなぁ(苦笑)。

正確に問題認識しろよ。
ウォーターフォールじゃ半年5人のプロジェクトはまわせないってな。

半年5人のプログラマを有効に使いきれるプロセスはXPだけ。

ソフトウェア工学的に言って、ウォーターフォールじゃ半年という短期間に
5人の人間を使いきることはありえないんだよ。

実際はできるやつ一人ですむしな。半年5人のプロジェクトってのは。
5人つけたというのと、5人使ったの差わかってないだろ。

だから5人使った気で終わるんだろうが、実際は相当の工数を無駄にするんだ。
それがウォーターフォールプロセスの限界だ。




100 :デフォルトの名無しさん:02/06/13 05:28
同じ 「ウォーターフォール」 という言葉だが、内容が違っている罠。

101 :カイロ:02/06/13 05:43
>>99

>というより、ウォーターフォールをまじめにやってないんだろうなぁ(苦笑)。

まじめなウォーターフォールって何よ?
ソフト開発なんざ定式化できるわけないだろ(爆笑
頭が固いねぇ。そんな固定的な考えじゃ変化に対応できないんじゃない?


102 :XP狂信者:02/06/13 05:47
あほくさ。
プロセス論も知らないのかよ。
見積もりもできないわ。すげーな、さすが政治的SEだよ。



103 :カイロ:02/06/13 05:58
>>99
>ウォーターフォールじゃ半年5人のプロジェクトはまわせないってな。
>
>半年5人のプログラマを有効に使いきれるプロセスはXPだけ。
>
>ソフトウェア工学的に言って、ウォーターフォールじゃ半年という短期間に
>5人の人間を使いきることはありえないんだよ。
>
>実際はできるやつ一人ですむしな。半年5人のプロジェクトってのは。
>5人つけたというのと、5人使ったの差わかってないだろ。
>
>だから5人使った気で終わるんだろうが、実際は相当の工数を無駄にするんだ。
>それがウォーターフォールプロセスの限界だ。

どうしても5人x6ヶ月の話をしたいようだからするけど。。。
まあオーソドックスには2ヶ月ぐらい分析&設計にかけるかもしれないね。
もちろんプロジェクトの内容によるけど。

けどこの間いるのはこの規模なら1〜2人だ。普通他のメンバは一つ
前のプロジェクトのコーディングとかデバッグとかをやってる。
顧客との仕様の打ち合わせとかはどうしても時間がかかるから(例えば週1の
ペースで打ち合わせとかね)、この2人もかかりっきりになるとは限らない。

設計からコーディング、それ以降のフェーズの以降もこんな感じで、
期間はオーバーラップするし、設計をやった人間がコーディングする
わけだから、無用のドキュメントもばさばさとカット。

コーディングの後半からデバッグの終わりにかけてが当然ピークになるから、
全員がこのプロジェクトに集中する。山を越えても散発的にバグは出るから、
ある程度の人数を残しつつ、残りのメンバは次のプロジェクトの仕様検討。

ってな具合だね。5人で平均6ヶ月程度のプロジェクトをまわしていくなら。
各フェーズ間、そしてプロジェクト間でメンバをオーバーラップさせないと
君の言うように5人をフルに使うのは無理だね。


104 :カイロ:02/06/13 06:02
>>102
>あほくさ。
>プロセス論も知らないのかよ。
>見積もりもできないわ。すげーな、さすが政治的SEだよ。

お互いの立場を入れ替えて議論する?(w

105 :カイロ:02/06/13 06:08
ところでさあ、あるプロジェクトをXPでやったとして、その後の予定はどうなるの?
少人数の会社だと、前のプロジェクトが伸びでうしろのプロジェクトの開始が
遅れると場合によっては会社の死活にかかわるよね。きちんと当初予定した
期間で顧客は切ってくれんのかしら?

106 :デフォルトの名無しさん:02/06/13 06:50
>>99
期間半年で5人のプログラマって、どういうプロジェクトかな。
うちは普通その期間なら1〜2人、多くて3人だと思う。
実際3人というケースは稀で、一人は新人教育を兼ねて、みたいな感じだと思う。
プロジェクトに関わる人数が多い場合もあるけど、それはプログラムに関係
ない部分がほとんどなんで、この話には関係ないよね?
半年でプログラマが5人も必要って事態は、デスマーチとか思いつくけど。
デスマーチを効率良く回せるのがXPってことかな?

107 :デフォルトの名無しさん:02/06/13 09:15
なんでXPの話をするとすぐに宗教論争になるんだろう。
ウェーターフォールだろうがXPだろうが、たいして違いはないと思うんだけど。
XPの最大の功績は、いままで、分析を厳密にやらずにコーディングして
うしろめたい思いをしてたのを、それでもいいじゃんとおおっぴらに言ったことにあって
それ以外にはない。

108 :デフォルトの名無しさん:02/06/13 09:19
>>107
どの辺が宗教論争なの?

109 :デフォルトの名無しさん:02/06/13 10:43
XP=デスマーチですか?

110 :デフォルトの名無しさん:02/06/13 11:49
>>109
明るく、前向きに、プラス思考で!

今朝社長に言われたろ?

111 :カイロ:02/06/13 12:26
>>107
>なんでXPの話をするとすぐに宗教論争になるんだろう。

> XPの最大の功績は、いままで、分析を厳密にやらずにコーディングして
> うしろめたい思いをしてたのを、それでもいいじゃんとおおっぴらに言ったことにあって
> それ以外にはない。

XPは「そのままのきみでいいよ、はあと」の癒し系?
宗教も癒しだからじゃないの(w

112 :腐海在住の名無しさん:02/06/13 15:00
XPの良いところは、リリース速度が速いことだと思う。
一つの機能追加のために不安定な挙動になることを容認せず、
ただひたすらペアプロ&テスト。
結果的に、「どう動くかみせて」と言われたときに、
必ず最新バージョンを提供できる。

これがソフトウェア開発を効率化することでなくて何なのか?
これが宗教?

113 :デフォルトの名無しさん:02/06/13 21:09
中間リリースをお願いすると、PGはぶーぶーいうけどXPって呪文を唱えると、
好きになるんだ。面白いね。なんで?

114 :sageo:02/06/13 21:10
XP実践したら
最悪なことになって
途中で断念・

115 :デフォルトの名無しさん:02/06/13 21:13
>>113
XP(やそれに類する状態)が出来てないと中間リリースを
やっても混乱するだけなことがわかっているから。

116 :デフォルトの名無しさん:02/06/13 21:17
>>114
参考の為に失敗例を具体的に教えて。
問題点、改善点を探そう。

117 :デフォルトの名無しさん:02/06/13 21:37
>>114
XPを途中でやめるってことは、そのままデスマーチ突入だから、
やめてもやめなくても同じ(w
唯一40時間労度が120時間労働になるだけ。
それかプロジェクトを概略設計からやり直し。

118 :XP狂信者:02/06/13 21:46
>>106
正解。さすが実務やってる人間は違うね。
僕の仕掛けたトリック見破れない奴相手に、
ちょっと頑張りすぎてた。今反省中。

そう、普通ウォーターフォールではまわせないんだ。
短期間に5人というのはね。むしろ人数入れることで余計遅くなる。

XPはそういう意味ではデスマーチ。半年5人いれば10000から20000ステップは
楽に実装しちゃうからね。しかも、無駄のない筋肉質なコードと
レグレッションテスト&妥当なユニットテストカバレッジ付。

普通一般のプロセスでは、その速度は出せない。原理的に無理があるんだよ。
でも、XPは可能。
理由のひとつはペアプログラミング。実質二人分なのだから、人数余っていても
大丈夫なわけだ。
もうひとつ大きな理由もあるんだけど、そっちはまだ隠しておこうかな。
少し考えてみるといいよ。

普通の生産量ベース(人月あたり)で倍は軽いし、
アサインされた人間を早急に立ち上げるプロセスを使っているから、
ロスも非常に少ない。短納期に圧倒的な強みを見せるのが特徴。
でも週に40時間。かわいい彼女とデートするのも余裕だし、
成果賃金でウォーターフォールの倍だから、これまでの給料の倍。
実際はそこまでくれないけどね(T_T)。
XPやったらやめられなくなっちゃったよ。
XPマンセーの所以だね。





119 :カイロ:02/06/13 22:15
>>118
>正解。さすが実務やってる人間は違うね。
>僕の仕掛けたトリック見破れない奴相手に、
>ちょっと頑張りすぎてた。今反省中。

その「相手」ってのは俺のことか?

プロジェクトの内容もなしに5人6ヶ月ってだけの条件で、キミがその話を
したいというから、一生懸命答えたのだが、ずいぶん失礼なやつだな。

>普通一般のプロセスでは、その速度は出せない。原理的に無理があるんだよ。
>でも、XPは可能。
>理由のひとつはペアプログラミング。実質二人分なのだから、人数余っていても
>大丈夫なわけだ。

人数が余っていても大丈夫?キミのところは余る心配が足りなくなる
心配よりも大きいのか(w
変なとこだね。仕事がないとか?失礼。

>普通の生産量ベース(人月あたり)で倍は軽いし、

その「普通」ってのはキミのとこの当社比ということでいいの?
ま、キミのとこがウォーターフォール型をまわすのが下手だという
ことは、これまでの文章でよくわかるよ。

ところで客先から引き合いが来たとする。そこから本格的に
XPのイテレーションが開始されるまで、平均どれくらいの時間かかってる?
最初のリリースまでの時間でもいいけど。

案外これに時間食われてるんじゃないの(w
不動産やの広告みたいに「都心から○分。ただし乗り継ぎにかかる時間は含
まれていません」ってのじゃ困るねぇ。

>もうひとつ大きな理由もあるんだけど、そっちはまだ隠しておこうかな。
>少し考えてみるといいよ。

ずいぶん胡散臭いね。いよいよ新興宗教の勧誘になってきたなぁ。

>アサインされた人間を早急に立ち上げるプロセスを使っているから、
>ロスも非常に少ない。
>短納期に圧倒的な強みを見せるのが特徴。
>でも週に40時間。かわいい彼女とデートするのも余裕だし、
>成果賃金でウォーターフォールの倍だから、これまでの給料の倍。

それともキャッチセールスかな?

>実際はそこまでくれないけどね(T_T)。
>XPやったらやめられなくなっちゃったよ。
>XPマンセーの所以だね。

オウム信者の脱洗脳は難しいとかいう話を思い出しちゃったよ。
くわばらくわばら。

ステップ数重視に否定的なはずのXPを一方で謳いながら、
嬉々として1万ステップだ、2万ステップだと語る君の姿は理解に苦しむ。
物欲は捨てなさいと教える一方で何かとお布施だなんだという新興宗教が
オーバーラップした。

見せかけだけでも、もう少しスマートに勧誘しないと信者は増えないよ(笑

120 :カイロ:02/06/13 22:23
ここでXP信者の方々にとっておきのアドバイスをあげよう。

「信者の勧誘マニュアルを作る」

これだね。プラクティスにしてもいいよ。1日1回勧誘する、とかね。
あとは「顧客の騙し方」のノウハウもためておくといい。

XP狂信者クンはまだまだ下っ端だ。勧誘も熱意が先んじて(勧誘の)技術的
には荒削りだね。勧誘相手の知性を認めることが次のステージへの課題だ。
XP信者の方は新興宗教のなかでも幹部クラスかな。なかなか一筋縄では
いかない。(w



121 :カイロ:02/06/13 22:25
いい忘れたけど「顧客の騙し方」このマニュアルが出来たら、ぜひ教えてね。
そのマニュアルをえさにするならなら入信してもいいよ。

122 :カイロ:02/06/13 22:37
>>118
>XPはそういう意味ではデスマーチ。半年5人いれば10000から20000ステップは
>楽に実装しちゃうからね。しかも、無駄のない筋肉質なコードと
>レグレッションテスト&妥当なユニットテストカバレッジ付。

これ読んでて思ったんだけどさ、コーディングに力が入るのは結構なことだけど、
直ちに仕事には結びつかないような自分への投資的なものはどーすんの?

俺の場合設計やコーディングの前半では比較的スケジュールを緩やかにしている。
メンバはその期間で自分なりに必要と思うことを勉強するなり新しい試みを
試してみるなりする。もちろん遊んでいるやつもいるが、まあそれはしかたないかなと
も思っている。言い換えればそういう時間にも会社は給料を金を出している。

キミのXPのように全力疾走してる場合、そーゆーのはどーうするの?
40時間はみっちり目の前の仕事に集中してもらって、勉強は各自労働時間
外でやってもらうってこと?


123 :XP信者:02/06/13 22:38
>>112

>XPの良いところは、リリース速度が速いことだと思う。

そのとおり。

>これが宗教?

XPの宗教色は、方法論に価値観を持ち込んだところ。
リリース速度が速いっていうのは確かにメリットであるが、
XPほど他の方法論は重視していない。

これは、XPにとって最も重要であると考える4つの価値を
実現するために、XPが構成されているから。

XPが信じる4つの価値に共感できるか否かによって、
XPが全く違ったものに見えるでしょう。

XPが宗教である所以


124 :XP信者:02/06/13 22:39
>>120

>XP信者の方は新興宗教のなかでも幹部クラスかな。なかなか一筋縄では
>いかない。(w

いえいえ、あなたも煽りに年季が入っているようで。

125 :xπ    :02/06/13 22:45
共生以て甦六

126 :デフォルトの名無しさん:02/06/13 22:50
>>122
それもタスクのうちに入るよ。

127 :デフォルトの名無しさん:02/06/13 22:56
>>122
>40時間はみっちり目の前の仕事に集中してもらって、勉強は各自労働時間
>外でやってもらうってこと?

勉強の時間をどうするかは重要な話だけど、方法論とは別の話じゃないかな。

XPでプロジェクト中は時間が取れないとしても、
プロジェクト終了後に勉強期間を設けるとか工夫はできそうかな。

128 :カイロ:02/06/13 23:11
いや何かとウン万ステップとか謳い上げるもんでね。
効率の悪さも時には「必要悪」ってこと。

脊髄反射でレスつけたくなる人のために、用意しといてあげよう。
>うしろめたい思いをしてたのを、それでもいいじゃんとおおっぴら〜

129 :XP信者:02/06/13 23:20
>>103

>けどこの間いるのはこの規模なら1〜2人だ。普通他のメンバは一つ
>前のプロジェクトのコーディングとかデバッグとかをやってる。

具体的な人数配分は読み取れなかったけど、これってリスク高くない?
前のプロジェクトが予定通り終わらなかったら、全然関係ない次の
クライアントのプロジェクトにも影響が出るって事でしょ?

>コーディングの後半からデバッグの終わりにかけてが当然ピークになるから、
>全員がこのプロジェクトに集中する。山を越えても散発的にバグは出るから、
>ある程度の人数を残しつつ、残りのメンバは次のプロジェクトの仕様検討。

テストの工程は無いの?

あと、ウォータフォール形式の線を引いて契約する場合、ほぼドキュメントの納品が
求められると思うけど、それも無用のドキュメントに入ってるの?

130 :デフォルトの名無しさん:02/06/13 23:24
 water form  ・・・

131 :カイロ:02/06/13 23:44
>>129
>>けどこの間いるのはこの規模なら1〜2人だ。普通他のメンバは一つ
>>前のプロジェクトのコーディングとかデバッグとかをやってる。
>
>具体的な人数配分は読み取れなかったけど、これってリスク高くない?

高い。予想が必要だし予想は外れる。
だから>>105の発言がある。

>前のプロジェクトが予定通り終わらなかったら、全然関係ない次の
>クライアントのプロジェクトにも影響が出るって事でしょ?
>
>>コーディングの後半からデバッグの終わりにかけてが当然ピークになるから、
>>全員がこのプロジェクトに集中する。山を越えても散発的にバグは出るから、
>>ある程度の人数を残しつつ、残りのメンバは次のプロジェクトの仕様検討。
>
>テストの工程は無いの?

あるよ。書いてないだけ。書いても面白くないし、テストについてはどうやったって
XPに勝てるわけがない。

実際には、全体の大きな線表の中に単体設計-製作-単体テストが散らばるね。
んで○○の結合テストとかが連なっていって全体のテストになるね。

>あと、ウォータフォール形式の線を引いて契約する場合、ほぼドキュメントの納品が
>求められると思うけど、それも無用のドキュメントに入ってるの?

どれくらいのドキュメントをどの時期に顧客に出すかはケースバイケースだよ。
小規模なプロジェクトなら顧客に出すドキュメントも大抵少なくする方向でまとめる。
平凡な答えで申し訳ないけど。


132 :カイロ:02/06/13 23:56
ドキュメントについて追加。

ドキュメントについて融通が利かないケースってのは大抵規模もでかい。
そういうのはドキュメント作製の工数もそれなりにたくさんとる。
お硬い相手は辟易する量のドキュメントを要求してくる。
自社の形式もあるが、それを使うか、顧客の指定の形式をつかうか、
まったくプロジェクト独自のものを使うかは、柔軟に考えている。




133 :デフォルトの名無しさん:02/06/13 23:59
>>131
面白い。

134 :XP信者:02/06/14 00:41
>高い。予想が必要だし予想は外れる。
>だから>>105の発言がある。

XPの方がリスクは抑えられると思うけど、
具体的な内容がまとめられないので保留。
少なくとも、オーバーラップを前提としない分、
顧客のリスクは抑えられるかな?

>>テストの工程は無いの?
>あるよ。書いてないだけ。書いても面白くないし、テストについてはどうやったって
>XPに勝てるわけがない。

テストって人手がかかるんで、人数の話をしているときは重要なんじゃないかと
思ったりして。
あと、ウォータフォールである以上、最後の工程はテストなんでしょ。
ピークはコーディングじゃなくてテストなんじゃないんでしょうか?

>どれくらいのドキュメントをどの時期に顧客に出すかはケースバイケースだよ。
>小規模なプロジェクトなら顧客に出すドキュメントも大抵少なくする方向でまとめる。

そのやり方を極めたのが、XPの「ドキュメント不要」の方針だと思うんだけど。
「ドキュメントがどれだけ必要から顧客に決定させなければならない。」ってのが。


135 :デフォルトの名無しさん:02/06/14 02:10
>>134
>
>XPの方がリスクは抑えられると思うけど、
>具体的な内容がまとめられないので保留。
>少なくとも、オーバーラップを前提としない分、
>顧客のリスクは抑えられるかな?

?現状はそのリスクは開発会社が負ってるんだよね。
前の仕事の遅れを次の顧客に影響させることはどんなことがあってもできない。

開発会社内で人員をやりくりするか、孫請けや人材派遣を頼むか、
最悪でも前の仕事の顧客に何とか了解してもらうしかない。
(全く中断はできないから、パワーダウンして続けることになると思う。)
ま、早い話デスマーチ状態ですな。

そしてXPだとそのリスクを顧客に負わせるわけだよね。
XPだと「延長」の要望(事実上「命令」)はないの?
だらだらと続くことを恐れているんだけどね。

延長分の開発費は払いますから、開発を続けてください、というのも
考えようによっちゃたちが悪い。後の仕事を断るわけにもいかないから。

もちろん契約でその辺ちゃんと決めればいいと思うのだけど、
それが可能なのはずいぶんと相互の信頼が厚い場合に
限られるよね。(厚くてもそもそも会社として、そういう発注
形体を許さない方針のとこもあるだろうし。)



136 :カイロ:02/06/14 02:10
>>>テストの工程は無いの?
>>あるよ。書いてないだけ。書いても面白くないし、テストについてはどうやったって
>>XPに勝てるわけがない。
>
>テストって人手がかかるんで、人数の話をしているときは重要なんじゃないかと
>思ったりして。

XPタイプのテストとウォーターフォールタイプのテストでどちらが(人員面で)
効率的か、というのは興味深い話と思う。

危険度の高い部分はテストのためのプログラムの製作とかを
盛り込むから、最終的に同じ品質を求めるなら、両者はだいたい
同じになるんじゃないかと。

ただ一般にウォーターフォールの場合、大半の箇所を危険度が低いと
予測して単体のテストで手を抜くから、その予測が外れないがきり「効率」は
よい気がする。(とうぜんリスクも高い。)

すなわち「品質」のコントロールの権限がデフォルトでは(XPは顧客にあるが)、
ウォーターフォールでは開発者側ってことかな。デフォルトの状態は
要望に応じて変更可能と思うけどね。

>あと、ウォータフォールである以上、最後の工程はテストなんでしょ。
>ピークはコーディングじゃなくてテストなんじゃないんでしょうか?

それはそう。

>>どれくらいのドキュメントをどの時期に顧客に出すかはケースバイケースだよ。
>>小規模なプロジェクトなら顧客に出すドキュメントも大抵少なくする方向でまとめる。
>
>そのやり方を極めたのが、XPの「ドキュメント不要」の方針だと思うんだけど。
>「ドキュメントがどれだけ必要から顧客に決定させなければならない。」ってのが。

ふむ。その点は異論ないよ。


137 :カイロ:02/06/14 02:31
補足

>すなわち「品質」のコントロールの権限がデフォルトでは(XPは顧客にあるが)、
>ウォーターフォールでは開発者側ってことかな。デフォルトの状態は
>要望に応じて変更可能と思うけどね。

テスト項目とテスト結果の提出時期には結構うるさいお客もいる。
無意味としか思えない内容を要求する顧客もいれば、舌を巻くほど
鋭い内容のものを要求する顧客もいる。そういうケースは、むしろやりやすいね。お互い。


138 :HAMAIタンうぉっち:02/06/14 17:48
># ISOとXPは相性悪いかな、と思えてしょうがないです(^^;

あくまで相対的にですが。ISO9001は信頼性重視生産性軽視、XPは信頼性軽視
生産性重視だと思います。
XPで信頼性を重視した開発ができないとは思いませんが、XPらしさといった
ものは薄れると思います。


139 :デフォルトの名無しさん:02/06/14 17:51


140 :デフォルトの名無しさん:02/06/14 22:34
HAMAIタンはXPのどこをどうとって信頼性軽視といってんだ?
例えば作成とテストを同じ人がやるから、監査面で信頼性が悪いといってんのかな。

141 :XP狂信者:02/06/14 23:12
ついにアスパラ君、完璧なる分析を断念。
というより、すでにオーバースペックだね。
ざっとやれって言ってるのになぁ(苦笑)。

コアになる部分だけ作ればいいのに、何でもかんでも分析ーデザインでは
本質を見つける能力にかけているぞよ。

XPはアジャイルなので、一週間ずっと打ち合わせやって
何も決まらないプロジェクトには興味ありません。

時間が来たら多少の無駄だろうがなんだろうが、さくっと実装。
それを見ればまた少し賢くなった自分たちに出会えます。
日々進歩。これがXP。

Xperになってから、あるたぐいのコーディングを雑にやってたりしてます。
static final int xyz = 123;
とか昔は書いてたところで、とりあえずいいやってんで、
定数をじかに書いたりもしています(^^;。

さすがに2度目の参照があるなら、finalにしますが、
一回だけならもう何でもあり。
定数に持っていくのは2回目から。

こういう細かいこと考えなくてよくなったので、
コンストラクタの設計もいろんなパラメータの場合なども考えません。
いやー、本当に考える量がむちゃくちゃ減りました。
おかげで、仕事がはかどるはかどる。
OOPの力を存分に味わえてます。

XPマンセー。ハイル ベックたん。
ハマイタンもがんばれー(笑)。


142 :デフォルトの名無しさん:02/06/15 01:31
>>140
その点は受け入れテストがカバーしてるよね。

143 :デフォルトの名無しさん:02/06/15 01:46
やっぱし濱井タンはXPの中身よく解ってなかったのね。
xUnitも使ったこと無いんだろーなぁ。

144 :デフォルトの名無しさん:02/06/15 01:56
>>141
>いやー、本当に考える量がむちゃくちゃ減りました。

思わず「考える力がむちゃくちゃ減りました」って読んじゃったよ。
ま、既存の固定観念にとらわれず自分の力で考えろ、考えろ、考えろと
攻め立てて、その実、考える力を奪うのが新興宗教の常套手段だから。


145 :デフォルトの名無しさん:02/06/15 01:58
>>144

ドキュメント整理に追われて肝心のロジック考える時間を奪われるよりよっぽど
ましだと思うが?

146 :デフォルトの名無しさん:02/06/15 02:10
>>144

いままでxyzと書くか123と書くかを半日悩んでたり、コンストラクタの
引数はどうあるべきかを1週間もんもんと考えてたりしたのが、なくなった
てことだろ。

そりゃ当社比で何倍もの効率アップになるだろうね。
XPと関係ない気がするけど。


147 :デフォルトの名無しさん:02/06/15 02:12
>>143
濱井タンって実はソフト開発したことないんじゃない?

148 :カイロ:02/06/15 03:46
>>141

なんかほめ殺しになってないかい?
ひょっとして俺の同志かな。


149 :デフォルトの名無しさん:02/06/15 05:26
ねぇ、XPでやらせたらとんでもねーことになった、とかの体験談ないの?

150 :XP狂信者:02/06/15 07:05
昔は、ソーティング法どれを使うかで小一時間悩んでたりもしました。
今は、もう簡単。最小値選択かバブルソート。
10秒で実装できる奴を選びます。
Javaならユーティリティがあるけどね。

2分探索も最近はめったに書いてないなぁ。

えっ?性能が遅いって?
ああ、気にすることないです。
本当に、速さが求められるところは、そんなには多くない。
Profiler使えば遅いところは見つけられるし、
受け入れテストで引っかかる部分だったり、
ユーザから要求があった時点で考えても十分間に合います。
最善のアルゴリズムを導くための状況が整うまで、
その判断を遅らせられるのがOOPの良いところ。

やっぱり実際のデータ集合がないと、最速のアルゴリズムって
なかなか見つけられないんだよね。
OOAOODでは、OOPの持つ力の半分も引き出してなかった
ことを思い知らされてます。

本当にまじめな話、レベルの低いプログラマになると仕事はかどるんだよね。
あるいは、ちょっと前の自分がいかに無駄なことを考えていたかを
思い知ってます。

おかげでレベルの低いプログラマにもやさしくなれました(爆笑)。

いや、まじめな話さ。メソッドのアクセッサ。
publicにするかprivateにするかprotectedにするか、
普通5分は悩むでしょ?
今?今はもう、デフォルトですよ。パッケージデフォルト。
気になったらprivateにするけどね。
必要になったらpublicかprotectedにする。
それで仕事が終わるんだもの早い早い。



151 :XP狂信者:02/06/15 07:27
>>149
あるわけないだろ。
今XPやってるのはあるレベル以上だけ。

XPやれないところにXPやらすと失敗するのは目に見えているので、
そんな要求はしないほうが身のため。

XPやりたいと開発側が言わない限り要求するのは無理です。
死にますよ。いや、マジ。

俺のところも、アクセプタンステストはほとんどうまくできてない。
ついつい手動による確認で終わらせてしまうんだ。
今後の改善項目だよ。






152 :デフォルトの名無しさん:02/06/15 07:28
>>150
まだ少々修行が足りない。

自分の能力以上のコードを、
長時間悩んで実装するのは馬鹿げたことだが、
幾重にも積み重ねられた経験があれば、
今と同じ時間で、それほど悩むこともなく、
それなりのコードが書けるようになる。

でもまあ、今はそれでいいんじゃないか?

153 :デフォルトの名無しさん:02/06/15 13:49
>>151

>>ねぇ、XPでやらせたらとんでもねーことになった、とかの体験談ないの?
>
>あるわけないだろ。
>今XPやってるのはあるレベル以上だけ。
>
>XPやれないところにXPやらすと失敗するのは目に見えているので、
>そんな要求はしないほうが身のため。

日本語もXPで書いてんの?イテレートしてくだちぃ。

154 :デフォルトの名無しさん:02/06/15 14:17
>>150
なんかキミの文章読んでると、XPやると馬鹿になるんじゃないかっていう
恐怖を感じるよ。

155 :XP狂信者:02/06/15 15:25
まじ、もうちょっと若いころのほうが、無茶なコーディングしてたけど、
エネルギッシュだったわけよ。
なぜ遅くなってきてたかっていうと、細かいところが気になって
それがブレーキ踏んでたことに気づくのね。
XPでそのブレーキの原因を壊せました。

UnitTestがオートマティックにブレーキ踏んでくれるので、
こっちはアクセルがんがん踏むだけ考えれば良くなったの。
早いよぉ。たまんねぇよ。
XPジャンキーって感じです。



156 :XP狂信者:02/06/15 15:35
>>154
XPに転職というのはね。RPG的にいうとね。

速度+4
正確さ+2
力強さー2
体力+1
忍耐度−4
知力ー2
知恵+3
運命+2
カリスマ+3

こういう効果のあるジョブチェンジだからねぇ。
君に向いているかどうかは、おれは知らないっす。


ちなみに体力ー2とか忍耐力ー4とかは、
体力に余裕出てくる



157 :XP狂信者:02/06/15 16:14
あっ、途中きれ(^^;
体力+1ってのは体力に余裕出るの意味。
忍耐力ー4は、まじせっかちになったかなー(^^;


158 :カイロ:02/06/15 17:18
>>155
>まじ、もうちょっと若いころのほうが、無茶なコーディングしてたけど、
>エネルギッシュだったわけよ。
>なぜ遅くなってきてたかっていうと、細かいところが気になって
>それがブレーキ踏んでたことに気づくのね。

おれもそんな頃がったよ。(笑

これはひとそれぞれだけど、頭の中だけで考えると煮詰まっちゃう人は、
手を動かしながら(コーディングを通じて)考える方が向いてるだろうね。

>XPでそのブレーキの原因を壊せました。

それはなによりだけど、マジで新興宗教に熱狂しているみたいで
心配なんだけどね。新興宗教は確かに、お手軽に「目からうろこ」の
「答え」を与えてくれる。「苦労しないで得たものは身につかない」と
おっさんくさいことをいうのは気が引けるけど、「苦労」ってのは
ようは応用問題なんだよね。基本問題を解く公式を教えてもらうのは
悪いことじゃないけど、そこからが本当の出発点なんだけどね。

>UnitTestがオートマティックにブレーキ踏んでくれるので、
>こっちはアクセルがんがん踏むだけ考えれば良くなったの。
>早いよぉ。たまんねぇよ。
>XPジャンキーって感じです。

ま、がんばってこれからいろんな応用問題を解いてくれ。
そういえば「公文式」ってあったね。今もあるか。XPはアレにも
にてるかな。

159 :カイロ:02/06/15 17:24
ところでさあ、他の項目にコメントする気はないけど(聞いても
答えは予測できるし)、

>カリスマ+3

これはどんな理由なの?

160 :デフォルトの名無しさん:02/06/16 05:53
設計を最初にやる意義がまったくわかりません。
要件の分析や定義を早めにやるのはまあ理解はできるけど、

なぜ最初に設計までやりますか?しかも細部まで!
そういった設計が最後まで維持できたプロジェクトは見たことがない。

維持しようとして失敗したものなら見たことがある。

理由きぼん、まじでメリットが分からん。 > 最初に設計

161 :XP狂信者:02/06/16 08:15
昔はアセンブラだったから。
これが答えのひとつかな。
コーディングが本当に大変だったからね。
今はOOPでしょ。コーディングしているほうが、
フローチャート書いているより数段楽。
その差じゃないかな。
まだ、フローチャート要求する会社もあるらしいけど、
そーゆーところは、逝ってよしだよね。


162 :XP狂信者:02/06/16 08:18
>>160
身だしなみに気をつけるようになるから(爆笑)。
ペアプロだし、お客様常駐だからね。
ヨレヨレ状態はまずいっす。

ついでに、うるさくて訳わからないこと言わなくてすむようになったので、
部下受けがあがったっすよ。



163 :XP狂信者:02/06/16 09:01
http://www.ipsj.or.jp/members/SIGNotes/Jpn/09/1998/121/article011.html
アスパラウォッチャーの狂信者です。

オブジェクトの識別って難しいんだ。
DATARUNってそういう人たち向けだったのか
ふーん、なるほどね。

どーりで訳わからない方向行くわけだ。
OOAOODって悟るものだからねぇ。
オブジェクトなんて、すぐにわかるようになるよ。
オブジェクトの識別が難しいなどというのはやめましょうね。>皆さん。

ちなみに、本格的なOODでは、単純なデータストラクチャーを
クラスとして扱うことはしません。
処理の都合上サポートクラスとして使うことはあるけどね。
そこらへんで、C++のおかげでだいぶミスリードされたよね。

ビジネスロジックをどこに記述するかのほうが大事です。
もっともこれが一番難しい。
EJBも狙いはそうなんだけど、やっぱりいまいちのフレームワークだし、、、。

二つ以上のオブジェクトのコラボレーションになるので、
どちらの役割にするかが問題。明らかな場合もあれば、
相互作用的にコールバック多用しなけりゃならないときもある。
ついでに、一段上のオブジェクトでもかけたりするので、
ここら辺になるともう趣味の領域なんだけどね。


それにしても、おもしろ開発法にかぶれるなら、
マイケルジャクソンのジャクソン法にはまったほうが
レベルあがるんだけどねぇ。

いやぁ、あれはすごい世界だった。
コードがまるっきり読めない世界でさ。
OOPのシステムをアセンブラでゴリゴリ書いてあるようなシロモノ。
実際はCで書いてたサンプルみたんだけど、あの方法はどこの環境でも
もっていけそうだった。でも、プログラマーは死ぬしメンテは不能(苦笑)。











164 :カイロ:02/06/16 11:08
>>163
>
>オブジェクトの識別って難しいんだ。

>OOAOODって悟るものだからねぇ。
>オブジェクトなんて、すぐにわかるようになるよ。
>オブジェクトの識別が難しいなどというのはやめましょうね。>皆さん。

実際問題として難しいかどうか、って話じゃなくて、発見的手法でしか
扱えなかったものをどう演繹的に定式化するか、って話だからねぇ。

「悟」りのアルゴリズムを考えていきましょう、って。

コンピュータチェスのアルゴリズムを研究してる者に「チェスは
難しくありません。悟るものです。」とかいうのと同じじゃないのかな。(w

チェスに強くなりたいなら、とにかくいろんな相手と対戦を
して場数を踏めば、自然と身につきます、ってのが「悟り」だね。

どっちが正しくてどっちが誤りってことじゃなくて、両者を排他的に扱うのが間違い。



165 :カイロ:02/06/16 11:30
>>160
>設計を最初にやる意義がまったくわかりません。
>要件の分析や定義を早めにやるのはまあ理解はできるけど、
>
>なぜ最初に設計までやりますか?しかも細部まで!
>そういった設計が最後まで維持できたプロジェクトは見たことがない。
>
>維持しようとして失敗したものなら見たことがある。
>
>理由きぼん、まじでメリットが分からん。 > 最初に設計

俺は必要以上に細部までやらないけどね。
必要なのは設計者とコーディングを行う人間が別のときだね。
例えばチェスの思考アルゴリズムを考える人とプログラミングする
人が別なら、アルゴリズムを人から人へ伝えなきゃならないから。

実用的な分野でもエアコンやエンジン、ロボットとかの制御プログラムは、
ナントカ理論によって導き出された数式がごちゃごちゃ出てくるから、
それを伝えなきゃならない。基本的な数式だけ示すだけでプログラムに
落とせる人はやっぱ限られる。

後はやっぱ多人数で開発する時だろうね。他者担当の部分とのインターフ
ェース部分を設計する。

ま、なんにせよ意味がないと感じるなら、実際に意味がないんだから
無駄な詳細設計はやめた方がいいよ。必要な箇所だけすればいい。

この部分はちょっと落ち着いて考えとかないと、その先どうプログラム
していくか方針が立たない、って箇所だけじっくり設計すればいい。

ただし、それさえ見極めなれないレベルの人間相手に対しては、ほっとくと
どこへ走っていくかわからないから、やっぱ設計の重要さは話すけどね。


166 :カイロ:02/06/16 11:46
あとデータの更新タイミングとかトランザクション周り、ようするに全体にかか
わるところだね、はやっぱ先に設計するけどね。これを後でいいとかいう技術者には
不安を感じる。

作りながら設計出来ないことないだろうけど、ある方針でコーディングを
はじめたら行き詰って、別な方針に変更する時に、コードの変更量が
非常に大きくなる。

もちろん設計を念入りにやろうが、いきなりコーディングをやろうが、
行き詰るときは行き詰る。もしどういう順序でやっても行き詰る確率が
同じぐらいなら、どっちでやってもいいだろうね。

結局、最初にじっくり考えた方が、多少なりとも行き詰る確率が減りそう
な箇所だけ設計に力を入れるべきだね。

167 :160:02/06/16 16:12
>>165
アルゴリズムはどうにもならんようには思います。
が、アルゴリズムは専門化がブラックボックス的につくってしまって、
他の人間が触る必要がなくなるようにしません?
そういった場合、事前に作るのはインターフェイスくらいだし。

>>166
データがらみは最後に手をつける俺は駄目技術者ですか?
やっている仕事の違いだろうけど、データがらみが全体に影響する
ってのがよく分からない。

あとコーディングの変更がそんなに嫌かな?おれは事前に設計させられて、
変な仕様書書いて、それを後から修正するほうが嫌です。実際それでキレて
辞めたことがある。

168 :カイロ:02/06/16 17:02
>>167
>アルゴリズムはどうにもならんようには思います。

そう。

>が、アルゴリズムは専門化がブラックボックス的につくってしまって、
>他の人間が触る必要がなくなるようにしません?

あるよ。こまったもんだよ。
前スレの670辺りでXPは本当にコードの共有を維持できるのか?を
しつこく問い詰めてたのは俺だ。

>そういった場合、事前に作るのはインターフェイスくらいだし。

だから

>後はやっぱ多人数で開発する時だろうね。他者担当の部分とのインターフ
>ェース部分を設計する。

といってるんだが、何が言いたいのかわからん。日本語が不自由なの?

>>>166
>データがらみは最後に手をつける俺は駄目技術者ですか?
>やっている仕事の違いだろうけど、データがらみが全体に影響する
>ってのがよく分からない。

キミがどういう分野の仕事をしているかによるね。分野だけでも
教えてくれないと話は進まないと思うよ。

それに分野によっていろいろ異なるから165-166にかけて、わざわざ
異なる分野でそれぞれの位置づけを示したんだが、君の頭にはバッファが
1つしかない?

>あとコーディングの変更がそんなに嫌かな?おれは事前に設計させられて、

別に?いやとはいってないよ。
設計での変更でもコーディングでの変更でもお好きに。効率がいいほうを
取ればいいし、効率がすべてではないというなら、それも一理あるから、
最終的に好きなほうを取ればいいだけだ。

俺は設計段階で試行錯誤する方が、わざわざコーディングして試行錯誤
するより効率がいいから、それを好むけどね。頭の中の作業が不得手と
いうか性に合わない人は、そうすればいいといってる。

>>158
>これはひとそれぞれだけど、頭の中だけで考えると煮詰まっちゃう人は、
>手を動かしながら(コーディングを通じて)考える方が向いてるだろうね。

(少しは前のレスも読めよ)



169 :デフォルトの名無しさん:02/06/16 17:06
>変な仕様書書いて、それを後から修正するほうが嫌です。実際それでキレて
>辞めたことがある。

それは設計がいやというんじゃなくて、ドキュメントを作るのがいやなんじゃないの?

設計ってのは頭の中で行うもんだよ。プログラミングもね。その頭の中の物を
どう残すかがドキュメントでありコーディングだと、俺は考えるね。

ドキュメントを残す残さないは「設計」とは別の話にしてほしいものだ。
少なくともドキュメントを作るのが設計と考えている人間に設計とはどうある
べきか、いつ行うべきかなどと論じてほしくない。

「設計」の成果物としてのドキュメントを残すか、またそのフォーマットを定めるか、は
いろんな理由があるから、なんともいえないけどね。無意味に細かい関数仕様とか
を書いたところで、俺個人的には意味ないと思う。それを要求するのは要求する
人の考えと事情があるんでしょ。

ま、この辺話したければ俺ももう少しつき合うけど。

170 :160:02/06/16 18:50
>>168
インターフェイス作ってアルゴリズムを隔離しておくことぐらいは
設計とは言わなくない?

おれがやってることは企業向けのイントラと
イントラ作成の際にあると便利なパッケージの作成です。

イントラに関してはデータが重要ではあるものの、データのレイヤーが
他の部分に影響しないように作ればあまり問題がないだろうという考えです。

>>169
いかに設計するか、ってのはまあ趣味の問題かと。
でも実際に作業するにあたって、設計と実装が分離した形だと
問題なような、という話です。

最終的にある程度の設計書を書くのは仕方がないように思います。
保守する人間が開発者ではない場合も多いし、第一顧客が要求してきます。


171 :160:02/06/16 19:30
ウォーターフォールだと必要以上にドキュメント中心になる傾向が
あるような。そんなには相関ないだろうに、なんでだ?

某HとかMとかいった大手の内部プロセスの資料を見てびびった覚えがある。
ドキュメントを書かないと叱られるといった意味でしか機能してなかった。

172 :カイロ:02/06/16 19:49
>>170
>インターフェイス作ってアルゴリズムを隔離しておくことぐらいは
>設計とは言わなくない?

今ひとつキミの日本語がよくわからんのだが、「設計とは言わない」と
言ってるのか?

見ている範囲によるだろうね。全体から見れば個々のモジュールに
分解するのも立派な設計だ。

つーかなんかキミのレスはつまらんよ。

>おれがやってることは企業向けのイントラと
>イントラ作成の際にあると便利なパッケージの作成です。
>
>イントラに関してはデータが重要ではあるものの、データのレイヤーが
>他の部分に影響しないように作ればあまり問題がないだろうという考えです。

キミの作っているパッケージではデータの更新タイミングとかトランザクション
処理とかは気にしなくていいの?

イントラってのはグループウェアとか?誰がどのデータを入力したり
参照したりするのかのフローを「設計」することが必要だと思うけど。。。

いまいちキミのやってることがイメージできないが、まあキミがやって
ることはキミが一番詳しいんだから、その分野でデータの流れが
対して重要ではない(最初に設計するひつようがない)というなら、
そうなんだろう。何もキミの仕事にケチつける訳じゃないから。

せっかく説明してくれたのに、ちょっと申し訳ないが。。。

>>>169
>いかに設計するか、ってのはまあ趣味の問題かと。
>でも実際に作業するにあたって、設計と実装が分離した形だと
>問題なような、という話です。

そりゃそうだろう。常識ジャン。一人が何でもできて何でもやった方が
効率いいに決まってるよ。一般的な話をすればね。それがままならない時に
(大抵それがままならない)さあ、どうしましょう、ってのが議論の分かれる
とこだよね。

なんとなく、ここからはありきたりな話になりそうな気がするんだけど、続ける?

>最終的にある程度の設計書を書くのは仕方がないように思います。
>保守する人間が開発者ではない場合も多いし、第一顧客が要求してきます。

例えば今君がやってることを、別なやり方で可能なのか?ってのを考えて
みるなら面白い話になるかもしれない。

小規模のパッケージ開発なら俺もXPでいけるかなと半分ぐらい考えている。
少なくとも今の受託とかをXPでやるより現実的かな、とね。特に「設計」
にプログラム以外の専門的知識(数学とか物理とか経済とか)がいらない
パッケージなら、プログラミング片手に設計するのも可能だろう。




173 :カイロ:02/06/16 19:56
>>171
>ウォーターフォールだと必要以上にドキュメント中心になる傾向が
>あるような。そんなには相関ないだろうに、なんでだ?

逆ではないのかな。ドキュメントを求めるから、それ向きの手法を
選択するんじゃないの?

>某HとかMとかいった大手の内部プロセスの資料を見てびびった覚えがある。
>ドキュメントを書かないと叱られるといった意味でしか機能してなかった。

本当に機能していないかが問題なんだが、担当者の引継ぎとか、時には
プログラマの寿命を越えて10年とかメンテしなくてはならないプログラムとか
を大手のソフト会社は受注すると思うけど、そういった点から見ても、本当に
「無駄」なの?

例えばキミが10年ぐらい前に開発されたCOBOLとかPL/Iのプログラムを
メンテしてくれ、と渡されたとき、そのドキュメントが何の足しにもならない、
といって迷わずシュレッダーにかけるような代物なら、そのドキュメントは
無駄なんだろう。多少は足しになると思って一応受け取っておくなら、
少しは役に立つものなんだろう。


174 :カイロ:02/06/16 20:01
誤解しないで欲しいのは、言いたいのは中にはドキュメントが非常に重視される
プログラムもあるってこと。そしてもちろんすべてではないってこと。
原子力発電所の制御プログラムにドキュメントがついてなけりゃ、困ると
思うよ。でもちょっとしたWebのcgiに同じ量のドキュメントを求めるのはナンセンスだ。



175 :XP狂信者:02/06/16 23:15
しかしねぇ、コードという明確な形まで落としておかないとね。
頭に覚えてなきゃならないんで精神的にどんどんキツクなるんだよね。

設計とドキュメントは別というのは正しいのだが、
ウォーターフォールの場合はドキュメントの形に残さなければ
マイルストーンがあやふやになるので、プロセスがない状態と言っていい。

XPはそういう意味では、開発全部の期間を設計にしようというスタイル。
マイルストーンは、ストーリー、タスクで図れるのでそれで問題ない。
また、デザインの失敗もリファクタリングによる調整で処理できる。
だから、いちいち全体ー全部なんて気にする必要がない。
コードが教えてくれるきれいな形を求めていけば
自然にシンプルでよい設計に落ち着く。

この点、設計でドキュメントベースでやってると、
設計の上できれいな形になっても、コードが汚くなる可能性が高い。

設計上の美しさのポイントとコードの美しさのポイントがずれるのが問題なのだ。

良い例が、ジャクソン法。ジャクソン法の設計は非常に美しいしわかりやすい。
だけど、コードがガタガタ。えらくこみいったものになる。

RUPの場合、以前誰かがリンクはってくれた
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/ObjectModeling/article.html
の人、設計もモデリングも問題ない。

だけど、コードは、elseifが多すぎて何がなんだかという状態。
Factoryパターンを使ったから格好よいでしょ。
というのが趣旨なんだけど、あの程度じゃあそこまではいらない。
設計だけやってると、どうしても大げさになっちゃうんだよ。
ご苦労さまという感じ(^^;

ItemFactory.javaで結局 DVDクラス生成するところで、
CDクラス呼んじゃってるしなぁ。筆がすべってしまったのだろうけど。

XPは、コードセントリックな設計法だから、すなわち
コードが美しくてシンプルなのがベストな設計法と言っていい。
基準がひとつなので、管理しやすいし、同じ方向をみんなで向きやすい。

設計期間がx倍。美しさの基準がひとつ。
シンプルでいいね。XPマンセー。












176 :160:02/06/16 23:39
>>172
やっぱりアルゴリズムのラッパーを設計というのはどうかと。
これも趣味の問題か。

あんまり詳しくは書けないけど、
データ自体は重要だけど、<事前の>設計が必要だった例はないような。
多少は事前に考えておけばよかったかなと思うときもあるけど。

>大抵それがままならない
おれは大抵は設計と実装を同時に行えると思っているんだけど…

>>173
俺が見た例では、似たようなプログラムのそれらをコピーしていたから、
いかなる理由においても役に立ってないんじゃないかな?
まあこれは、駄目な例だけどね。

んで、いつものXPの主張だけれども、
まっとうな言語をつかっていて(COBOLは勘弁してください)、
外部仕様がわかっていて、実装がシンプルで、
テストがそろっているならそれ以外のドキュメントなど
ほとんど必要なくない?

177 :XP狂信者:02/06/16 23:41
動かしながら設計のひとつの形は以下のリンクのとおり。

http://www.sra.co.jp/public/doc/GSletter/vol.26/smalltalk/smalltalk.html#pgfId=779327

ドメインオブジェクトを見つけるのが重要なのは、どの言語でも一緒。
でも、頭だけでやるよりは、動きで考えたほうがわかりやすい。

みんな、RUPやるより、Smalltalkいじりなよ。
そのほうが、OOがよくわかるよー。




178 :XP狂信者:02/06/16 23:51
>>176
そうなんだけどね。
でも、多数のプログラマを見てきたところ、
彼らはまだ日本語?で考えるのがやっとらしい。
コードで考えられないようなんだ。

XPはスキルというか、コードネイティブな人向けなことは確かなので、
その点彼らには非常にキツイだろうね。

コードがネイティブに浮かばない人たちのことを
SE−−−業務知識と日本語でなんとか考えられる人。
PG−−−特殊な図や擬似コード(日本語)をなんとかプログラムに翻訳できる人。

世間ではこういうことらしいよ。多少信じがたいのだが(苦笑)。

で、そういう連中のプログラムは実装がシンプルではありえないんで、
そのためドキュメントがいるんだよ。
プログラムをわかりやすく書く訓練が欠如しているからね。

おかげで、おれもドキュメントを要求されちゃって、
わざわざ頭の中のコードから図描いて、PGに渡してたりしたんだけど、
XPになってすごく楽になりましたよ。






179 :XP狂信者:02/06/17 00:07
http://dspace.dial.pipex.com/jacksonma/
マイケルジャクソンは上の人。英文だけどね。


180 :160:02/06/17 00:47
>>175
あれは構造化のほうのプログラムが(意図的に?)関数の括りだしを行っていない
あんまりな例なので、ちょっとひいた。

if文自体は文字列での入力を判断する部分なので、仕方がなくない?

181 :XP狂信者:02/06/17 01:06
入力のほうはね。
ItemFactoryのほうのelseifを問題にしたい。
Hash使うとかで、文字列とClassの辞書作っておいて、さくっと呼びたい気分。
初期化のところがダラダラとなるけど。

説明用だからわかりやすいのを選んでいると思っているんだけどさ。

OOPでは、elseifとかswitchは滅多に書きません。
必須なのかどうかチェックしないとね。

よいうことで、問題にしているのは、RUPとXPでは、
コードの落ちつく先が違うってこと。
余計なクラス作るのがRUP(分析ご苦労さま)。
その分メンテが増えるんだよなぁ。






182 :カイロ:02/06/17 01:21
>>175
>XPはそういう意味では、開発全部の期間を設計にしようというスタイル。

>XPは、コードセントリックな設計法だから、すなわち

コードで表すのがもっとも適切な部分ってのは、んーどうかなのかね、
少なくともあえてコーディングと分けなきゃならない「設計」ではないね。

コードでは間接的にしか表せない部分こそが、設計と思うけどね。

例えば

>>177
>http://www.sra.co.jp/public/doc/GSletter/vol.26/smalltalk/smalltalk.html#pgfId=779327

ここでいくつか「図」を使って説明してあるけど、なぜ「図」が必要なのか?
smalltalkのコードだけじゃ説明しにくいからだよねぇ。



183 :XP狂信者:02/06/17 01:59
>>182
説明しにくいだろうねぇ。別に否定はしないよ。

Smalltalkerは普段は図使わないもの。
そのためにブラウザがあるんだし。でも、HTMLでの説明用には使えないわけだ。
ブラウズしてるうちに構造は頭に浮かんでくる。それで十分ってことさね。

会議で図書くのはいいんだけど、あくまで説明用。
メンテナンスの対象にはしないでおこうというXPスタイルは、
そういう割り切りがあるのさ。

実際、UMLのクラス図もJavaの宣言部分も
情報量は変わらないのだから、わざわざ図で書かなければならない理由
はないよ。javadocでドキュメント生成ぐらいしとけばあとはブラウズできる。







184 :カイロ:02/06/17 02:09
>>178
>そうなんだけどね。
>でも、多数のプログラマを見てきたところ、
>彼らはまだ日本語?で考えるのがやっとらしい。
>コードで考えられないようなんだ。

それは「コーディング」をまさに「日本語で書かれた仕様」を
プログラミング言語に翻訳する作業、ってとらえ方のことだよね。
いくらなんでも古すぎるよ。

>XPはスキルというか、コードネイティブな人向けなことは確かなので、
>その点彼らには非常にキツイだろうね。
>
>コードがネイティブに浮かばない人たちのことを
>SE−−−業務知識と日本語でなんとか考えられる人。
>PG−−−特殊な図や擬似コード(日本語)をなんとかプログラムに翻訳できる人。
>
>世間ではこういうことらしいよ。多少信じがたいのだが(苦笑)。

>おかげで、おれもドキュメントを要求されちゃって、
>わざわざ頭の中のコードから図描いて、PGに渡してたりしたんだけど、

それは間抜けでは?というか勘違いだと思うよ。キミが示している
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/ObjectModeling/article.html
にあるようなさまざま図がキミの頭の中にあるはず。もちろんコードもあったとしてもね。

設計ってのはこの「図」の部分であってコードってのはその一部でしかない。

すなわちコードで表せるのは設計の一部ってことだ。例えば人の書いた
コードを解析して同じ図を作ろうとしたら、それなりに苦労するだろ?それは
コードから失われた設計の一部を復元する作業に苦労するわけだよ。


185 :デフォルトの名無しさん:02/06/17 02:18
>>183
>会議で図書くのはいいんだけど、あくまで説明用。
>メンテナンスの対象にはしないでおこうというXPスタイルは、
>そういう割り切りがあるのさ。

「設計」の成果物をどうメンテナンスするかってのは、確かに厄介な話だ。
メンテナンスのうっとうしさから設計が軽視されるんじゃ本末転倒だから、
いっそのことメンテナンスしなくてもいいんじゃないの?と魔が差すことが
ある。

残されたものは常に正しくなくてはいけないってこともないと思うよ。もち
ろん最終成果物と一致していなければならないものはそうしなきゃならな
いけど、「常に」「すべて」ではない。

>実際、UMLのクラス図もJavaの宣言部分も
>情報量は変わらないのだから、

なるほど。ここが考え方が違う点なんだろうね。クラス図だけなら、確かに
情報量はコードにすべて包含されてるけど、設計の時に頭に浮かべるのは
クラス図だけじゃないじゃん(w


186 :デフォルトの名無しさん:02/06/17 12:18
ほらほら!読んで見れ!
http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1490-1

187 :HAMAIタンうぉっち:02/06/17 13:34
HAMAIの発言はすでに議論でさえなくなってきてる。
俺はこう思うっていいはってるだけ。
相手はいろいろ自分の説をうらづける文献をしめしてるのに、HAMAIは自己主張だけ。
こいつリアル中坊か?
--------------------------------------------
>私はハンフリーの調査には協力しましたがCMM派はありませんが、
>9000シリーズのカウンターオファーとしてXPの方が会社を危うくします。
>
>ぜひ、Agile software Developmet by Cockburnをご一読ください。
>http://www.amazon.co.jp/exec/obidos/ASIN/0201699699/249-5912653-0806759

XP*でも*会社を危うくする、と言った方がいいのでは。まあ、XPは強力な
手法なので、使い方を誤った時の悪影響は、ISO9000シリーズなどより大きい
でしょうね。


>これは私の持論ですがXPなどは戦術論であって
>CMMなどは戦略論だと思っています。

私に言わせれば、CMMよりXPの方がまだしも戦略的ですが。


188 :デフォルトの名無しさん:02/06/17 13:43
>私に言わせれば、CMMよりXPの方がまだしも戦略的ですが。

言わせない方法が知りたいです。

189 :デフォルトの名無しさん:02/06/17 18:52
>>181
>入力のほうはね。
>ItemFactoryのほうのelseifを問題にしたい。
>Hash使うとかで、文字列とClassの辞書作っておいて、さくっと呼びたい気分。
>初期化のところがダラダラとなるけど。
>
>説明用だからわかりやすいのを選んでいると思っているんだけどさ。
>
>OOPでは、elseifとかswitchは滅多に書きません。
>必須なのかどうかチェックしないとね。
>
>よいうことで、問題にしているのは、RUPとXPでは、
>コードの落ちつく先が違うってこと。
>余計なクラス作るのがRUP(分析ご苦労さま)。
>その分メンテが増えるんだよなぁ。

「ということで」って全然理由の説明になってないじゃん。



190 :デフォルトの名無しさん:02/06/17 19:08
>>186
名前は派手だけど、あんまりたいしたこと書いてないね。
看板に偽りありって感じだ。
「超初心者向けデザインパターン入門」って名前変えたほうがいい。

191 :XP狂信者:02/06/17 21:22
>>189
ん?
ああ、コードのどこが問題かはもともと明らかでしょ。
違う?なら失礼(苦笑)。

そっちの問題は明らかで、こちらが問題にしたいのは、
設計ダケやってると、クラス構成が大げさになるということだけ。
あるいは、Roseいじりまくってるとと言い換えてもいい。
最近はUMLかけるツールいくつも出てきているけどね。

で、コードセントリックなXPマンセーとつながるわけだよ。
言いたいのはそちらだけ(笑)。



192 :カイロ:02/06/17 21:50
>>191
>設計ダケやってると、クラス構成が大げさになるということだけ。
>あるいは、Roseいじりまくってるとと言い換えてもいい。
>最近はUMLかけるツールいくつも出てきているけどね。
>
>で、コードセントリックなXPマンセーとつながるわけだよ。
>言いたいのはそちらだけ(笑)。

あのサイトのコードのどこら辺が「大げさ」なの?
説明に関係ない部分を思いっきり削ってるんだから「おおげさ」とか
そういう観点から見ることがナンセンスだと思うが。

なんか君の言うことは全部こじつけだねぇ。

193 :デフォルトの名無しさん:02/06/17 22:32
ピンク本に登場する Ann は1つ受け入れテストを通すたびに End Zone Dance をやる、とのことで、

君らの職場ではテスト通す喜びを楽しんでますか?

194 :デフォルトの名無しさん:02/06/17 22:48
テストそのものに喜びを見出せないから、ごまかしてんじゃないの?

195 :デフォルトの名無しさん:02/06/17 22:54
ツレタ

196 :デフォルトの名無しさん:02/06/17 23:22
このスレ読んでると反XPの人の方が、まともに見えるんですけど。

197 :XP信者:02/06/17 23:29
XPの人の方がまともに見えるスレなんかありましたっけ?

198 :XP信者:02/06/17 23:32
>テストそのものに喜びを見出せないから、ごまかしてんじゃないの?

喜びが溢れ出してきて、ダンスでしか表現できないのでしょう。

ユニットテストじゃ踊れないけどね。

199 :デフォルトの名無しさん:02/06/18 00:06
>>198
そんなにうれしいなら、逆に金もらわにとな。

200 :カイロ:02/06/18 00:45
XPの胡散臭さが認知されてきてうれしい限りです。

201 :XP狂信者:02/06/18 00:56
胡散臭いねぇ。くくく。
おお、あの程度じゃ大げさじゃないんだ。すごいねぇ。
コード圧縮派vs沢山のクラス派の戦にもなりそうで楽しいよ。
はっきり言って、Utilに渡すパラメータ変えてるだけだから、
IItemだけで十分。
それもインタフェースにするのもアウト。XP派はそういうだろう。
説明用コードだからといって、ああいう設計してれば、
余計なコードが増えるのさ。
まぁ、仕事量が増えて見えるから金取れるんで、
それも行きかたのひとつではあるけどね。
XPがうまくいかない道でもある。
Simpleじゃない設計やるから、
ドキュメントで説明しないと駄目になるのさ。
簡単なコードで書くならば、
ドメインオブジェクトが見えているならば、
ついでにクラスのレスポンシビリティがはっきりしているなら、
あとはナビゲーションの問題だけなので、
設計に難しい部分なんてない。

ドキュメントがなくても呼び出されたクラスの何かのメソッドで、
コールパスでも見れば、設計の構造なんてのはおのずとわかる。
ここら辺で、インタプリターと戯れる人間と、
頭の中で考える派の戦にもなるわけだけどさ。

まぁ、ご自慢の頭で頑張ってください。


202 :カイロ:02/06/18 02:47
>>201
>簡単なコードで書くならば、
>ドメインオブジェクトが見えているならば、
>ついでにクラスのレスポンシビリティがはっきりしているなら、
>あとはナビゲーションの問題だけなので、
>設計に難しい部分なんてない。
>
>ドキュメントがなくても呼び出されたクラスの何かのメソッドで、
>コールパスでも見れば、設計の構造なんてのはおのずとわかる。
>ここら辺で、インタプリターと戯れる人間と、
>頭の中で考える派の戦にもなるわけだけどさ。
>
>まぁ、ご自慢の頭で頑張ってください。

例えばさぁ、BASICインタプリタをXPで開発できる?
それともXPじゃこんな「複雑」なプログラムは扱えない?
できるとして、その時どういった「設計」をどのタイミングでやるの?

203 :カイロ:02/06/18 02:53
>>201
>胡散臭いねぇ。くくく。
>おお、あの程度じゃ大げさじゃないんだ。すごいねぇ。

何度もいうけどさぁ、サンプルなんだから大げさとか意味ない。
キミはアホか?

204 :XP信者:02/06/18 07:58
>例えばさぁ、BASICインタプリタをXPで開発できる?
>それともXPじゃこんな「複雑」なプログラムは扱えない?
>できるとして、その時どういった「設計」をどのタイミングでやるの?

XPの設計タイミングは普通のスパイラル型と変わらないでしょ。
そのとき必要なスコープの分だけ設計する。


205 :デフォルトの名無しさん:02/06/18 12:05
>>196
> このスレ読んでると反XPの人の方が、まともに見えるんですけど。

なんか・・・XP も 反XP もどっちも厨に見えてきてるんだが気のせい?(w

206 :デフォルトの名無しさん:02/06/18 12:19
所詮は耳学問だし

207 :HAMAIタンうぉっち:02/06/18 13:51
何の足しにもならない当たり前のこといってんだか。

----------------------------------
>> あくまで相対的にですが。ISO9001は信頼性重視生産性軽視、XPは信頼性軽視
>> 生産性重視だと思います。
>> XPで信頼性を重視した開発ができないとは思いませんが、XPらしさといった
>> ものは薄れると思います。
>う〜ん、そうでしょうか・・・
>相対的であってもXPが信頼性軽視とは思わないです。
>と言うより逆に信頼性重視ではないでしょうか。
>
>回帰テストを徹底して行ったり、YAGNIの精神で必要最低限の実装を
>行ったりするのは、堅固なアプリケーションを構築する為の手段
>だと思います。

XPの場合、信頼性を高めるというよりも、ある程度以上の信頼性を確保する
という方が適切だと思います。欠陥が多いとXPのように変更を繰り返す
と欠陥が欠陥を生んで収拾がつかなくなるおそれがあります。

ソフトウェアの変更には、常にミスが入り込む危険性があります。
信頼性を高めるためには、可能な限りソフトウェアを変更しないように
すべきであり、「変化ヲ抱擁セヨ」というXPの考えと対立します。


>XPにおいて生産性は、信頼性を高める事で結果的には
>生産性も高まる、と言うような考え方だと思っています。

ある程度までは、信頼性と生産性は両立しますが、それ以上に信頼性を追求
すればコストが急激に上昇することになります。欠陥のないソフトウェアを
開発する方法は未だに見つかっておらず、近い将来見つかる可能性も
ありません。したがって、ある程度以上欠陥を減らすには、欠陥を捜して
見つかった欠陥を慎重に修正するしかありませんが、欠陥を捜すコストは
組み合わせにより急激に増大しますから、信頼性を高めようとするとコストが
急激に上昇することになります。


208 :デフォルトの名無しさん:02/06/18 13:58
>>204
普通のスパイラル型と変わらないなら、XPだとどこがいいの?
スパイラル型でもテストはするよ。

209 :デフォルトの名無しさん:02/06/18 13:58
kimochi...

210 :デフォルトの名無しさん:02/06/18 14:03
>>207
ガキ(HAMAI)は大人の話の仲間に入れてもらいたくて、必死と思われ。

211 :デフォルトの名無しさん:02/06/18 14:18
XPで開発したとして、間に1年ぐらいブランクがあったとする。
1年後にも変化を抱擁できるの?


212 :デフォルトの名無しさん:02/06/18 14:22
>>211
ユニットテストがあればできる。

213 :デフォルトの名無しさん:02/06/18 14:22
201 vs 203は203が正しいと思う。
201はソースの細部にこだわりすぎ。

214 :デフォルトの名無しさん:02/06/18 14:24
>>212
じゃあ元のメンバーが誰もいなくなってもできるの?

215 :デフォルトの名無しさん:02/06/18 14:25
おれはXPに期待してる。
でも、別に万能って思ってるわけじゃない。
あんちの人は反例が極端過ぎないか?
どうしてそんなにむきになるのかなあ。

216 :デフォルトの名無しさん:02/06/18 14:27
俺も知りたい。
XPで開発されたソフトの変更を別の会社に頼めるのか。
その時ソースコード以外は要らないのか。

217 :デフォルトの名無しさん:02/06/18 14:30
>>216無理。もう一度開発しなおすしかない。

218 :デフォルトの名無しさん:02/06/18 14:33
>あんちの人は反例が極端過ぎないか?

俺にはどれもすごく普通の話だと思うけど、どの辺が極端が?

219 :デフォルトの名無しさん:02/06/18 14:34
>>216
XPは引継ぎは出来ない。

220 :215:02/06/18 14:38
>>218
BASICインタプリタの開発とかって。そんなのおれたちの仕事とは違うだろ。
それに元メンバがいなくなって1年後に苦労するのは、なんだっておんなじでわ?

221 :デフォルトの名無しさん:02/06/18 14:43
XPを支持してるのはたいしたプログラム作ったことないやつばっか。

222 :215:02/06/18 14:45
>>221
期待通りの反応をありがとう。
そういうのに限って。。。だよなー。
あーあ。

223 :デフォルトの名無しさん:02/06/18 14:50
自分の周りにいるやつを基準に考えないことだな。>222
井の中で満足してろ!

224 :215:02/06/18 14:56
だってさあ、BASICインタプリタ開発する人って世界に何人いるの?
そういう仕事なら、XPとかじゃなくても、まあそうだろ。
全国300万のプログラマが日々作ってるようなシステムには、
XPがいんじゃないの?君もその一員だろ。
それとも、授業でHelloWorldでも作ってる?

225 :カイロ:02/06/18 15:09
簡単なインタプリタを作るって仕事はそこそこあるよ。もちろん絶対量としては少ないけど、できるところはあまり多くないから(つーか尻ごみするとこが多いから)結構仕事としてはおいしい。

226 :デフォルトの名無しさん:02/06/18 15:11
>>205
ま、妥当な判断だね(w
こんだけ煽ってるんだから。

227 :カイロ@モバイル:02/06/18 15:15
>>224
古いコードをメンテするぐらいなら作り直す、って性質のプログラムにはいいかもね。

228 :カイロ:02/06/18 15:26
>>216
頼めないだろうねぇ。
XPをやるような連中が、そんな仕事引き受けるとは思えない。コードもチーム特有の文化にべったり依存してるだろうから、
物理的にもできないだろうね。
いや、やったという実例があれば聞きたいけど。

229 :腐海在住の名無しさん:02/06/18 16:20
■■■■■■■■■■■■
 このスレ、壊れてる。
■■■■■■■■■■■■

>>216-217
可能だろ。
言葉によるコミュニケーションもできんのか?
保守を担当してたメンバーを一日貸し出して、納得いくまで説明させろよ。
XPをホントに実践してたなら、そいつは何でも知ってるだろ。


230 :カイロ@モバイル:02/06/18 16:29
>>229
参考までに聞くけど、1日でいいわけ?

231 :腐海在住の名無しさん:02/06/18 16:37
>>230
それは状況に依存する。

俺は「不可能ではない」と言いたかった。
出来ないと決め付けるのは嫌いだから。

232 :カイロ:02/06/18 16:49
それなら何でも不可能じゃないと思われ。ウォーターフォールもね。
実際、1日で引継ぎが完了するなら、すばらしい長所だよ。
俺は無理だと思うけどね。

233 :デフォルトの名無しさん:02/06/18 16:51
1日どころか1イテレーションは貸し出さないといかんのでないか。

234 :デフォルトの名無しさん:02/06/18 16:54
顧客役も張り付ける必要あるよね。

235 :カイロ:02/06/18 17:39
現実問題として引継ぎなんてできないと思うけど。

236 :デフォルトの名無しさん:02/06/18 17:58
>>216-217

引継ぎの対象にxUnitのテストコードが含まれるとは思わないわけ?
リリースコードのみで引き継ぐなんてXPのチーム内でも不可能だよ。

>>235

「思うけど」ばっかりじゃん。
せめてJUnitぐらい触ってから物言えば?

237 :デフォルトの名無しさん:02/06/18 18:08
>>236
JUnitがどういうものかぐらいは当然知ってると思うけど(笑)

しかしまあ、XPならテストコード群こそがソフト自体より重要とすら言えるわけなので
引き継ぐならテストコード群を渡すのは必須だよな。
むしろ既存コードは(スタイルが違うなどで障害になるぐらいなら)引き渡さなくてもいいぐらいでは。

238 :カイロ:02/06/18 19:22
>>>235
>
>「思うけど」ばっかりじゃん。
>せめてJUnitぐらい触ってから物言えば?

じゃ改めて聞くけど、テストコード込みなら引継ぎ可能なわけ?
その時どれくらいの日数が必要なの?ゼロでよいの。

>>237
>しかしまあ、XPならテストコード群こそがソフト自体より重要とすら言えるわけなので
>引き継ぐならテストコード群を渡すのは必須だよな。
>むしろ既存コードは(スタイルが違うなどで障害になるぐらいなら)引き渡さなくてもいいぐらいでは。

それはもう一度作り直すってことだよね。テストコードがある分だけマシってだけで。
例えばテストコードだけある状態で、元の仕様とまったく同じものを作るとすると、
どれくらいのリソースで作れるの?最初に作った時の1/2ぐらい?
(もちろん一概に言えないから、適当でいいよ)


239 :デフォルトの名無しさん:02/06/18 19:32
>>238
>その時どれくらいの日数が必要なの?ゼロでよいの。

またそんな極端な例を出しちゃって、むきになりなさんなって。
テストコードの量によって可変な事ぐらい解ってるくせに。

しかし、JUnit使ったことが無いってのは否定しないのな(w
あんたの正直さに惚れてしまいそうだよ。

240 :デフォルトの名無しさん:02/06/18 19:55
テスト群が詳細仕様書なんだな。
ただし、合致性を自ら判断してくれる点が自然言語の仕様書と違うところだな。
また、仕様変更に際してまず最初に更新され、最新の仕様を反映していることが確実に期待できる。
しっかりとテストが書かれていれば、だれに書かせても出てくるコードの品質が保証できる。

>>237 >>238
まあ、すでに動く物があるのなら全部捨てて作り直すのはかなりもったいないとは思う。
リソース自体はいくらか少なく済むにしても、既存のテストが全部パスするまでは
まったく作り上げていく実感がなく、XP的にモチベーション上がらないかも。
とはいえ、それによってコード全体に関する知識がチームに蓄積されるので
チームメンバーの派遣は不要になるかもしれない。

241 :デフォルトの名無しさん:02/06/18 20:06
>>238
>例えばテストコードだけある状態で、元の仕様とまったく同じものを作るとすると、
>どれくらいのリソースで作れるの?最初に作った時の1/2ぐらい?
>(もちろん一概に言えないから、適当でいいよ)
まあ、半分以下だと思う。
最初のときはテストコードも作ったわけだし、テストコードを書く方が大変だからね。
設計・検討はテストに集約されるし、分量もターゲットコードと同等以上になる。

242 :XP狂信者:02/06/18 20:12
http://www.ne.jp/asahi/e/yamane/software/engineering/xp/daiary/xp_fever.html

XPでの引き継ぎ例は上記のスタイル。
まぁ、理想的な状況だけどな。

ついでに、保守フェーズに入ったら、人手カットするタイプの会社は、
XPチームに発注すべきではないな。これは断言。
ソフトウェアはそういうものではないのだから。

XP教科書のインソーシングあたりをきっちり読んでおくこと。


243 :デフォルトの名無しさん:02/06/18 20:18
>>242
前半だけど、それがXPの営業の仕方か。おもろい(笑)

244 :XP狂信者:02/06/18 20:24
ついでにBasicのインタプリター?
もろ、XP向きじゃないか。

ポケコン並みの最低仕様からスタート。
変数名2文字。データ型doubleのみ。
グローバル変数のみ。
配列なし、Subroutineあり、
ワンパスで、くそノロイソフトからスタート。

大体500行も書けば動き始めるから、
一人でいけるな。一ヵ月後あたりにはリリース可能。

もっとも、その手の簡単なインタプリターなんぞは、
yaccなりbisonなり使えば簡単にでっちあげきくから、
XPでスクラッチから開発したほうがいいかどうかが問題だが。



245 :XP信者:02/06/18 22:48
>>208

>普通のスパイラル型と変わらないなら、XPだとどこがいいの?

細かいことは教典を読んでいただくとして、XPが良いのは、その価値観。
XPは、その価値観にしたがって、12(14?)の、今までに有効であると
実証されてきた、プラクティスで構成されている。

だから、XPのどの部分を切り取っても、別に珍しい部分は無く、
一つ一つなら有効性に疑問を持つ人も少ないはず。
ただし、一つ一つを見ると、副作用の影響も目立つけどね。



246 :カイロ:02/06/19 01:05
おぉ、なんかたくさんレスがついてるね。狂信者の紹介リンクは
いつも面白いから、内心感謝してるよ。コメントつけたいんだけど、
ちょっと今日は本業がハードだったんで頭が働かん。
ちょっとまってね。スマソ。

247 :カイロ:02/06/19 16:17
>>240
>テスト群が詳細仕様書なんだな。
>ただし、合致性を自ら判断してくれる点が自然言語の仕様書と違うところだな。
>また、仕様変更に際してまず最初に更新され、最新の仕様を反映していることが確実に期待できる。
>しっかりとテストが書かれていれば、だれに書かせても出てくるコードの品質が保証できる。

「テスト郡」の完成度とか品質はどういう仕組みで保証するの?
もちろん従来の手法でも「仕様書」の質を保障するのは困難だけどね。

>リソース自体はいくらか少なく済むにしても、既存のテストが全部パスするまでは
>まったく作り上げていく実感がなく、XP的にモチベーション上がらないかも。

正しいと思う。XPの本質がどこにあるかを鋭くえぐっている。
決められたことをやるのが「いや」なわけだよね。そりゃ同感だが、XPは
それを解決してるの?ちょっと目の触れない向こう側(顧客側)に遠ざけただけじゃない?(w

>>241
>最初のときはテストコードも作ったわけだし、テストコードを書く方が大変だからね。
>設計・検討はテストに集約されるし、分量もターゲットコードと同等以上になる。

いいかえると設計とテスト(の環境作成)に全体の半分の工数を
かけるってことだね。そんなもんだろうって気がする。でもそれだと
ウォーターフォールに比べて、効率がいいってほどじゃないよね。

テストコードの管理とかは大丈夫なの?


248 :デフォルトの名無しさん:02/06/19 16:42
>>242

>XPでの引き継ぎ例は上記のスタイル。
>まぁ、理想的な状況だけどな。

ひきつぎ30分、うーん。
ま、スムーズに引き継げるのはその程度の規模ってことでよい?
似たような画面がたくさんあるWebとかの開発だったら、こんな感じかなぁ。

>ついでに、保守フェーズに入ったら、人手カットするタイプの会社は、
>XPチームに発注すべきではないな。これは断言。
>ソフトウェアはそういうものではないのだから。

それは結構なことだけど、現実問題として金勘定はどーすんの?
そのシステムが稼動している間は、ずっと金を出せと?

かまわんが、あらかじめ想定している予算を1回でぽんと出すか、
何ヶ月、何年にもわたって分割で払うか、ってことになるだけだぞ。
実際そういった形のプロジェクトもあるが。

それはそうと、その会社の専属(?)開発者になるならともかく、
あと他の仕事とのスケジュールは大丈夫なの?



249 :デフォルトの名無しさん:02/06/19 16:46
>>244
>一人でいけるな。一ヵ月後あたりにはリリース可能。

どちらかというと、複数のメンバでどう進めていくかが聞きたい。
(けど俺の聞き方もいまいちだね。我ながら。ちょっと考えるよ。)

250 :XP狂信者:02/06/19 22:58
メンテナンスを最低でも自社ですることという意味だ。
メンテナンスを自社でするなら、途中でプロジェクトに突っ込み、
そのソースのカルチャーに慣らしておく必要がある。
これがインソーシング。

もっとも、顧問料などの名目で、
ある程度の金額を毎年払うことをお勧めする。

新しいソフトウェア企画の相談に乗ってもらえるし、
OSのバージョンアップやJDKのバージョンアップや
データベースドライバ関連のバージョンアップなどなど、
ソフトウェア本体に手を入れなくてもよさそうだけど、
そうでもなさそうな作業をお願いする必要があるからな。

先払い費用分で消化できる作業量なら、追加費用ナシってことでな。
会社としては、経営が安定するので願ったりだ。
フルタイム費用を考えるとバカ高いのだが、ある程度、本質的な作業量が
読めるはずなので、その量に応じて適度な金額を予算に入れておけばよい。
例えば、2人日分、10万円毎月程度でも結構お互いにおいしい。

自社でやれるならそれでもいいが。
まぁいずれにせよ、XPでは保守も開発も大した違いはない。

基本的に会社としては、どんどん長い契約になるように望んでいるのが、
XPスタイル。あるいはソフトウェアクラフトマンシップということになる。
売り切って、ハイさよならー。後は知りませんというスタイルではない。

メンバーの交代については、きっちりXPがされている場合は、
半年とか1年に1割程度が入れ替わっても問題にはならないので、
契約が長く続くことの問題もないだろう。

いずれにせよ、メンテナンスフェーズだから人数を10−>1のような
スタイルはやめるべきだ。そんなことやってるから、ソフトウェアがハードウェア
なみにカタクナになってしまう。
ハードの寿命がきました、超特急で次のバージョンなどといっても
そうは問屋がおろさないことぐらい、そろそろ学習してもよいだろ?

いわゆるTCOを最小化しようとするならXPスタイルは、
かなり役にたつ。

OSのバージョンアップ。動作しますか?
これの解答は全自動のユニットテストとアクセプタンステストを走らせるだけ。
これで判断できるんだからな。

ウォーターフォールじゃ、できるハズとは言えても、実績データとしては
出せまい。また、総合テストの費用をかけないとならんが、普通それは無理。











作業内容は、改善項目の見積もりの相談。


251 :カイロ:02/06/20 02:56
>>250
>先払い費用分で消化できる作業量なら、追加費用ナシってことでな。
>会社としては、経営が安定するので願ったりだ。

不況になるとそういう維持費的なものは真っ先に削減対象になるが。

>ハードの寿命がきました、超特急で次のバージョンなどといっても
>そうは問屋がおろさないことぐらい、そろそろ学習してもよいだろ?

ちゃんとしたとこは、ハードにしろソフトにしろ、そういったことも考慮に
入れるよ。保守契約に盛り込むなり、時期を見て早めに乗り換えるなり。
2000年問題でもそうだったけど。

そういった必要性を認識しているところは妥当なコストをかけて現在でも
やっているのだから、今認識していないところは、この先も認識が変わる
かねぇ。

ハードの寿命ってのは個体の寿命じゃなくて、その系列の製品が製造され
なくなる寿命だよね。をどれくらいとして論じているのかわからんが3〜4年
として、その間従来型なら一度もマイナーチェンジをしない製品に対して、
XPだからといって毎月10万円とか払うかな。つーか払うユーザは今も保守
費用として払ってる。

ま、ソフト開発を成果物の提供ではなく、サービスの提供とする考え方に
近いんだろうね。この方向は今後どうなるのか読めん。

>ウォーターフォールじゃ、できるハズとは言えても、実績データとしては
>出せまい。また、総合テストの費用をかけないとならんが、普通それは無理。

大規模なものはテスト項目の詰めやテスト環境の開発なども当然やる。
顧客がものを妥当なコストをかけてね。本来こういったことを厳密に顧客と
取り決めて、その水準の品質を維持するのが、ウォーターフォールの本来
の姿だから。君の周りにはそういうことをやらないウォーターフォール型が
多いのかもしれないがね。ま、どうしてもウォーターフォールは重厚壮大に
なるから、効率は誇れたものじゃないが。

でもさ、繰り返し聞くけどXPでテストの質はどう保証するの?
フィーリング?(w

252 :デフォルトの名無しさん:02/06/20 03:32
「質」とは?

253 :XP信者:02/06/20 06:52
>大規模なものはテスト項目の詰めやテスト環境の開発なども当然やる。

小規模だとしないの?

>でもさ、繰り返し聞くけどXPでテストの質はどう保証するの?

「保証」とは?
ウォータフォール風に言えば、誰が判を押すかって事?



254 :XP信者:02/06/20 07:10
>>248

>ひきつぎ30分、うーん。
>ま、スムーズに引き継げるのはその程度の規模ってことでよい?

よくない。

その程度が何をさしているのかはっきりしないけど、論理的に正しいのは
「その程度の規模はスムーズに引き継げる」ってこと。

つまり、他の方法では「その程度の規模ですらスムーズに引き継げない」ってこと。

スムーズ?


255 :カイロ:02/06/20 07:44
>>253
>>大規模なものはテスト項目の詰めやテスト環境の開発なども当然やる。
>
>小規模だとしないの?

顧客の希望とコストの兼ね合いだろうね。
顧客が望むならもちろんするよ。望まないのであれば、それなりのものだろうね。
概略&詳細仕様書だけではなくテスト仕様が合わさって「仕様」だから。

>>でもさ、繰り返し聞くけどXPでテストの質はどう保証するの?
>
>「保証」とは?
>ウォータフォール風に言えば、誰が判を押すかって事?

責任もまあそうだけど、テストの妥当性の検証をどうするのか?だね。

テスト仕様と詳細仕様がどの程度整合しているか、とかテスト仕様に対して
テストプログラムが正しいか、負荷のかけ方とか期間とか、が妥当かどうか、とか。

顧客とそれなりの時間をかけて(ウォーターフォール的に順に(笑))詰めてい
くわけだけど、これは結局1つのプロジェクトだ。大規模なソフトのテスト環境の
線表は小〜中規模のソフト開発本体顔負けの規模になるね。それだけ力を入
れなきゃ妥当な(と多くの人が思う(笑))テストにならない。

テストプログラムのテストも必要な箇所はする。(と無限にやったら間抜けだから、
どこかでやめるけど。)

XPのテスト内容は開発側と顧客側でどういった話し合いの元で決まるのかな?と。
決まったテスト内容と実際のテストコードの整合性はどの程度テストされるの?
なんか神秘的な力でどんなテストコードを書くと正しいテストが出来るかが、
たちどころにわかっちゃう?

256 :XP信者:02/06/20 08:00
>XPのテスト内容は開発側と顧客側でどういった話し合いの元で決まるのかな?と。
>決まったテスト内容と実際のテストコードの整合性はどの程度テストされるの?
>なんか神秘的な力でどんなテストコードを書くと正しいテストが出来るかが、
>たちどころにわかっちゃう?

XPの教本に神秘的な力を使ったプラクティスがあるように読み取れた?

XPだって、顧客とそれなりの時間をかけて(スパイラル的に)顧客の承認のもとで
受け入れテストを構築していくよ。

>顧客の希望とコストの兼ね合いだろうね。
>顧客が望むならもちろんするよ。望まないのであれば、それなりのものだろうね。
>概略&詳細仕様書だけではなくテスト仕様が合わさって「仕様」だから。

顧客が望む品質を保証するテストを、妥当なコストで実現できるの?
つまり小さなテストには小さなコストで、大きなテストは大きなコストでってことだけど。

>ま、どうしてもウォーターフォールは重厚壮大に
>なるから、効率は誇れたものじゃないが。

ってあるように、重厚壮大なテスト計画は、大規模な開発でしかペイしないんじゃないの?


257 :カイロ:02/06/20 08:02
>>254
>その程度が何をさしているのかはっきりしないけど、論理的に正しいのは

30分で全体の大雑把な構造と重要部分のある程度立ち入った構造が
見渡せる規模。数1000行〜1万行ぐらいじゃない。(「俺は10万行でも
30分で構造を見渡せるってやつもいるかもしれないが)

>つまり、他の方法では「その程度の規模ですらスムーズに引き継げない」ってこと。

これはそんなことないと思うけどね。



258 :カイロ:02/06/20 08:38
>>256
>XPだって、顧客とそれなりの時間をかけて(スパイラル的に)顧客の承認のもとで
>受け入れテストを構築していくよ。

その流れがいまいちとらえ難いのだが。

詳細仕様、テスト仕様、テストプログラムを相互に検討すれば、少なくとも3者で
矛盾がないか程度は検証できる。(3者が同じように間違ってる場合もあるけど。)
テストコードしかなければ、その矛盾をチェックする方法は使えないよね。

>顧客が望む品質を保証するテストを、妥当なコストで実現できるの?
>つまり小さなテストには小さなコストで、大きなテストは大きなコストでってことだけど。
>
>>ま、どうしてもウォーターフォールは重厚壮大に
>>なるから、効率は誇れたものじゃないが。
>
>ってあるように、重厚壮大なテスト計画は、大規模な開発でしかペイしないんじゃないの?

XPのテスト(コード)が手間隙かけて行うウォーターフォールのテストと同等かそれ
以上の正当性を持っていることを、第3者に対して簡単に示せるの?開発者と
顧客側の担当者が馴れ合いでテストコードを決めていないかどうか、監査可能?

もしそれが可能でかつ効率よくテストが行えるなら、その点はXPが優れていることを
認めてよいよ。

259 :デフォルトの名無しさん:02/06/20 09:10
> 顧客側の担当者が馴れ合いでテストコードを決めていないかどうか、監査可能?

そこは、もう XP とか開発とか、そういう領域越えてしまってる。

そういうことは、もう人の問題。組織の問題とか、コミュニケーションの問題に関する
別途に専門書はたくさんある。そちらを参考にして、顧客と「話し合い」してください。

260 :カイロ:02/06/20 10:11
>>259
>> 顧客側の担当者が馴れ合いでテストコードを決めていないかどうか、監査可能?
>
>そこは、もう XP とか開発とか、そういう領域越えてしまってる。

いいや全く越えていない。越えているのは君の頭だろう。
ドキュメントが何で必要かといえば、最終的にはこれに尽きる。

>そういうことは、もう人の問題。組織の問題とか、コミュニケーションの問題に関する
>別途に専門書はたくさんある。そちらを参考にして、顧客と「話し合い」してください。

なにパニクってるの(w
キミには無駄な紙くずにしか見えないドキュメントの山も必要な場合には必要なの。
だいたい意味不明だよ、キミの文章は。


261 :カイロ:02/06/20 10:19
あたりまえだけど、それと同質のテストをXPに求めるほど俺は馬鹿じゃないよ。
XPが提供する「質」は別なものなのだろ?
で、それを説明してくれといってるわけだ。
相手に一方的に説明を求めるのもなんだから、ウォーターフォールの重厚壮大な
テストが提供する「質」を説明した。次はXPが提供するテストの「質」を説明していただきたい。

262 :カイロ:02/06/20 10:31
もうひとつ言わせてもらえば、こういったドキュメントの意味とか価値とかを、
自分の範囲ではない、とかいうなら、ドキュメントを無意味とか批判する資格ないよ。
しっかりその意味を考えた上で、これはこういう理由だから、ドキュメントを書く
コストがメリットに見合わない、というなら、まともな意見だと思うけどね。

263 :デフォルトの名無しさん:02/06/20 12:06
XP = eXtreame imPotence

264 :デフォルトの名無しさん:02/06/20 12:57
横から素人なんすけど、極論すると、
1.XPでもウォーターファールでもやるべきことは一緒
2.XPはちょこちょこやり、ウォーターはどかんどかんとやる
ということのような気がしてきたんすけど。
それなら、ちょこちょこやった方が絶対いいと思うだけど。

265 :腐海在住の名無しさん:02/06/20 15:30
>>261
話の流れに致命的な間違いがある。

XP本の中でテスト工程として明示されてはいないが、XPにあって、
ウォーターフルーに無い「テスト工程」があるじゃないか。

XPでは「驚くほど短期間でのリリース(※1)」がテスト工程を兼ねているんだ。
そうは思わなかったかな?

第一、クライアントの一言で変わりかねない仕様書の通りに動くからといって、
テストの「質」が十分だと思っているらしいが、私にはそうは思えない。
その点、クライアントに実際の挙動を見せた上で「思った通りか?」と聞くXP的なテストは、
仕様書通りか?というテストよりは、クライアントの要求を汲んでいると思うのだが…。
XPのテストの「質」。こんな説明ではどうかな?

※1:完成ではなく、公開のことね。ソフト開発に終わりなど無いのだから。

266 :デフォルトの名無しさん:02/06/20 15:45
正直、糞の役にもたたない仕事のための仕事みたいな事務作業
をやりたくないので、XPまんせーです。




267 :カイロ:02/06/20 16:34
>>265
>その点、クライアントに実際の挙動を見せた上で「思った通りか?」と聞くXP的なテストは、
>仕様書通りか?というテストよりは、クライアントの要求を汲んでいると思うのだが…。

だからXPのテストの正当性をささえるのはフィーリングではないの?と
いったのだけどね。(w

フィーリングをよい意味ととるか悪い意味と取るかは人それぞれ。

>XPのテストの「質」。こんな説明ではどうかな?

一つの説明だと思うよ。サンクス。



>話の流れに致命的な間違いがある。
>
>XP本の中でテスト工程として明示されてはいないが、XPにあって、
>ウォーターフルーに無い「テスト工程」があるじゃないか。
>
>XPでは「驚くほど短期間でのリリース(※1)」がテスト工程を兼ねているんだ。
>そうは思わなかったかな?

何も俺はXPのテストはおかしいとか批判しているわけじゃなく、
どういうものなのだ?と聞いているだけなのだから、間違いも何もないと思うが。

>第一、クライアントの一言で変わりかねない仕様書の通りに動くからといって、
>テストの「質」が十分だと思っているらしいが、私にはそうは思えない。

誰が十分だと思っているのかねぇ。目がおかしいんじゃない?
xxxの妥当性の根拠はyyyに基づく、ってのは絶対的にxxxが正しいとか
yyyが正しいとかいうもんじゃない。当たり前だよね。

駐車違反の取締りの妥当性の根拠を道交法に置くってのは、道交法が正しい
なら、駐車違反の取り締まりは正しいってだけの話だ。道交法も駐車違反の
取り締まりも絶対的に正しいなどとは誰もいっていない。

同じ言い方をすれば

>その点、クライアントに実際の挙動を見せた上で「思った通りか?」と聞くXP的なテストは、

この部分は

顧客が短期リリースの成果物を使ってみて下す評価を、XPのテストの妥当性の
根拠とするってなるかな。

俺はどっちかつーとテストコードによるテストの方の話をしてたんだけど、
キミの上げた点は、もちろん重要だとは思うよ。異議がなかったからそもそも
話題に出さなかったけど。

>>266
>正直、糞の役にもたたない仕事のための仕事みたいな事務作業
>をやりたくないので、XPまんせーです。

この短い文章がすべて主観で構成されている。見事だ。


268 :ふかいざいじゅうのななしさん:02/06/20 17:54
>>267
スマソ。最初の行は完全に余計だったな。
俺が話の流れを追えていないだけだったようだ。
逝ってくる。

269 :カイロ:02/06/20 17:58
>>268
いやいや、全体的に俺の文章は煽り調子で書いてあるけど、
腹を立ててるわけじゃないから、逝かなくていいよ。(w


270 :XP狂信者:02/06/20 22:00
で、いったい何を問題にしているのだ?

オレがいえるのは、
Windows95で動いていたソフトを98対応にするのに、
ウォーターフォールなら、半年や一年はゆうにかかる可能性がある。

Windows2000で動いていたソフトをXP対応にするのに、
動くかどうかの判断さえ、一週間以内に帰ってくることはない。
電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。

あるいは、Linuxのカーネルやglibcをセキュリティ対策で
アップグレードしたら、使えなくなる可能背のあるソフトウェアを
作っていてもウォーターフォールプロセスでは致し方ない。

あるいは、保守メンテナンス費用を払っていても、
アップグレードには時間がかかり実質的には再開発が必要である。
すなわちメンテナンス費用は払う必要のない費用である。

こういったところだが、反論あるの?
というより、ちゃんとテストカバレッジ出してる?
出しているなら金持ちソフトウェアハウスだな。

でもテスト仕様書は、手書きなんだ。ふーん。
結局2,3ヶ月テストするんだ。気狂いそうにならない?退屈でさ。

僕らはボタン一発。GreenかRedかだけだからね。簡単。

結局、ソフトウェア開発で自動化しなければならなかったのは、
設計フェーズではなく、テストフェーズだったという
ベックのアイディアはすばらしい。

ベックマンセー。XPマンセー。








271 :カイロ:02/06/20 22:54
>>270
>Windows95で動いていたソフトを98対応にするのに、
>ウォーターフォールなら、半年や一年はゆうにかかる可能性がある。

それはかかるかもね。

>Windows2000で動いていたソフトをXP対応にするのに、
>動くかどうかの判断さえ、一週間以内に帰ってくることはない。
>
>電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。

これは開発プロセス云々というより仕事のスタイルがそういうスタイルが
多いということでは?開発者がその時別な仕事をしていれば、すぐには
対応できない。

迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
俺はあまりその方向に力を入れるべきとは思わないね。作業者には
一つの仕事に集中させたい。繰り返すけど、にもかかわらず機動性の
ある会社は本当にすばらしいと思うよ。

>あるいは、Linuxのカーネルやglibcをセキュリティ対策で
>アップグレードしたら、使えなくなる可能背のあるソフトウェアを
>作っていてもウォーターフォールプロセスでは致し方ない。

セキュリティ対策はだいたい保守契約の範囲で行うことが多いね。
カーネルを入れ替えて動作チェックする程度のものであれば。
チェックした結果動作せず、ソフトの変更が必要って場合は、別途
話し合う。

ま、セキュリティパッチ程度の変更で動かなくなるのは、もともと
バグに近いようなコーディングをしているとかだね。

他の多くのソフトでも問題がでるようなメジャーアップグレードの場合は
別途話し合いだろうね。



272 :カイロ:02/06/20 22:54
>あるいは、保守メンテナンス費用を払っていても、
>アップグレードには時間がかかり実質的には再開発が必要である。
>すなわちメンテナンス費用は払う必要のない費用である。

それはなんか偏った見方じゃないの?セキュリティパッチにも
対応しないなら、君の言うとおりその会社にメンテナンス費用を
払う必要はない。というよりすぐにそんな会社に仕事を頼むのを
やめろ。

他のソフトでも問題が出るようなメジャーアップグレード
については、メンテナンスに含めないと思うよ。この場合どの
程度かはケースバイケースだけど「再開発」だろうね。

>こういったところだが、反論あるの?

といったところだ。俺があんたの客なら、こういったことがXPだと
魔法のように解決する、とか言われても信じられないねぇ。

>というより、ちゃんとテストカバレッジ出してる?
>出しているなら金持ちソフトウェアハウスだな。

最初から要求する顧客はあまりいないね。というか今のところ俺はないね。
デスマーチになって、不安になった顧客が、要求するってことはあるねぇ。
その場合重要なモジュールについては行うね。開発会社内で自分たちの
デバッグのためには行うことはあるね。

>でもテスト仕様書は、手書きなんだ。ふーん。
>結局2,3ヶ月テストするんだ。気狂いそうにならない?退屈でさ。

まぁ、その辺は考え方だからね。いろんな人間がいるから向き不向き、
好き嫌いはいろいろあるから、ある程度適材適所に配置する。(裁量の
範囲でね。そもそもテストは開発とは別の人間が行うことが望ましいし。)

お役所で働いている人間がいるように、ソフト開発会社でもお役所的
な仕事をする人間はいる。すべての人間がクリエーター(笑)である
必要もないし、あるはずもない。

>僕らはボタン一発。GreenかRedかだけだからね。簡単。
>
>結局、ソフトウェア開発で自動化しなければならなかったのは、
>設計フェーズではなく、テストフェーズだったという
>ベックのアイディアはすばらしい。

で、最初の質問の答えだ。俺は何を問題にしているかといえば、
テストの作業そのものは自動化出来ても、テストの内容の検討
(一種の設計だね)は、当たり前だけど自動化できない。これは
本来のソフト開発と同じように、テスト工程も「開発」なわけだ。

君が言ってるテストの自動化ってのは、ソフト開発で言えば、
コンパイル・リンク作業が自動化された、とはしゃいでるだけだ。



273 :XP信者:02/06/20 23:09
>迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
>俺はあまりその方向に力を入れるべきとは思わないね。

そう思うならXPは永遠に理解できないよ。
価値観が違うからね。

現在の顧客の多くは、迅速性にコストを支払う価値があると考えている、
ということを前提にしているのがXPであるから、その価値観を抜きにして
話しても仕方ない。


274 :XP信者:02/06/20 23:13
>30分で全体の大雑把な構造と重要部分のある程度立ち入った構造が
>見渡せる規模。数1000行〜1万行ぐらいじゃない。

なるほど。鶏と卵だね。

>>つまり、他の方法では「その程度の規模ですらスムーズに引き継げない」ってこと。
>これはそんなことないと思うけどね。

242のリンク先が、そう主張しているってこと。
248で誤読しているようだったので、訂正しただけです。


275 :カイロ:02/06/20 23:30
>>273
>>迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
>>俺はあまりその方向に力を入れるべきとは思わないね。
>
>そう思うならXPは永遠に理解できないよ。
>価値観が違うからね。

もとの文脈は、現在やっているプロジェクトのメンバを一時的に
借り出してきて、迅速にイレギュラーな対応(例えばWin95で
開発されたソフトがWin98で動作するかの問い合わせがあれば、
すぐに確認し答える)をすべきか否かについてだ。

どのプロセスでやるにしろメンバをなるべく一つの仕事に集中させたいという
意味だ。念のため書くけどね。だからそれを含めて価値観が違うというなら
(メンバの集中力を重視せず、迅速に顧客対応するのがよい)、そうなのだろう。
俺は集中力の方を重視する。

>現在の顧客の多くは、迅速性にコストを支払う価値があると考えている、
>ということを前提にしているのがXPであるから、その価値観を抜きにして
>話しても仕方ない。

したがってメンバが一つの仕事に集中することと、顧客への対応を迅速に
行うことを両立するなら、(ありきたりの考えだが)規模を大きくして人数を
増やすしかない。

もちろん小規模で迅速な対応を実現している会社の努力には敬意を
評するがね。ただ、例えば過去にやったプロジェクトの量や質にも影響
すると思うがね。少数のプロジェクトなら対応は容易だろう。多量の、そして
そこそこの規模のプロジェクトをどれも迅速にというのは難しいと思うよ。

>>274
>>30分で全体の大雑把な構造と重要部分のある程度立ち入った構造が
>>見渡せる規模。数1000行〜1万行ぐらいじゃない。
>
>なるほど。鶏と卵だね。

そうだよ。あまりにも当たり前だから言い訳さえしなかったけどね。
それともキミは適切に説明できるのかい?
くだらん煽りの域をでないコメントだ。

>>>つまり、他の方法では「その程度の規模ですらスムーズに引き継げない」ってこと。
>>これはそんなことないと思うけどね。
>
>242のリンク先が、そう主張しているってこと。
>248で誤読しているようだったので、訂正しただけです。

同じくくだらんね。言葉遊びだ。

276 :XP信者:02/06/20 23:41
>そうだよ。あまりにも当たり前だから言い訳さえしなかったけどね。
>それともキミは適切に説明できるのかい?

なんの言い訳?なんの説明?

>>248で誤読しているようだったので、訂正しただけです。
>同じくくだらんね。言葉遊びだ。

ああ、元々くだらん煽りでしたか。



277 :XP信者:02/06/20 23:48
>もとの文脈は、現在やっているプロジェクトのメンバを一時的に
>借り出してきて、迅速にイレギュラーな対応(例えばWin95で
>開発されたソフトがWin98で動作するかの問い合わせがあれば、
>すぐに確認し答える)をすべきか否かについてだ。

そうなの?
OSのバージョンアップに伴う、ソフトウェアのバージョンアップという
新たな発注に対して、顧客が考える適切な速度で対応できるかって
話かと思ってた。

>したがってメンバが一つの仕事に集中することと、顧客への対応を迅速に
>行うことを両立するなら、(ありきたりの考えだが)規模を大きくして人数を
>増やすしかない。

ここの論理がわかりません。
規模を大きくしたら、なんで両立できるの?
っていうか何の規模を大きくするの?

278 :XP狂信者:02/06/21 00:02
>>275
だから聞いているのは、

OSにセキュリティパッチあてるたんびに、
ユーザが本当にこのパッチ当てても大丈夫のか?
こう聞かれて、きちんとドキュメントの形で
以下の、納入時に行った試験項目と同等の試験を行いパスしました。

こういう報告書を出せるのか?
こう聞いているんだが無理だろ?
保守料貰ってても、コスト的に絶対無理なはずだ。
認めちゃえよ。

XPは出せる。それだけだ。
別に主担当者じゃなくても、報告書が作れる。

OSアップデートして、半日無作為にいじって遊んで、「動くようですよ。」
こういう答えを期待しているわけじゃない。
「品質保証」を求められた時、どう対応するんだ?

ついでに動かなくてもそれは仕方ないのだが、
何日で対処できるんだ?すぐ見積もりでるのか?
XPはその類の見積もりは最速で出すぞ。
しかも、かなり精度高い。
どこにバグがあるかの検出が早いからな。

XPというのは、突き詰めて言えば、開発上流から作られた方法論じゃない。
むしろ保守しながら開発する中でできあがってきたものだ。
だから、保守関係のプロセスはほぼ完璧だ。
ほかのプロセスでそういう味付けのモノはオレは知らない。

保守担当者がほしいのは、ドキュメントではない。安全なんだよ。
XPのプロセスはそれを保証してくれるのがマンセーな所以なのだ。



279 :XP狂信者:02/06/21 00:25
ついで、
今の世の中PCのハードウェア構成、ソフトウェア構成は、
はちゃめちゃに不統一だ。
このような環境で、
「お宅のソフトウェアをおれのマシンで使えるかどうか
すぐに知りたいのだが、どうだ大丈夫か?」

これにちゃんと技術的に答えられるか?
自動化受け入れテストがなけりゃ、こんなもの断言できるシロモノじゃない。

「多分動くと思いますよ。でも、保証の範囲外ですね。」
秋葉原の店員レベルのトークをしなければならないだろ?
何と相性悪いのかもお客さんに教えてもらわなきゃならない始末だ。

だから、XPはすばらしい。XPマンセー。



280 :カイロ:02/06/21 00:27
>>276
ん?あんたのいうことを俺が勘違い
してるのか?鶏と卵を別な言葉で
説明してくれないか?

俺にはあんたが『規模』とは何かって
話を持ち出して話をわやくちゃにしようと
思ってるのかと思ったんだがね。

違うなら謝った上でちゃんとレスするよ。


281 :カイロ:02/06/21 00:37
>>277
新たな発注についてなら計画を立てて
プロジェクトをスケジュールするから、
何も問題は出ないと思うけど?

ウォーターフォールが小回りが効かない、
といってもハードのアップグレードやwindowsの
アップグレードのスピードについていけ
ないほどじゃないと思うが。

ついていけてない製品があるなら、
それは開発形体の問題ではなくて、
会社としてその製品のアップグレードに
どれだけ金をかけるか、って問題だと
思うけどね。



282 :カイロ:02/06/21 00:41
>>277

>規模を大きく

つまらんありきたりの話だけど、メンテ要員や
ユーザーサポート要員を増やす。。。



283 :XP信者:02/06/21 00:42
>してるのか?鶏と卵を別な言葉で 説明してくれないか

いいですよ。

>>242のリンク先では、「他のプロセスでは、こんなに素早く引き継ぎができない」
という主旨の文章を、>>248では「スムーズに引継ぎが出来る規模だから、
スムーズに引き継げたんだ」という主旨の発言をしているように見えました。

そんな当たり前のアンチテーゼを出す以上、元々引継ぎがスムーズに行くか
どうかなんて議論するつもりがなかったんだと解釈して、

>ああ、元々くだらん煽りでしたか。

となってます。

あなたの発言は、煽りとそうでない部分の判別が付き辛いですね。

284 :XP信者:02/06/21 00:46
>新たな発注についてなら計画を立てて
>プロジェクトをスケジュールするから、
>何も問題は出ないと思うけど?

最初の問い合わせで、↓のような対応しかとれなければ、
多分発注はこないと思うよ。

>Windows2000で動いていたソフトをXP対応にするのに、
>動くかどうかの判断さえ、一週間以内に帰ってくることはない。
>
>電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。


285 :カイロ:02/06/21 01:00
>>278
>報告書

可能だよ。もちろんコストはかかるよ。
そのコストを顧客が望むか、どういう形で
望むか(開発費に入れ込むか、保守費
に入れるか、ここに毎回負担するか)は
さまざまだ。テスト環境の構築や維持
の方法もね。テスト用のサーバとかも
必要になるし、自動化できないテストも
ある。(自動化する努力はもちろんすべ
きだから、XPの考えを取り入れるのは
悪くないがね。)

XPはデフォルトでテストツールの作成が
開発費に折込済みであることと、それでも
開発費がそれほど増えないといいたい
のだろう?

その点は特別異論はないかが、テスト内
容(テストコード)の正当性の根拠は何に
基づくのかがに関していまいち説得力の
ある説明が君からは聞けていない。



286 :デフォルトの名無しさん:02/06/21 01:07
>>285は極端なインポ


287 :カイロ:02/06/21 01:20
>>278
>何日で対処

こう聞かれた場合、人のやりくりが一番
ネックだね。XPではネックにならないの?

>>279
>いろいろなハードウェアへの対応

テストの自動化と人海戦術の両輪だね。
なにも自動化はXPの専売特許じゃない。
開発とテストを密接に連動させる点は
ユニークだが。

客先に環境で動作するか否かについては、
ハード構成もさることながら、微妙な
コンフィグレーションの違いにに悩まされるね。

ま、相手先にテスト環境一式を持ち込んで
テストというのもよいかもね。ただ結局人
件費がねぇ。。。






288 :デフォルトの名無しさん:02/06/21 01:21
あー、「XP狂信者」と「XP信者」ってのがいるのか。

「XP信者」と「XP信者」だと勘違いしてて、全角XPと半角XPで
あまりにも文体が違うので、ひとりでモード切り替えでもしてるのかと
思ってたYO!


289 :デフォルトの名無しさん:02/06/21 01:25
スレ違いかもしれんけど、聞いていい?

UnitTest はすばらしいと思うけど、web の UnitTest って
どうやって実現するの? 各ページは HTML による疎な結合を
してるから、テストしにくい。仮に引数渡すレベルのテストは
実現できたとしても、Javascript のテストはどーなるんだろう。

あるいは、操作記録再生ツールでも導入して、テストパターンは
手で入力し、テスト自体はそれを再生したりするの? (そういう
ツールはあるようだが、時間が取れなくて試してないのっす)


290 :カイロ:02/06/21 01:30
>>283
なるほど、悪かった。

聞きたかったのはXPでこの程度の
規模だとこんな引継ぎの形になり、
別の規模だとまた別のこんな形になる、
といった内容。

規模をどう表現するかって点は棚上げしてね。

その発言が単なる煽り区別がつかなかったのであれば、俺の修行が足りないためだ。申し訳ない。

291 :カイロ:02/06/21 01:40
>>284

おれのその発言は
製品として顧客のニーズを見越して
開発することを念頭においたものだ。

顧客からの問い合わせがあって初
めて動き出す場合については(予想
ができないケース)、機動性が重要
だろうね。けどOSやハードのアップ
グレードについてなら、いつなにを
しなきゃならないかの予測は結構
あたると思うけどね。

は割と


292 :カイロ:02/06/21 01:57
>>289
それについていえば、微妙なタイミングとかもね。Submitボタンを押すタイミングとか、
サーバが過負荷な状態での操作とか、なかなか自動化しにくい。シミュレートは
出来るが、そのシミュレートが本当に妥当なのか、不安が残る。だから
今のところこういった部分は自動化ツールも使うけど、最終的には人手に
頼ってる。

XPを使うとうまい自動化の方法があるんでしょうかねぇ。

293 :デフォルトの名無しさん:02/06/21 03:26
>>292
人手だと繰り返しが面倒すぎるので気合をいれて自動化すべきかと。
面倒なテストを人間にやらせると信じられないくらいの確立でサボる、
もしくはミスをします。

で、普通に作ったら自動化が難しくなったりしちゃうんで、
自動化テストを容易になるような設計をしたり(事前の設計ぎみ)、
それ用のツールやらライブラリをそろえたり(YAGNI違反ぎみ)してるんだけど、
それはXP的にどうなんだろう。ダメ?


294 :カイロ:02/06/21 03:57
>>293
>>>292
>人手だと繰り返しが面倒すぎるので気合をいれて自動化すべきかと。
>面倒なテストを人間にやらせると信じられないくらいの確立でサボる、
>もしくはミスをします。

その対策も考える。これを不毛と呼ぶか重要なことと考えるかは、
相手にしているソフトよると思うけどね。

基本的には同じテストを複数人にやらせて、同じ結果になればOK
とする。特異な結果がでれば、テスト内容かテスト対象のプログラムか
テストしている人間のどこかに他と違う要素があるわけだから。

またわざとバグをもぐりこませておいて、それがちゃんとテストでレポート
されるかを確認する。

自動化の努力は言うまでもないのだけど、自動化されたテストが
妥当なものかを検証するために、人間が行ったテストとの相関を
とることが往々にして必要になる。

人間がやったテストと同じ結果がでるなら、その自動化テストは正しい
という考えが必要なことが結構あるからね。



295 :デフォルトの名無しさん:02/06/21 04:46
>>292
XPでもツライと思いますよ。
ビジネスロジック層ならいけるのですがプレゼンテーション層はツライ。
UnitTestの弱点はやっぱりこういうビジュアル的なテストだと思います。
グラフィック&音関係もツライですね。
これも最終的な出力はUnitTestしにくい。
しかし、出来るところはUnitTestをで自動化をしたほうが効率は断然良いと思います。
一番粒度の小さい(メソッド単位)テストですからバグがあった場合はたちどころにその場所が解りますし。

XPのテストで私が一番面白いと思ったのは「テストファースト」の考えですね。
先にテスト(メソッド単位)を書いてそのテストが成功するように実装する。
で、成功したら次のテストを書いてまた実装するって感じで一気に全てのテストを書く場合と違って大変テンポが良いです。
私の経験ですが最後にテストを一気に書くとたいていテスト自体にもバグが混入します。
テスト自体の設計も複雑になりますし書き上げるまでテストできません。
ここら辺はやっぱりXPは優れていると思います。

それからカイロさんの言われているテストも非常に重要だと思います。
実際に目的サービスとして機能しているかのテスト、いわゆる「機能テスト」ですよね。
これは、自動テストは難しいと思います。
XPではこのテストは先ほどのUnitTestと明確に分けていますね。
XPではこのテストの仕様の設計をお客さんにしてもらいます。
お客さんの求めている機能はお客さんが一番知っているという考えですね。
そして、それに合わせてテストを作るまたはテスト計画を立てます。
ここら辺はおそらくカイロさんのおっしゃっているテストとさほど変わりないと思いますよ。
ただ、UnitTestで既にかなりバグは少なくなっているのでバグ取りというよりお客さんの
求めている機能とこちらの解釈した機能が合致しているかの確認作業みたいな色合いの方が濃くなります。

こんな感じですがどうでしょう。
XPは結構実現が環境的に難しいものもありますが(ペアプログラミング、オンサイト顧客など)出来るところだけ使っても
とても役に立つと思います。
今回は書きませんでしたが「UnitTest」は「リファクタリング」をするときにその威力を発揮します。
バグをおそれずに平気でプログラムの根幹を改造できるのもこの二つのおかげです。
この二つだけでも一回実践して見ては。

296 :(ヒ・・・):02/06/21 08:50
>>295
> 今回は書きませんでしたが「UnitTest」は「リファクタリング」をするときにその威力を発揮します。
> バグをおそれずに平気でプログラムの根幹を改造できるのもこの二つのおかげです。
> この二つだけでも一回実践して見ては。

漏れもそう思います。
XP そのものにははっきしいってマンセーになれないけど、
個々のプラクティスの中には、単体でも使えるものがごろごろある気がします。
業務用アプリ作ってて、ころころユーザーの仕様が変わるのに迅速に対応できているのも
「UnitTest」 と 「リファクタリング」 のおかげだと日々実感してます。

297 :デフォルトの名無しさん:02/06/21 11:16
>>296
禿げ同
使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
結局はさじ加減でしかない。カイロとXP狂信者、XP信者の話はもうあきた。

298 :デフォルトの名無しさん:02/06/21 11:58
>使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
>結局はさじ加減でしかない。
おそろしく不同意だが

>カイロとXP狂信者、XP信者の話はもうあきた。
こっちは同意。
UnitTest, リファクタリング周りのコードに関わる話題と
それ以外でスレだか板だかを分けた方が良いのかも。

299 :XP信者:02/06/21 12:07
>使えそうなものはなんでも使う。
使えそうなものが無駄足だったとき痛いから、みんな情報収集して
いるんじゃないの?

>XPとかウォーターフォールとかどうでもいい。
では何故このスレをウォッチしているのかと、小一時間(以下省略)

>結局はさじ加減でしかない。
そのさじ加減を定義しているのがプロセスだと思うんだけど。

>カイロとXP狂信者、XP信者の話はもうあきた。
御意。
では次のネタをどうぞ。


300 :デフォルトの名無しさん:02/06/21 13:29
MSはXPやらんのかね
VS.NETに標準でTestingFrameworkつけて欲しい

301 :デフォルトの名無しさん:02/06/21 14:01
>>300
J Builder だけでなく Delphi / Kylix / C++Builder にも リファクタリング機構が欲しいぞ!ゴルァ!

302 :デフォルトの名無しさん:02/06/21 14:25
J Builder だけでなく emacs / 秀丸 にも リファクタリング機構が欲しいぞ!ゴルァ!

303 :カイロ:02/06/21 16:53
>>297
>使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
>結局はさじ加減でしかない。カイロとXP狂信者、XP信者の話はもうあきた。

恐ろしく無責任な発言だね。何の意味もない。
そのさじ加減が自分で判断できるなら、君はこのスレを読む必要もないし、
そもそもXPの本を読む必要ないんじゃないの?せいぜい本屋で立ち読みぐらいで
用が足りるだろう。

使えそうなものを使うなんてのは君に言われるまでもない。あたりまえじゃないかい?
君は使えなさそうなものを使うのか?

どういうときに何が使えるそうか、何が使えなさそうかを聞いたり言ったりしている
つもりなんだがねぇ。

どこのMLやBBSでもこういう(「使えそうなものを使う」)限りなく無意味な発言する
人がいるもんだね。

304 :デフォルトの名無しさん:02/06/21 17:08
例えば、Web アプリケーションの受け入れテストで

「数字、機種依存文字、日本語、英語、など、文字列を入力しても、異常な動作をしない。」

なんてことになっていたら、どうする?

(HTTPUnit, WebUnit は受け入れテストで便利だと思うけど、これは時間が結構かかる。
時間短縮のテクニックがあれが教えてほしい。)

305 :297 じゃないけど:02/06/21 17:17
>>303
なんか、熱くなってんねぇ。別に >>297 は、「世の中 XP とか騒いで
いるから、良くわかんないけど導入してみるか (と言う上司がいがち
なんだな)」とか言うのは止めて、冷静に自分の所に合いそうな所を
つまみ食いしましょう。ってことだろ。現場としてはまっとうな意見だ
よ。
> どういうときに何が使えるそうか、何が使えなさそうかを聞いたり
> 言ったりしているつもりなんだがねぇ。
まあ別にそう言う議論をすることには反対しないけど、大概「どういう
とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

306 :カイロ:02/06/21 19:51
>>305
>なんか、熱くなってんねぇ。

んーこの程度じゃくだらなすぎて熱くなれないねぇ。

>つまみ食いしましょう。ってことだろ。現場としてはまっとうな意見だ
>よ。

まっとうすぎて何の参考にもならない意見だけどね(笑

>まあ別にそう言う議論をすることには反対しないけど、大概「どういう
>とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

そうだねぇ。無意味な一般論を出して発散させる人が多いからねぇ。
君や297みたいに。


307 :カイロ:02/06/21 20:00
>>305
>まあ別にそう言う議論をすることには反対しないけど、大概「どういう
>とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

この世の中の大半の問題は「きちんと」なんて定義できないもんだよ。
きちんと定義しないままでもやりようはいくらでもある。

というより、きちんと定義できた時は、その問題が解決した(議論する
意味がなくなった)時なんだよ。根本的に君は考え方がなってないね。
君はえせ理想主義者だ。


308 :カイロ:02/06/21 20:58
>>304
結局それをテストコードに直すときに「など」とかの解釈で問題が
起きるよね。こういった「バグ」はXPでは検出できないだろう。

309 :デフォルトの名無しさん:02/06/21 21:04
>この世の中の大半の問題は「きちんと」なんて定義できないもんだよ。

これが無意味な一般論か・・・。

>きちんと定義しないままでもやりようはいくらでもある。

>>305で言ってるのは、大概は、議論をするのに十分な程度も
定義できないってことだろ。

まあアンタはきちんと定義しなくても、発散しないんだろうけどね。


310 :デフォルトの名無しさん:02/06/21 21:07
>結局それをテストコードに直すときに「など」とかの解釈で問題が
>起きるよね。こういった「バグ」はXPでは検出できないだろう。

詳細仕様書→テスト仕様書→テストプログラムの工程を踏めば
検出できるとでも?

結局、それだけの中間生成物をつくる工数を、XPはレビューに
割当てるから、もっと多くのバグを検出するよ。
バグを検出できるよ。

311 :カイロ:02/06/21 21:37
>>309
いやいや君の発言の無意味さに比べれば俺なんか足元にも及ばないよ。

>>310
なんかくだらな過ぎてレスつける気にならないんだけど。
どうしてもレスほしい?

312 :デフォルトの名無しさん:02/06/21 21:52
カイロさん落ち着いてー。あっというまにただの煽り厨に成り下がってるよ。

313 :カイロ:02/06/21 23:09
俺は煽りだよ。(w
過去の発言見てわからんの?

314 :カイロ:02/06/21 23:10
ま、まともな発言にはまともに相手するがね。
君に合わせるとこうなる。

315 :カイロ:02/06/21 23:15
少し整理すれば、XPのテストが強力だというのはあくまでコードレベルの
話であって、システムレベルの信頼性はまったく別の話だということ。

と総括できるかな。

316 :305:02/06/21 23:36
>>314
> ま、まともな発言にはまともに相手するがね。
どもってんの ? クスクス。

まあ、どうでもいいけど。レスの数は有限なんだから、まとめて書けよ。
迷惑だよ。(ま、煽り屋を自認して奴に何言ったって無駄だし、彼に言わせりゃ
「無意味な発言」と言うだけだろうからねぇ。)

317 :デフォルトの名無しさん:02/06/21 23:45
>>315
「システムレベルの信頼性」って?
正しく仕様に沿ってコーディングされているのか、
仕様が正しいのか、
の二つに帰着されると思うけど、
これって人の頭で考えないとどうしようもない部分だろう。

検証方法はこういうのとかあるけど、
http://www.ipsj.or.jp/members/Journal/Jpn/3605/article013.html
形式的仕様化の時点で人間の誤謬が混ざるのは避けられない。

318 :カイロ:02/06/22 00:16
見事に無意味な方向へ展開するねえ。
で、何がいいたいのかねぇ。俺の315を
支持してくれてると受け取っていい?
XPが詠う信頼性は枝葉末節なコードレベルだけってことで。

君の317と何も矛盾してないだろ?(笑


319 :デフォルトの名無しさん:02/06/22 00:18
>俺は煽りだよ。(w
>過去の発言見てわからんの?

もちろん分かってたよ。邪魔だから消えてくれ。

320 :デフォルトの名無しさん:02/06/22 00:24
>>318
じゃあ質問だけ。
「システムレベルの信頼性」って?

321 :カイロ:02/06/22 00:30
つまらん。煽りとしてもマジとしても。
少なくともどっちかで楽しめそうなレスにしてくれ。

322 :デフォルトの名無しさん:02/06/22 00:40
いいから消えろって。

323 :XP信者:02/06/22 00:41
>検証方法はこういうのとかあるけど、
>http://www.ipsj.or.jp/members/Journal/Jpn/3605/article013.html
>形式的仕様化の時点で人間の誤謬が混ざるのは避けられない。

会員じゃないんで見れませんでした。



324 :XP信者:02/06/22 00:51
>>304

Web アプリケーションは、やったことがないんで勘で書きますが、

>(HTTPUnit, WebUnit は受け入れテストで便利だと思うけど、これは時間が結構かかる。
>時間短縮のテクニックがあれが教えてほしい。)

受け入れテストは、ある程度なら(3〜4時間?)時間がかかってもいいんじゃないかな?

受け入れテスト専用のマシンを用意して、毎日自動実行する、って事例があったと
おもうけど、それじゃだめなのかな?


325 :デフォルトの名無しさん:02/06/22 00:58
>>321
あんたのお眼鏡に適わないレスは書けないスレですか?

>>323
別にアブストラクトだけ流し読みしてもらえばいいけど。
ObTS 関連はこの人が論文公開してる。
http://kt-www.jaist.ac.jp/project/ObTS/publications/

326 :カイロ:02/06/22 01:03
>>325
>あんたのお眼鏡に適わないレスは書けないスレですか?

いや、単に俺がレスつけないだけだよ。(w

327 :XP信者:02/06/22 01:23
>>325

精進が足りない所為で難しかった。

仕様記述言語って馴染みがないせいか、どうも無駄なことをやっているように
思えるなあ。

328 :カイロ:02/06/22 01:38
>>325
リンク先を読んでみた。

読んでみるとなかなか面白いね。ペトリネットは素人同然なんだが、
漠然と階層的に記述できるならもう少し実用的になるのかなぁ、と
思っていた。その意味で階層的記述の部分が面白かったんだけど、
うーん、階層的に記述できる*だけ*ではまだいまひとつなのかな、とも
思った。

これが感想。なにぶん素人の感想なんで見当違いだったら許してちょ。

#リンクは非常に面白かったので感謝するが、いまひとつそこからキミが
#何を主張したいのかが、#読み取れないのだが。


329 :デフォルトの名無しさん:02/06/22 01:39
>>327 ごめん、ちょっと割り込ませて
>>325 この5年間程、片山たんヲッチ忘れてますた。貴重なリンクありがとさん

330 :カイロ:02/06/22 01:43
少し実用的になるのかなぁ

実用範囲が広がるのかな

に訂正しとこ。言葉尻をとらえて反応されては叶わんから。

331 :デフォルトの名無しさん:02/06/22 01:56
XPの悪口を言われて脊髄反射したけど、後が続かなかったんじゃ。

332 :カイロ:02/06/22 01:59
不利になると不可知論に持ち込む人間はいやだね。

333 :XP狂信者:02/06/22 03:49
ん?仕様記述言語か。
うーむ、結局あれだ。
How to を記述するのが従来言語。XPが通常使う言語も、この範疇。
Whatを記述するのが仕様記述言語。XPのテストコードが該当する。

UnitTestでやってることって、両方から攻めましょう。
しかも、How to 言語だけで、Whatを記述する仕組みを作りましょう。
こういうことなんだよな。





334 :XP狂信者:02/06/22 03:58
ちなみにテストの正当性?

というより、ひとりのユーザに全権委任している時点で、
XPプロセス内部では、そういう要求満たせないの明らかだろ?
要求するほうがスジ違い。必要なら外でやってくれ。
品質保証が本当に大事なら、ユーザ側でQAチームを作るべし。
その程度で終わる話だ。プロセス監視チームも必要ならどんどんやりな。
コストがかかるだけだろし、どんどんノロクなるだろうけど。

いずれにせよ、テストが足りない部分は迅速なリリースによる、
「エンドユーザの大量導入」による実稼動でそのソフトウェアの
バグは早急に発見される。

そういう意味じゃ、XPはある程度我慢できる品質のものを
早く出すことが大事という文脈を狙ったプロセス。
無謬性要求があったりするならやめとけ。

XPという価値観は、ChangeをKeepすることで、適応しつづけること。
それに意義を見出せない人間には、意味のない世界だ。




335 :XP狂信者:02/06/22 04:01
>>307
いいこと言ってるな。
だから、分析なんていい加減にやっても大丈夫なんだよ(苦笑)。
「違う」ーーーこう言われてから直せばよい。
これがXPスタイル。OK?(笑)。



336 :デフォルトの名無しさん:02/06/22 04:08
>>304
Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので
HTTPを解析してイベントを起こすような作りにしておいて
イベントを直接起こしてテストすることで逃げる場合が多いです。

画面が正しく表示されているかとか、
JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
機能テストとしての役割はだいたい果たすかと。


337 :デフォルトの名無しさん:02/06/22 07:34
受け入れテストに何時間もかけていいもんなのか。頻繁にリリースできないじゃん。

338 :narucy56 ◆wMOjCT4s :02/06/22 08:10
>>336

> Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので

受け入れテストというのは、機能が存在することの証明でもあるから、
これはやらないとうまくない。

特に、リンク切れとか、セッションの保持・開放とか、Web アプリの場合、何かしら
の変更が伴った際に発生する場合が多いから、何かツールを作ってでもやるべき。

(自動的にすべてのリンク辿るスクリプトとか)

339 :XP信者:02/06/22 09:51
>画面が正しく表示されているかとか、
>JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
>機能テストとしての役割はだいたい果たすかと。

UnitTestならそれでもいいですが、受け入れテストではHTTP越しのも
入れないとまずいでしょ。

340 :XP信者:02/06/22 09:59
>受け入れテストに何時間もかけていいもんなのか。頻繁にリリースできないじゃん。

XPでのリリース周期は1ヶ月〜3ヶ月。
しかも、UnitTestとは異なり、常に100%通らなければならないものではない。

1日1回実行可能なら十分な速さだと思うけど。


341 :カイロ:02/06/22 12:53
>>334
>
>要求するほうがスジ違い。必要なら外でやってくれ。
>品質保証が本当に大事なら、ユーザ側でQAチームを作るべし。
>その程度で終わる話だ。プロセス監視チームも必要ならどんどんやりな。

そうそう。結局XPでは無理だからXPの外側でやるんだよね。

XPは「俺たちの責任はこの範囲だから、これ以上の責任はユーザーさんが
もってね」ってことだよね。(間違ってないだろ?w)

>いずれにせよ、テストが足りない部分は迅速なリリースによる、
>「エンドユーザの大量導入」による実稼動でそのソフトウェアの
>バグは早急に発見される。

実稼動でデバッグってことだね。(w


そんなのけしからん、なんて無粋なこといわないけど、その分、開発費は安くして
もらわないとね。半額ぐらいなら、結構割に合うと思うよ。(w


342 :カイロ:02/06/22 12:56
>>335
>いいこと言ってるな。
>だから、分析なんていい加減にやっても大丈夫なんだよ(苦笑)。
>「違う」ーーーこう言われてから直せばよい。
>これがXPスタイル。OK?(笑)。

「違う」という主体は誰なんだい?
そしてその人はなぜ「違う」と分かる?
分析するからだろう?
でなけりゃフィーリングや神秘的な力で分かるんだろうね。

343 :カイロ:02/06/22 13:00
>>336
>Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので
>HTTPを解析してイベントを起こすような作りにしておいて
>イベントを直接起こしてテストすることで逃げる場合が多いです。
>
>画面が正しく表示されているかとか、
>JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
>機能テストとしての役割はだいたい果たすかと。

IEのバージョンの違いとかで微妙に振る舞いが異なる部分も、
テストが難しいよね。

344 :デフォルトの名無しさん:02/06/22 14:02
>そんなのけしからん、なんて無粋なこといわないけど、その分、開発費は安くして
>もらわないとね。半額ぐらいなら、結構割に合うと思うよ。(w

くだらん。

345 :カイロ:02/06/22 14:09
いやいや現実的な話だよ。

>>いずれにせよ、テストが足りない部分は迅速なリリースによる、
>>「エンドユーザの大量導入」による実稼動でそのソフトウェアの
>>バグは早急に発見される。

テストが『いいかげん』な分、顧客はそのコストを負担するんだから、
開発会社に払う金は減らさないとね。


346 :カイロ:02/06/22 14:19
それに年次決算とか滅多に実行されない処理は実稼動で改良なんてのは
無理だと思うけどね。トラブルからの回復テストとか、どれもこれも
人手がかかるテストばかりだよ。

高負荷時のテストも、シミュレートだけじゃ予想外のトラブルが起こる可能性が
あるから、結局実稼動と同じように実際に人手を使ってテストしないとね。
「予想」は外れるからね。(w


347 :XP狂信者:02/06/22 15:31
>>341
でも生産量が倍以上違うからねぇ。
別に同程度以上の値段でOKだと思うよ。
短納期でもすぐ作っちゃうし、特急料金対応なんでね。

そういや半年プロジェクトの話続けるけど、
一人でやるのが正しいわけだけど、
病気したらどうするんだろうね?
XPはこういうところの対応も完璧。

ところで、ちゃんと違約金払う契約にしてる?
してるならいいけど、してないなら
XPと結局は大した差ないでしょ。
いくら手続きが完璧でも、実質が伴ってないってやつ?

結局ねぇ、ソフト会社にそこまでのリスク負わせる話はありえないし、
負わせたところで、つぶれられたら一緒。金は取れないんだから。

にしても、君ってオープンソースも認めてないんだね。
それとも認めてる?
認めてるならXPの狙ってる品質は、オープンソース並だよ。


348 :デフォルトの名無しさん:02/06/22 15:32
>>338
> (自動的にすべてのリンク辿るスクリプトとか)

それができればいいんだけど、POST とか Session とか、
<input type=button onClick="goto_nextpage()"> とか、
難題が多くてねぇ。

>>336
> HTTPを解析してイベントを起こすような作りにしておいて
> イベントを直接起こしてテストすることで逃げる場合が多いです。

できるだけそういうふうにしてるけど、うちは注文画面に
入力して、DB に突っ込むだけみたいな感じなので、Bean と
DB 投入のテストしかできないんだよな。

>>292
> 今のところこういった部分は自動化ツールも使うけど、最終的には人手に
> 頼ってる。
自動化ツールの名前を教えて。それとも、自動化ツールを作るってこと?


349 :デフォルトの名無しさん:02/06/22 15:57
>カイロ

くだらん。
何度同じ話を繰り返せば気が済むんだ。
少しはXP本でも読んでから批判しろって。

350 :デフォルトの名無しさん:02/06/22 16:01
>>349
だから放置しろって。

351 :カイロ:02/06/22 16:18
>>347
>でも生産量が倍以上違うからねぇ。
>別に同程度以上の値段でOKだと思うよ。
>短納期でもすぐ作っちゃうし、特急料金対応なんでね。

んーまあこの辺は内容が違うからなかなか比較しにくいけどね。
顧客側が行うテストなんだか評価なんだかどう呼べばいいのか
分からんが、そういうことにかかるコスト分は、当然予算から
割かれるから、開発会社に回せる金は減ると思うよ。しかも

顧客側にとってはそういうものの専門家ではないのだから、効率が
悪い分、コストはよけいにかかるかと。

ま、業務については専門分野だから有利だろうけど、それは機能の
評価とか取捨選択面であって、安定性や機能障害の評価には無力
だと思うよ。

>そういや半年プロジェクトの話続けるけど、
>一人でやるのが正しいわけだけど、
>病気したらどうするんだろうね?

ん?俺は一人でやるのが正しいとは言ってないよ。念のため言っとくけど。

>XPはこういうところの対応も完璧。

ソースの共有が守られていればだよね。だから前スレとかでその辺がちゃんと
守られているのか、って小一時間問い詰めてたんだけど(w、効率を考えて
ればある程度特定の部分が特定の人に集中するのもやむなし、って意見が
あったと記憶してるけど?

>ところで、ちゃんと違約金払う契約にしてる?
>してるならいいけど、してないなら
>XPと結局は大した差ないでしょ。
>いくら手続きが完璧でも、実質が伴ってないってやつ?

金額に応じて行うよ。請求する立場でも請求される立場でも、
いろいろ考えて。実際そういう話になることもあるね。いやだけど。
ただ、請求する立場で言えば、相手が小規模な会社には、現金は
請求できないね。よほどのことがない限り。(よほどのことってのは
明らかに悪質な場合ぐらいだ。)

相手の会社の打撃が大きすぎるから。ソフトを作ってもらうのが目的
だから、ソフトの代わりに金を取り返してもね。相手が
つぶれちゃったら自業自得なんていってられないし。

>結局ねぇ、ソフト会社にそこまでのリスク負わせる話はありえないし、
>負わせたところで、つぶれられたら一緒。金は取れないんだから。

そのとおりだよ。金は取り返せないけど、ひどいケースでは
なんらかのペナルティは負ってもらうだろうね。信頼できるところに
重要な仕事を回すってのは当然だよね。自分たちも顧客からそう
評価されてるんだから。

>にしても、君ってオープンソースも認めてないんだね。
>それとも認めてる?
>認めてるならXPの狙ってる品質は、オープンソース並だよ。

レベルによるね。今日全く認めないんじゃサーバーすら立ち上げられないジャン。
だからオープンソース並といわれても、ピンからキリまでのどの辺かが重要かと。


352 :カイロ:02/06/22 16:27
>>348
>> 今のところこういった部分は自動化ツールも使うけど、最終的には人手に
>> 頼ってる。
>自動化ツールの名前を教えて。それとも、自動化ツールを作るってこと?

表現が悪かった。君が望むようなツールは持っていない。ようするに
人手主体だよ。

人手でテストしてみて、特定の操作部分が高負荷に弱いとか割り出せれば、
その時個別に特定の操作を繰り返すようなツールを作ってさらに負荷をかけた
テストをすることはある。

>>349
>>カイロ
>
>くだらん。
>何度同じ話を繰り返せば気が済むんだ。
>少しはXP本でも読んでから批判しろって。

キミは教科書の丸暗記的な反論しかできないのだろう?(w

353 :カイロ:02/06/22 16:37
>>347
>XPと結局は大した差ないでしょ。

だから俺はXPでも従来型でも信頼性も効率も、大差ないって言ってるんだけど(w
顧客から見ればトータルのコストは減らない。開発会社の負担は減るだろう。
だからその分、開発会社に払う金は安くなるだろう、ってことだよ。

何もXPの利点をすべて否定するわけじゃないよ。高い金もらって不毛な
仕事をするより、相応の金をもらって楽しくやる、ってのはいかにも開発者
好みだと思うけどね。そりゃ金は欲しいだろうけど(w

354 :デフォルトの名無しさん:02/06/22 17:32
>キミは教科書の丸暗記的な反論しかできないのだろう?(w

教科書も読まずに反論するやつにはそれで十分だろ?(w

355 :デフォルトの名無しさん:02/06/22 23:38
他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう?


356 :デフォルトの名無しさん:02/06/22 23:41
名前

単に言い換えただけだし

357 :デフォルトの名無しさん:02/06/22 23:44
構造化技法で新しいことはなんでしょう?
OOPで新しいことはなんでしょう?
AOP新しいことはなんでしょう?

358 :デフォルトの名無しさん:02/06/22 23:45
XPに新規性がないことが分っただけで十分です

さようなら

359 :カイロ:02/06/23 00:17
>>355
ずばり形式的手法の否定では?(w
言い換えれば、メタ形式化だね。

360 :カイロ:02/06/23 00:25
その意味ではCMMレベル5もいわばメタ形式化だからXPと同じだ。
と言ってみるテスト。(w

361 :カイロ:02/06/23 00:39
>>354
相手して欲しければ、中身のあること書きな。笑

362 :デフォルトの名無しさん:02/06/23 00:52
>相手して欲しければ、

相手してるじゃん(w

363 :355:02/06/23 00:56
>>359
ごめん。メタ形式化が良く分からない。
形式的手法の否定だと、ほとんどの方法論は開発プロセスに形式的手法を採り入れていないが、
否定というのは採り入れていないという意味ではないの?


364 :カイロ:02/06/23 01:22
げ、マジレスがきた。悪い。言葉遊びだったんだ。すまん。申し訳ない。

>他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう?

焦点を当てているのが生成物(プロダクツ)でも生成方法(プロセス)でもなく、
生成者(開発者)という点では。

---そこそこマジレス。

365 :デフォルトの名無しさん:02/06/23 01:31
bye

366 :デフォルトの名無しさん:02/06/23 02:37
XP信者って厨房ばっかだなー

367 :デフォルトの名無しさん:02/06/23 03:03
そろそろブームも下火だね。

368 :カイロ:02/06/23 03:43
厨房にウケがいいのは事実だろうね。

369 :デフォルトの名無しさん:02/06/23 05:39
>>355-359
355はテスト技法、方法論、形式的手法をひとくくりにしてる段階で何も分かってないと思われ。

370 :HAMAIタンうぉっち:02/06/23 08:46
こいつ何が言いたいんだ?

「修正も変更の一種です。」にはワラタ

------------------------------
>
>> 欠陥が多いとXPのように変更を繰り返す
>> と欠陥が欠陥を生んで収拾がつかなくなるおそれがあります。
>
>それを回避するためのテストでは?

はい。ですから、収拾がつかなくなることを防ぐため、欠陥をある程度
以下に押さえ込んでおけるようにテストするわけです。XPにおけるユニット
テストは、欠陥を虱潰しに捜して積極的に欠陥を減らすようなものでは、
通常ありません。


>欠陥が欠陥を生むのはむしろ
>
>> 信頼性を高めるためには、可能な限りソフトウェアを変更しないように
>> すべきであり
>
>という従来の考え方だと思います。

ソフトウェアを変更しなければ欠陥は増えません(減りもしませんけど)。

従来の考え方は、ソフトウェアを変更しないようにするために、仕様変更や
リファクタリングをせずにすむようなソフトウェアを開発するということ
であって、仕様変更やリファクタリングがさけられないソフトウェアを
開発しておいて仕様変更やリファクタリングをしないということでは
ありません。

しかし、仕様変更やリファクタリングをせずにすむようなソフトウェアの
ソフトウェアの開発は不可能と言ってもいいほど困難ですし、コストも
多大になります。ですから、変更を減らすのではなく、変更によって欠陥を
作り込む確率を減らすという考え方をXPなどは取り入れたのです。

>変更しないことで信頼性を高めるという主張は、変更前のコードの信頼性が十分
>高いことを前提としています。ところがソフトウェア開発においてはある時点で
>の信頼性の高さはあまり意味がありません。顧客の要求により突然仕様が変更さ
>れれば、変更前の仕様を前提とした信頼性の高さは無意味です。

そんなことはありません。欠陥の多い、わかりにくいソフトウェアの仕様を
変更するくらいなら、最初から作り直した方がましとはよく言われることです。

>                             従来の考え方で
>は、仕様変更によって意味を失ったコードを無理矢理延命させるために場当たり
>的な修正を加え、その結果として潜在的欠陥が累積されるというパターンが度々
>見られます。

修正も変更の一種です。変更しているのだから欠陥がふえても不思議では
ありません。


片岡さんが批判しているのは、従来の信頼性を重視したソフトウェア開発手法
ではなく、従来の信頼性を*軽視*したソフトウェア開発手法のように
見えます。


371 :デフォルトの名無しさん:02/06/23 09:12
全体的に支離滅裂だけれど、特にこの辺が激しいね。

>>変更しないことで信頼性を高めるという主張は、変更前のコードの信頼性が十分
>>高いことを前提としています。ところがソフトウェア開発においてはある時点で
>>の信頼性の高さはあまり意味がありません。顧客の要求により突然仕様が変更さ
>>れれば、変更前の仕様を前提とした信頼性の高さは無意味です。
>
>そんなことはありません。欠陥の多い、わかりにくいソフトウェアの仕様を
>変更するくらいなら、最初から作り直した方がましとはよく言われることです。

作り直すなら尚のこと変更前の信頼性の高さは無意味だから、反論にさえなってない。
すごく分かりやすい『議論のための議論』の例だ。



372 :デフォルトの名無しさん:02/06/23 14:12
>他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう?

こういう質問に譬え話で答えて見るテスト。

かつてOOが登場した時、開発者達は笑って言ったものでした。
「俺はソース単位でグローバル変数を管理してカプセル化していたよ。」
「俺はポインタを使って処理を振り分けていた。これはまさに多態性じゃないか。」
「俺だって継承を取り入れたプログラミングをしていたぞ。」
「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」

そしてXPと呼ばれる開発手法が登場した時、開発者達は笑って言っています。
「俺は昔からテストコードを書いていたよ。」
「俺は後輩と組になってコードの保守をしていた。これはまさにペアプロじゃないか。」
「俺だってユーザにプロトタイプを提供して意見を聞いていたぞ。」
「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」


373 :つづき:02/06/23 14:17
幸せそうな開発者達はさておいて、逆にみなさんに質問してみましょう。

みなさんは昔から、デフォルトでOOを実践していましたか?
開発途上で結果的にOO的な状況になっていたことを思い出して、それを本当のOO開発と混同していませんか?

みなさんは昔から、デフォルトでXPを実践していましたか?
開発途上で結果的にXP的な状況になっていたことを思い出して、それを本当のXP開発と混同していませんか?





374 :355:02/06/23 15:24
ごめんよ。書き方まずった。XPを否定しているわけじゃないんだ。
次の点を簡潔に知りたいんだ。

他の手法と差別化して主張しているのはどこか?

どういう技法などを改良して採り入れたのか?


375 :カイロ:02/06/23 15:55
>>372-373

>「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」

と思うのはさすがにアホだけれど、、

>開発途上で結果的にOO的な状況になっていたことを思い出して、それを本当のOO開発と混同していませんか?

「結果的にOO的な状況になる」と「本当のOO開発」はどの程度違うのかね。
延長にはあるし、個々にOOを再発見しなくてよいってだけって気もする。

しかし、鶴亀算や旅人算を駆使して問題を解くのと一次方程式を立てて解くのだと、
結果的に同じことをやっているにもかかわらず、後者はずっと整理され一般化されているから、
前者の延長ではたどり着けないような領域にまで展開可能だ。

結局ばかばかしいかばかばかしくないかは、従来と同じ土俵で比較していては、
判断できないってことだと思うけどね。従来の方法では扱いきれないものを
どれくらいうまく扱えるかって点に尽きる。


376 :デフォルトの名無しさん:02/06/23 15:57
>>374
Pert1から順に過去ログ読むのをお勧めする。
たぶん休日使って読むくらいの価値はアル。

377 :カイロ:02/06/23 15:58
>>374

> 次の点を簡潔に知りたいんだ。

従来の方法論はそこそこ知ってるようだけど、キミはそれらの「次の点」を
簡潔に説明できるわけ?見本を見せてくれれば、それにそって説明できるかもね。


378 :XP信者:02/06/23 16:03
>他の手法と差別化して主張しているのはどこか?

それはやっぱりテスティングとリファクタリングでしょう。
ここまで極端に、この2つを取り入れている手法を他には無いでしょう。

>どういう技法などを改良して採り入れたのか?

これはXPのプラクティスが全部そうでしょう。
逆にいえば、その他の事柄は、(プラクティスほどは)重要視していない、
というところが特徴です。

よく誤解されているのではないかと思うんですが、XPでのドキュメント不要論は
「ドキュメントを書かない」というプラクティスがあるわけではないので、重要視さ
れているわけではないのです。

ただ、「変化ヲ抱擁スル」こととXPのプラクティスを実践することによって、
ドキュメントを作成/メンテナンスすることが非常に難しくなってしまうだけ
なのです。

例えば、たった一つの機能を追加するのに、10ものドキュメントを修正しなけれ
ばならないとすると、手を出しかねてしまいますし、物理的に短期リリースも
不可能となってしまうでしょう。

だから、コミュニケーションに役に立ち、自立テストによって正当性を検証でき、
追加/修正が容易なドキュメント作成/維持方法があれば、XP的にドキュメント
を不要と考える理由はなにも無いはずです。

そして、XPではソースコード/テストコードをドキュメントと同一視することで
それを実現しているのです。


379 :カイロ:02/06/23 16:17
>>370-371
「従来の信頼性を*軽視*したソフトウェア開発手法」なんてものがあるのかねぇ。
どれもこれも、手法としては、うんざりするくらい重視してると思うけどね。

「従来の信頼性を重視したソフトウェア開発手法」とは何を念頭において言ってるのか
聞いてみたいね。(w

いくら手法が立派でも、それにそって実際に運用しきれなきゃね。

そこから運用できるレベルまで手法の方を軽量化しましょう、って考えるか、
運用できるように組織を充実させましょう、ちゃんと運用されているかどうか
チェックする組織も作りましょう、って考えるか、だね。


380 :デフォルトの名無しさん:02/06/23 16:50
> そこから運用できるレベルまで手法の方を軽量化しましょう、って考えるか、
> 運用できるように組織を充実させましょう、ちゃんと運用されているかどうか
> チェックする組織も作りましょう、って考えるか

まんまCMMやね

381 :カイロ:02/06/23 17:03
チェックしてもしちゃんと運用されていなければ、組織自体も改良していきましょう、
ってのがCMM5かな。(w

382 :デフォルトの名無しさん:02/06/23 17:37
>>379
開発手法の運用を語る人にしては、文章がちょっと支離滅裂ぎみだと思う。
レス番も違うみたいだし。

383 :カイロ:02/06/23 18:29
>>382
>レス番号も違うみたいだし



384 :カイロ@モバイル:02/06/23 18:34
>>382
現実は支離滅裂なもんだよ。
ご本だけ読んでてもね。
>ぼくちゃん。

385 :カイロ:02/06/23 18:51
>>282
ところでさぁ、part1の頃から思ってたんだけど、
いつも少し前レスの煽り文句をそのまま真似て
つかってる人がいるなぁと思ってるんだけど、
みんな君なのかな?(w
いや、悪くはないんだけどね。何事も猿真似から始まるんだからね。

残念だけど君がチットモ意味あることを書いてくれないから、
俺もこんなレスしかつけてあげられないんだ。
ごめんよ。

386 :カイロ:02/06/23 19:31
すみません。
そうなんです。

ばれました?

387 :XP狂信者:02/06/23 21:11
>>378
だね。そういう意味では、
javadocやdoxygenによる自動生成ドキュメントはXPでは、
多少の負荷にしかならないから、この程度はやるんだよね。

ついでに、自動生成テストケース結果レポート作成が今はブームで、
これのやり方がある程度、普及すれば、顧客納品ドキュメントの体裁
ぐらいは整えられる。



388 :カイロ:02/06/23 22:08
>>386
君は誰やねん(w

389 :デフォルトの名無しさん:02/06/24 01:38
おい、カイロに絡んでる厨、ウゼエ
お前がこのスレを荒らしてんだぞ。うせろ!

390 :デフォルトの名無しさん:02/06/24 03:25
>>385
ワラタ
もしかしてHAMIかもな。

391 :デフォルトの名無しさん:02/06/27 14:42
なんでUnitTestってテストされるクラスとは別にテストするクラスを作るの?
テストされるクラス自体にテストメソッドをつくり自己テストにしたほうが
Private変数のテストも出来るし、いいような気がするんだけど。

392 :デフォルトの名無しさん:02/06/27 15:41
>>391
リリースビルド時に簡単にテストメソッドだけ削除できることと
元の継承ツリーとは別にTestCaseクラスを継承できれば
(つまり多重継承できる)それでもいいけど
両方可能な言語はそれほど多くない。

393 :デフォルトの名無しさん:02/06/29 15:30
>>391

自己テストはリファクタリングの妨げになりやすいのでXP的には却下なのれす。
実装をテストするのではなくインターフェイスをテストするのれす。

394 :デフォルトの名無しさん:02/06/30 17:31
やってみなきゃわからないでしょう?
やる前からあーだこーだ言ってると、
それ以上進まないですよね?
ただ僕はXPを知ってほしい。
僕はね。XPで本当に幸せになれたんです。
昔は、僕もあなたと同じ考えでした。
でもまぁ僕の話なんだけども、ウォーターフォールで仕様変更に悩まされてて、
先生にXPを信じてやってみなさいって言われたんです。
で、それから一生懸命ね。XPを勉強して
信心したらね。スット頭の中が整理されて、バグもなくなったんです。
なんでもっと早くXPを習わなかったのかなぁと今は思ってます。
なんで僕がね。こんなことを言うかと言うと、
あなたに幸せになって欲しいからなんです。
だから一度、XPの集会がや日曜にやってますんで、
一度でいいですから来てみてください。
そしたらXPについて今の誤ったイメージが間違っていたと
思うようになると思います。もしXPがやっぱりだめだと
思ったらそれは構いせん。それは自由です。
でも幸せになれないでしょう。一度集会に顔出してみてください。

395 :デフォルトの名無しさん:02/06/30 22:09
>>394

出すタイミングが1週間は遅いね。

396 :デフォルトの名無しさん:02/07/01 03:25
どこを立て読みするんですか?

397 :デフォルトの名無しさん:02/07/01 20:44
>>394
駅前とかで勧誘するといいんじゃない?


398 :393:02/07/02 00:45
ごめん。
394は俺が書きました。
っていうか、戦場OOスレからコピペ&置換しただけなんだけど、なんで皆そんなに
余裕の無いレスばっかりなの?

だからカイロなんかになめられる。
と言ってみるテスト。

399 :デフォルトの名無しさん :02/07/02 01:44
>>398
出来がよすぎるんだよ。しゃれになってない。

400 :デフォルトの名無しさん:02/07/02 09:16
>>398

いや、そのネタはもう飽きたから。

401 :デフォルトの名無しさん:02/07/03 00:49
>>400

余裕の無いレスの典型だな(w

402 :HAMAIタンうぉっち:02/07/10 07:38
相変わらず何も根拠を挙げないただの独りよがりの意見だね。
---------------------
XPは、ソフトウェア開発の目的をまがりなりにも意識していますが、
CMMはほとんど意識していません。目的を意識せずに戦略は立てられません。
そういう意味で、XPの方がまだしも戦略的です。

戦略と戦術とでは、戦略の方が優先します。もし、XPとCMMとが対立したら、
XPを優先させるべきだというのが、私の考えです。


403 :HAMAIタンうぉっち:02/07/10 07:40
あーうっとうしい。
これだけ長い文章で意味のあることを何も書かないってのは特技かもしれない。
-----------------------------
目的は「提供」であって「開発」ではない。このことは、「開発」の効率
向上が必ずしも「提供」という目的の達成に貢献しないことを示しています。
それどころか、「開発」の効率向上は「提供」という目的の達成の障害
となるおそれすらあります。

このことは意外かもしれませんが、理解しづらいことではありません。
例えば、フルマラソンにおけるゴールタイムと10kmまでの区間タイムを
考えてみましょう。区間タイムが速ければ速いほどゴールタイムも速くなる
でしょうか。もちろん、そんなことはありません。区間タイムの向上は他の
区間のタイムの低下につながり、ある程度以上区間タイムを向上させれば
全体としてのタイムの低下につながります。スタミナは有限なので適切な
配分が重要なのです。

企業における、ヒト、モノ、カネといったリソースも有限です。
ある部分にリソースを投入するということは、他の部分に投入できたはずの
リソースを奪うことでもあります。開発のために、開発の効率向上のために
リソースを投入するということは、他のもっとリソースを投入すべきだった
かもしれない箇所からリソースを奪うことでもあるのです。
部分的な効率向上は、全体的な効率の低下につながる危険性が多分にある
のです。

細かいことを二つほど言うと。
「最終的」ということは、中間的な目的とかもあるのでしょうか。
ソフトウェア開発において、重要度の高い目的、重要度の低い目的、
長期的な目的、短期的な目的というような区別はできても、最終的な
目的、中間的な目的というような区別は無いと思います。

「お客様が提示した要求への回答(ソリューション)を提供する」
には、「満足」と「価格」の二つの条件が抜けています。
これらを無視できるなら目的の達成は誰でもできることでしょう。


>CMMの場合、経営側の責任(契約や要件定義、品質管理など)に重
>点を置いているため、XPよりも経営側の視点に近い気がします。
>そういった意味では、CMMの方が戦略的かもしれません。

トップが下す判断が常に戦略的とは限りません。旧日本軍など典型的な例
でしょう。戦略的に考えることは難しく、特に日本人は苦手のようです。
戦略的ではなく、戦術的に考えているケースは多いです。


404 :HAMAIタンうぉっち:02/07/10 07:43
これも何を言ってるんだか。
質問者はこの程度の答えを期待していると思っているんだか。
--------------------------------------
>・ドキュメントについて
> XPの基本方針としてドキュメント作成等の上流工程より、「テスト」を中心と
> した開発という事が謳われています。確かに開発時はこれで効率が良いとは思
> いますが、リリース後の保守において、ソースしか見るものがないというのは
> 、保守担当者にとっても大変効率の悪いものとなりがちです。XPでのドキュメ
> ントの重要度はどう考えられているのでしょうか。

XPでは、製品としてのドキュメントまでは否定していないです。

 
>・オンサイト顧客について
> プログラマからの質問にその場で答えると定義されていますが、質問内容を文
> 書として残さなければ、あとで「言った、言わない」の押し問答にならないの
> でしょうか(更にその場での回答が必ずしも適切な回答とはならない事も多々
> あると思う)

食い違いが生じたら、次のイテレーションで修正すればいいことでは。
誰の責任とか、不毛な議論をするよりさっさと修正する方がXP的でしょう。

「変化ヲ抱擁セヨ」の「変化」には、ミスの修正による「変化」も入っている
と思っています。


405 :HAMAIタンうぉっち:02/07/10 07:45
人口無能?
---------------------------
>気持ちはXP on CMM

私は、CMM on XP というところでしょうか。
# で、のらない部分は切り捨てる。

>そして、XPは戦略的かどうかも問題でなく
>XPを戦術と位置づけることで
>「戦略は経営陣に従うが戦術は現場に委譲すべきだ」。
>と議論を展開で、導入しやすいだろうなと思っただけです。

XPが戦略的だとは思っていません。CMMはより戦略的でないと
思っているだけです。


>現場が戦略論を打ち上げたら経営陣は拒絶を示しませんか。

トップが誤った戦略を打ち出したら現場は反対せざるを得ません。


406 :デフォルトの名無しさん:02/07/10 08:20
このスレ、無能ばっかりだ…

407 :デフォルトの名無しさん:02/07/10 08:22
面白くない。

408 :デフォルトの名無しさん:02/07/10 08:26
無能?苦悩?久能?

409 :デフォルトの名無しさん:02/07/10 08:46
>>406
オマエモナー

410 : :02/07/11 10:57
>>406
HAMAIタンいらっしゃい

411 :デフォルトの名無しさん:02/07/11 21:37
カイロうざい

412 :HAMAIタンうぉっち :02/07/12 10:17
この人はCMMをわかってないな。
CMMレヴェル5のどこが「あるきまったプロセス」なんだ?
-----------------------------------------
>> > XPは、ソフトウェア開発の目的をまがりなりにも意識していますが、
>> > CMMはほとんど意識していません。目的を意識せずに戦略は立てられません。
>> > そういう意味で、XPの方がまだしも戦略的です。
>> >
>> > 戦略と戦術とでは、戦略の方が優先します。もし、XPとCMMとが対立したら、
>> > XPを優先させるべきだというのが、私の考えです。
>>
>> 「開発の目的」とはなにか?が重要になると思います。
>> CMMでもXPでも、最終的には「お客様が提示した要求への回答
>> (ソリューション)を提供する」ことが目的だと思いますが、いかが
>> でしょうか?当然、同時に自社も儲けるのが前提になりますが。
>
>CMM と XP では観点が違うような気がします。CMM は組織として
>のソフトウェア開発力の成熟度を見ているし、XP は個々の具体
>的なソフトウェア開発のプロセスをどう最適な物にするかだと
>思います。そう言う意味では CMM の方が XP よりはより大局的
>だとは思います。戦略と戦術ですが、これは対象となる目的の規
>模によるでしょうね。

目的を達成しやすいように条件を整えるのが戦略です。
ソフトウェア開発の目的は端的に言えば、「顧客の満足する製品やサービスを
顧客と提供側双方にとって妥当な価格で提供する」といったところでしょう。

開発は提供するための複数ある手段のさらにその一部にすぎません。開発
という手段に固執しているCMMは、大局的でも戦略的でも無いです。
XPも開発に固執している点は同じですが、顧客の要求を中心にすえている
という点でCMMよりははるかにましです。[XP-jp:03278]で述べられている
ような顧客の要求を断ることは、コストや納期に無理がある、法律や倫理に
反している、というような場合以外、行うべきではありません。CMMの成熟度
レベルを維持するために顧客の要求を断るということがCMMの矛盾を
示しています。


>#実際にインドの CMM レベル5企業の組み込みソフトの品質は
>#CMM レベル2相当の日本の企業の組み込みソフトに比べて実は
>#低かったと言う報告を見た記憶がありますし。・・・

ワインバーグは、レベルの違いではなく文化の違いに過ぎず優劣ではない、
と言っていたはずです。

開発物に対する要求だけでなく、開発プロセスに対する要求もプロジェクト
ごとに異なります。それどころか、プロジェクトの期間中にさえ変化します。
あるきまったプロセスでのりきろうとするCMMの考え方に無理があります。
スポーツなら、試合開始直後、終盤勝っている時、終盤負けている時、各々
別のやり方で戦うはずです。


413 :幼稚園児:02/07/14 18:41
なんかXPってよくわかりません。幼稚園児でも理解できるように説明してください。


414 :デフォルトの名無しさん:02/07/14 19:18
>>413
俺は幼稚園児じゃないので幼稚園児が理解できるかどうか知りません。

415 :デフォルトの名無しさん:02/07/14 23:04
>>414

ソフトウェア=泥だんご
のメタファで何とかならないか?

416 :デフォルトの名無しさん:02/07/15 02:09
最初から大きくて割れない泥だんごを目指すんではなくて、
小さな泥だんごを作ってみて、落として割れなかったらもう少し泥を付け足す。
付け足したらまた落として割れないことを確認する。
だんだんひび割れなどが見えてくるので、そこには水をかけてならしたりする。

417 :HAMAIタンうぉっち :02/07/16 00:27
無意味なレスつけるのが趣味なんだろうな。
きっとそうだよ。それ以外ないよね。
ーーーーーーーーーーーーーーーーーー
濱井です。引用の順番を入れ替えています。
2002/07/09 20:57:21 +0900にt-honma@pp.iij4u.or.jpさんが送られた
メールに関する返信です。

>> >CMMの場合、経営側の責任(契約や要件定義、品質管理など)に重
>> >点を置いているため、XPよりも経営側の視点に近い気がします。
>> >そういった意味では、CMMの方が戦略的かもしれません。
>>
>> トップが下す判断が常に戦略的とは限りません。旧日本軍など典型的な例
>> でしょう。戦略的に考えることは難しく、特に日本人は苦手のようです。
>> 戦略的ではなく、戦術的に考えているケースは多いです。
>
>そこが問題ですよね。
>XPを導入すれば、この辺も改善されていくのでしょうか?

ある程度の改善は期待してもいいと思います。ただ、XPが特効薬になるとは
考えない方がいいでしょう。「銀の弾丸」はまだ見つかっていません。


>> 「お客様が提示した要求への回答(ソリューション)を提供する」
>> には、「満足」と「価格」の二つの条件が抜けています。
>> これらを無視できるなら目的の達成は誰でもできることでしょう。
>
>顧客満足、価格、納期などは、すべて提供する「回答」に含まれる
>ものだと思ってます。これらを無視するつもりはありません。
># というより、無視できないでしょう。実際。

要求内容と回答内容が1対1に決まるようなものではないので、「回答」
だけでは、意図が読みとれません。

人は、他人の書いた文章をそう注意深くは読んでいないものです。
ましてや、記述者の意図通りに読みとってくれるとは思わない方がいいです。



418 :デフォルトの名無しさん:02/07/16 15:21
うちもXPだなんだってやってるが、XPチームとかでやってるやつらは2期連続デスマーチ・大赤字だ。
どんどん人員を増加しているしな。他のプロジェクト潰してでもだ。おかげでボーナスも遅れてる。
俺はXPなんでどうでもいいから詳しくは知らないが、
うちのバカどもが学習できないのか、XPが完璧な人間の集まりでしかできないのかよくわからん。
こういう会社はXPやめたほうがいいですか?
おまけにJava以外の開発やりたくねーってよ!カス共め。

419 :デフォルトの名無しさん:02/07/16 19:34
人のレベルを上げるか仕事のレベルを落とせ。

つーか、ぜひ詳細レポートきぼんぬ。
今の時点で人数ってどれくらいなの?
XPでなけりゃうまくいきそうだった?

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

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)