eXtreme Programming Part.3

前すれ
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/

乙ｶﾚｰ

ハヤシもあるでよ

エキセントリックプログラミングのｽﾚはここですか？

WindowsXPのスレはここですか？

前スレで振っといた話題、客の要求を迅速に整理する方法。語らせてね。

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

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

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

※小さな例
[IF 情報を整理したい。(追加した問題)]
↓
[THEN 名前変更機能が欲しい。]
[THEN ネームスペース機能が欲しい。]

>>4
ここはエクスクルーシブプログラミングのスレです。

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

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

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

ホワイトボードだと漢字が書けないのがばれてしまう罠。

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

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

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

(省AA強化月間）

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


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

これを無限後退といいます。
いいですね？
はーい、先生。

(省AA強化月間）

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

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

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

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


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

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

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

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

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

やつが会社でどれだけうざがられてるか想像できる。
多分会社で会話する相手もいないんじゃないかな。

はーい、はまいたんウォッチャー御一行様、こちらですよー。

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

いわゆる宇宙人はいるって立証したやつと、
宇宙人はいないとは言い切れないとかいってるやつの違いだな。

＞＞１５
それほど大物じゃないよ。

前スレのこれってほとんどXP否定じゃないの？

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

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

だからXPは共産主義と同じで滅びる運命なんだよ。

>>18
従来よりも大規模なプロジェクトに適応した変化でしょ。
バリエーションでいいんじゃないかなあ。

つーか従来だと適応できるプロジェクトはゼロに近いと思われ。

XPはけんとべっくタンがウォーターフォールを学習する日記でした。

単一のユーザではなく、ユーザというインターフェイスを
満たした何かと考えるべきなのかな？
あんなの個人で満たすのむりだよね。

XP早くも自滅の予感

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

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

>>23
いや、無理じゃないよ。
だからシステムとしていくつも作られてきているわけだ。

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

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

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

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

こんな調子。

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

古いたとえなんで嫌いだけど、そのぐらいの構成で、
大体、３万ステップから１２万ステップを半年から１年で
最高品質で最高に有効なソフトウェアを作るためのプロセス
それがＸＰってことでＯＫ？

>（省略されました・・全てを読むにはここを押してください）

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

http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.html

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

ではー（＾＾）

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

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

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

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

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

ＳＥに執着しているねぇ（苦笑）。
ＸＰのユーザはプロダクションマネージャだよ。
まぎれもなくね。
それをＳＥの亜種だというならそうだろう。

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

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

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

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

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

すまん
プロダクションマネージャじゃないね。
プロダクトマネージャだ（苦笑）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづき

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

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

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

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

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

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

２０万行が小規模というのならね（苦笑）。
君の大規模って何？
終わらないプロジェクトのこと？

>>37

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

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

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

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

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

>>39
> 結局、育たないのは、育てないからだと思う。
禿胴！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

おらおら、ＳＥ／ＰＧネタやったらここでやったれ
http://www20.big.or.jp/~o-shin/bbs/common/complain/bbs.cgi

>>38
>２０万行が小規模というのならね（苦笑）。
>君の大規模って何？
>終わらないプロジェクトのこと？

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

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

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

XPはあくまでも少人数でうまくまわる手法だと思う。
そして開発できる規模は、その少人数のメンバー合計の力量次第かなと。

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

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

>>39
>
> 仕様書をSEに押し付けられるだけの開発側メンバが
> クライアントの愚痴を聞くチャンスが増えるというのに？

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

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

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

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

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

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

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

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

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

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

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

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

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

>>41

>>43
>そして開発できる規模は、その少人数のメンバー合計の力量次第かなと。
ここだけど、ウォーターフォールではこれが単純な合計ではなく、すこし低くなるよね。

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

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

＞XPは仕様を随時細分化してどんどん詰め込んでスケジュールしてゆくのに対し、

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

>>48
そのかわり残業なし。これ。

>>44
>俺がいってるのは要求仕様をまとめ上げる能力だよ。
>これをお客にやってもらうわけだろ。

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

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

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

>>50
>
> なんだか激しく誤解されているようだ。

失礼した。

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

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

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

ツーか、多対多の構成にした時点で負けだろ（苦笑）。
いまだにどうしてそんな構成になるのか首を傾げているよ。

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

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

>>47
少しじゃない、めちゃくちゃ少なくなる。
ケーススタディをしよう。

カイロはウォーターフローで行けるといったプロジェクトの例だ。
期間は半年。５＊６＝３０人月の予算規模だとしよう。
どういう工程配分にするね？
ＬＯＣどの程度のソフトウェアを開発できる？
ちと、ウォーターフローのプロの方概算してくれよ。

>>6から9
ありがとね。
ザゴールのインタビュー技術に通じるものがあって素敵だよ。

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

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

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

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

>>52
>ツーか、多対多の構成にした時点で負けだろ（苦笑）。
>いまだにどうしてそんな構成になるのか首を傾げているよ。

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

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

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

とか

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

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

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

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

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

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

かみあわないのは当然だが？
ＸＰ開発者は無理なことはしないんだ。
人生ヒマじゃないからね。

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

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

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

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

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

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

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

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



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

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

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

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

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

ケントが言ってたように、単一のユーザというイメージは無理があると思う。

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

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

>>57
>こういった変化は抱擁しないってことでいい？

全然よくねーよ（ｗ

>>58
>ケントが言ってたように、単一のユーザというイメージは無理があると思う。

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

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

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

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

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

開発なんてすべて泥臭いもんだよ。XPはその泥臭さが身上ではないの？（ｗ

>>59
よくねーなら、何とか抱擁しろ。さあ、その場面に直面した場合、まずどうする？

>>61

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

>>62
＞まずも何も、「ワークフローの変更」ってストーリーを一つ定義するだけだろ。

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

>>60
ビジネスチーム（ユーザ）の代表が何人かと、開発チーム全員じゃないかな。>　計画ゲーム
あまり効率が悪いとは思わなかった。

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

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

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

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

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

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

＞普通ありえない話を無理やり作ってるよな。

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

参考までに聞きたいんだけど、キミがいままでプロジェクトで苦労したところってどんなとこ？

66=67=俺ね。

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

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

ＸＰは、タスク（要件）を提示してくれるならば、
正確な見積もりとシンプルな設計実装をすばやく提供しますよ
といった方法論なんじゃないか？

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

そんなことはない。残念ながらね（苦笑）。
ウォーターフォールがなんとか回るのは余裕がある場合だけだ。
カツカツになってる仕事ばかりなので、ヒーコラいう話ばっかりさ。

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

１／３が分析でしょ。
半分はテストなはずなんだけどあってる？

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

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

>>69
すみません。

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

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

半年５年は間違い。半年５人ね。

>>72
俺は>>57の後半辺りの話をしているつもりだった。

>>71
>ウォーターフォールがなんとか回るのは余裕がある場合だけだ。

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

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

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

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

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

あほか（苦笑）。

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

>>76
>あほか（苦笑）。
>
>で、どの程度の規模のものが作れるの？
>半年、５人。ちょっと教えてよ。

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

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

いやいや、ＬＯＣで図るのは本位じゃないんだがね。
旧式の人間と話すときは、ＬＯＣで話すのさ。

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

>>72
>で、もう少し具体的に書くと、計画ゲームの参加者は、
>ユーザ = 顧客の業務担当＊ｎ、顧客のＳＥ、うちのＳＥ
>開発チーム = プログラマ１０前後
>でした。

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

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

>>78
俺はLOCでは見積もらない。各フェーズの人ｘ月ｘ単価が基本だ。
ま、これも当然目安に過ぎないけどね。

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

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

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

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

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

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

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


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

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

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

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

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

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

哲学は人の数だけあるからねぇ。
お、XPは哲学かも。

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

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

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

要するにﾁﾐはだめプログラマだね（・・）

濱井はまだうだうだいってんのか？
だれか殴って来い。ろくな仕事も出来ず同僚に食わせてもらってる身分のやつが、
何えらそうなことほざいてるんだ。来期リストラ候補のトップに上がってるのに本人は
わかってるんだかわかってねーんだか。

>お、XPは哲学かも。

だーかーらー、以下略。

XPは宗教なのか哲学なのか、小一時間（略）

プログラミングは哲学です。
書かれたコードにはその人の人生が表れます。

プログラムは著作物なんだよ
著作物は「思想」又は「感情」を「創作的」に表現したものなんだよ

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

>>89
いえプログラミングは宗教です。
イテレートのたびに魂がより高いステージに上がるのです。

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

XP自己啓発セミナー


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

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

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

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

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

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

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

セミナーでもペアを組んだり、少人数のグループに分かれてゲームをするなな（ｗ

するなな→するなぁ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いってみればXPってのはバブルなんだよ。実力はまだまだだ。

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

んー？まだウォーターフォールのほうが有利だなんて寝言いってるのか？
というより、ウォーターフォールをまじめにやってないんだろうなぁ（苦笑）。

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

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

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

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

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

同じ 「ウォーターフォール」 という言葉だが、内容が違っている罠。

>>99

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

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

あほくさ。
プロセス論も知らないのかよ。
見積もりもできないわ。すげーな、さすが政治的ＳＥだよ。

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

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

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

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

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

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

>>102
>あほくさ。
>プロセス論も知らないのかよ。
>見積もりもできないわ。すげーな、さすが政治的ＳＥだよ。

お互いの立場を入れ替えて議論する？（ｗ

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

>>99
期間半年で５人のプログラマって、どういうプロジェクトかな。
うちは普通その期間なら１〜２人、多くて３人だと思う。
実際３人というケースは稀で、一人は新人教育を兼ねて、みたいな感じだと思う。
プロジェクトに関わる人数が多い場合もあるけど、それはプログラムに関係
ない部分がほとんどなんで、この話には関係ないよね？
半年でプログラマが５人も必要って事態は、デスマーチとか思いつくけど。
デスマーチを効率良く回せるのがＸＰってことかな？

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

>>107
どの辺が宗教論争なの？

ＸＰ＝デスマーチですか？

>>109
明るく、前向きに、プラス思考で！

今朝社長に言われたろ？

>>107
>なんでXPの話をするとすぐに宗教論争になるんだろう。

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

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

XPの良いところは、リリース速度が速いことだと思う。
一つの機能追加のために不安定な挙動になることを容認せず、
ただひたすらペアプロ＆テスト。
結果的に、「どう動くかみせて」と言われたときに、
必ず最新バージョンを提供できる。

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

中間リリースをお願いすると、PGはぶーぶーいうけどXPって呪文を唱えると、
好きになるんだ。面白いね。なんで？

XP実践したら
最悪なことになって
途中で断念・

>>113
XP(やそれに類する状態)が出来てないと中間リリースを
やっても混乱するだけなことがわかっているから。

>>114
参考の為に失敗例を具体的に教えて。
問題点、改善点を探そう。

>>114
XPを途中でやめるってことは、そのままデスマーチ突入だから、
やめてもやめなくても同じ（ｗ
唯一４０時間労度が１２０時間労働になるだけ。
それかプロジェクトを概略設計からやり直し。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>実際はそこまでくれないけどね（Ｔ＿Ｔ）。
>ＸＰやったらやめられなくなっちゃったよ。
>ＸＰマンセーの所以だね。

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

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

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

ここでXP信者の方々にとっておきのアドバイスをあげよう。

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

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

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

いい忘れたけど「顧客の騙し方」このマニュアルが出来たら、ぜひ教えてね。
そのマニュアルをえさにするならなら入信してもいいよ。

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

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

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

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

>>112

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

そのとおり。

>これが宗教？

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

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

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

XPが宗教である所以

>>120

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

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

共生以て甦六

>>122
それもタスクのうちに入るよ。

>>122
>40時間はみっちり目の前の仕事に集中してもらって、勉強は各自労働時間
>外でやってもらうってこと？

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

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

いや何かとウン万ステップとか謳い上げるもんでね。
効率の悪さも時には「必要悪」ってこと。

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

>>103

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

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

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

テストの工程は無いの？

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

 water form　 ･･･

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

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

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

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

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

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

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

ドキュメントについて追加。

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

>>131
面白い。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それはそう。

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

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

補足

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

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

># ISOとXPは相性悪いかな、と思えてしょうがないです(^^;

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

HAMAIタンはXPのどこをどうとって信頼性軽視といってんだ？
例えば作成とテストを同じ人がやるから、監査面で信頼性が悪いといってんのかな。

ついにアスパラ君、完璧なる分析を断念。
というより、すでにオーバースペックだね。
ざっとやれって言ってるのになぁ（苦笑）。

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

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

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

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

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

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

ＸＰマンセー。ハイル　ベックたん。
ハマイタンもがんばれー（笑）。

>>140
その点は受け入れテストがカバーしてるよね。

やっぱし濱井タンはXPの中身よく解ってなかったのね。
xUnitも使ったこと無いんだろーなぁ。

>>141
＞いやー、本当に考える量がむちゃくちゃ減りました。

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

>>144

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

>>144

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

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

>>143
濱井タンって実はソフト開発したことないんじゃない？

>>141

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

ねぇ、XPでやらせたらとんでもねーことになった、とかの体験談ないの？

昔は、ソーティング法どれを使うかで小一時間悩んでたりもしました。
今は、もう簡単。最小値選択かバブルソート。
１０秒で実装できる奴を選びます。
Ｊａｖａならユーティリティがあるけどね。

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

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

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

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

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

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

>>149
あるわけないだろ。
今ＸＰやってるのはあるレベル以上だけ。

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

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

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

>>150
まだ少々修行が足りない。

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

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

>>151

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

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

>>150
なんかキミの文章読んでると、XPやると馬鹿になるんじゃないかっていう
恐怖を感じるよ。

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

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

>>154
XPに転職というのはね。ＲＰＧ的にいうとね。

速度＋４
正確さ＋２
力強さー２
体力＋１
忍耐度−４
知力ー２
知恵＋３
運命＋２
カリスマ＋３

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


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

あっ、途中きれ（＾＾；
体力＋１ってのは体力に余裕出るの意味。
忍耐力ー４は、まじせっかちになったかなー（＾＾；

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

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

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

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

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

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

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

ところでさあ、他の項目にコメントする気はないけど（聞いても
答えは予測できるし）、

＞カリスマ＋３

これはどんな理由なの？

設計を最初にやる意義がまったくわかりません。
要件の分析や定義を早めにやるのはまあ理解はできるけど、

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

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

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

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

>>160
身だしなみに気をつけるようになるから（爆笑）。
ペアプロだし、お客様常駐だからね。
ヨレヨレ状態はまずいっす。

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

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

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

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

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

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

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


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

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

>>163
>
>オブジェクトの識別って難しいんだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>167
>アルゴリズムはどうにもならんようには思います。

そう。

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

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

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

だから

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

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

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

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

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

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

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

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

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

（少しは前のレスも読めよ）

>変な仕様書書いて、それを後から修正するほうが嫌です。実際それでキレて
>辞めたことがある。

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

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

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

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

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

>>168
インターフェイス作ってアルゴリズムを隔離しておくことぐらいは
設計とは言わなくない？

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

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

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

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

ウォーターフォールだと必要以上にドキュメント中心になる傾向が
あるような。そんなには相関ないだろうに、なんでだ？

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

>>170
>インターフェイス作ってアルゴリズムを隔離しておくことぐらいは
>設計とは言わなくない？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>171
>ウォーターフォールだと必要以上にドキュメント中心になる傾向が
>あるような。そんなには相関ないだろうに、なんでだ？

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

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

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

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

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

しかしねぇ、コードという明確な形まで落としておかないとね。
頭に覚えてなきゃならないんで精神的にどんどんキツクなるんだよね。

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

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

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

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

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

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

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

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

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

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

>>172
やっぱりアルゴリズムのラッパーを設計というのはどうかと。
これも趣味の問題か。

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

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

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

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

動かしながら設計のひとつの形は以下のリンクのとおり。

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

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

みんな、ＲＵＰやるより、Smalltalkいじりなよ。
そのほうが、ＯＯがよくわかるよー。

>>176
そうなんだけどね。
でも、多数のプログラマを見てきたところ、
彼らはまだ日本語？で考えるのがやっとらしい。
コードで考えられないようなんだ。

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

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

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

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

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

http://dspace.dial.pipex.com/jacksonma/
マイケルジャクソンは上の人。英文だけどね。

>>175
あれは構造化のほうのプログラムが（意図的に？）関数の括りだしを行っていない
あんまりな例なので、ちょっとひいた。

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

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

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

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

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

>>175
>ＸＰはそういう意味では、開発全部の期間を設計にしようというスタイル。

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

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

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

例えば

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

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

>>182
説明しにくいだろうねぇ。別に否定はしないよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ほらほら！読んで見れ！
http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1490-1

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の方がまだしも戦略的ですが。

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

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

>>181
>入力のほうはね。
>ItemFactoryのほうのelseifを問題にしたい。
>Hash使うとかで、文字列とClassの辞書作っておいて、さくっと呼びたい気分。
>初期化のところがダラダラとなるけど。
>
>説明用だからわかりやすいのを選んでいると思っているんだけどさ。
>
>ＯＯＰでは、elseifとかswitchは滅多に書きません。
>必須なのかどうかチェックしないとね。
>
>よいうことで、問題にしているのは、ＲＵＰとＸＰでは、
>コードの落ちつく先が違うってこと。
>余計なクラス作るのがＲＵＰ（分析ご苦労さま）。
>その分メンテが増えるんだよなぁ。

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

>>186
名前は派手だけど、あんまりたいしたこと書いてないね。
看板に偽りありって感じだ。
「超初心者向けデザインパターン入門」って名前変えたほうがいい。

>>189
ん？
ああ、コードのどこが問題かはもともと明らかでしょ。
違う？なら失礼（苦笑）。

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

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

>>191
>設計ダケやってると、クラス構成が大げさになるということだけ。
>あるいは、Ｒｏｓｅいじりまくってるとと言い換えてもいい。
>最近はＵＭＬかけるツールいくつも出てきているけどね。
>
>で、コードセントリックなＸＰマンセーとつながるわけだよ。
>言いたいのはそちらだけ（笑）。

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

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

ピンク本に登場する Ann は１つ受け入れテストを通すたびに End Zone Dance をやる、とのことで、

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

テストそのものに喜びを見出せないから、ごまかしてんじゃないの？

ﾂﾚﾀ

このスレ読んでると反XPの人の方が、まともに見えるんですけど。

XPの人の方がまともに見えるスレなんかありましたっけ？

>テストそのものに喜びを見出せないから、ごまかしてんじゃないの？

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

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

>>198
そんなにうれしいなら、逆に金もらわにとな。

XPの胡散臭さが認知されてきてうれしい限りです。

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

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

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

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

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

>>201
>胡散臭いねぇ。くくく。
>おお、あの程度じゃ大げさじゃないんだ。すごいねぇ。

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

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

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

>>196
> このスレ読んでると反XPの人の方が、まともに見えるんですけど。

なんか・・・XP も 反XP もどっちも厨に見えてきてるんだが気のせい？（ｗ

所詮は耳学問だし

何の足しにもならない当たり前のこといってんだか。

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

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

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


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

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

>>204
普通のスパイラル型と変わらないなら、XPだとどこがいいの？
スパイラル型でもテストはするよ。

kimochi...

>>207
ガキ（HAMAI）は大人の話の仲間に入れてもらいたくて、必死と思われ。

XPで開発したとして、間に1年ぐらいブランクがあったとする。
1年後にも変化を抱擁できるの？

>>211
ユニットテストがあればできる。

201 vs 203は203が正しいと思う。
201はソースの細部にこだわりすぎ。

>>212
じゃあ元のメンバーが誰もいなくなってもできるの？

おれはXPに期待してる。
でも、別に万能って思ってるわけじゃない。
あんちの人は反例が極端過ぎないか？
どうしてそんなにむきになるのかなあ。

俺も知りたい。
XPで開発されたソフトの変更を別の会社に頼めるのか。
その時ソースコード以外は要らないのか。

>>216無理。もう一度開発しなおすしかない。

＞あんちの人は反例が極端過ぎないか？

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

>>216
XPは引継ぎは出来ない。

>>218
BASICインタプリタの開発とかって。そんなのおれたちの仕事とは違うだろ。
それに元メンバがいなくなって１年後に苦労するのは、なんだっておんなじでわ？

XPを支持してるのはたいしたプログラム作ったことないやつばっか。

>>221
期待通りの反応をありがとう。
そういうのに限って。。。だよなー。
あーあ。

自分の周りにいるやつを基準に考えないことだな。＞２２２
井の中で満足してろ！

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

簡単なインタプリタを作るって仕事はそこそこあるよ。もちろん絶対量としては少ないけど、できるところはあまり多くないから（つーか尻ごみするとこが多いから）結構仕事としてはおいしい。

>>205
ま、妥当な判断だね（ｗ
こんだけ煽ってるんだから。

>>224
古いコードをメンテするぐらいなら作り直す、って性質のプログラムにはいいかもね。

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

■■■■■■■■■■■■
　このスレ、壊れてる。
■■■■■■■■■■■■

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

>>229
参考までに聞くけど、１日でいいわけ？

>>230
それは状況に依存する。

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

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

1日どころか1イテレーションは貸し出さないといかんのでないか。

顧客役も張り付ける必要あるよね。

現実問題として引継ぎなんてできないと思うけど。

>>216-217

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

>>235

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

>>236
JUnitがどういうものかぐらいは当然知ってると思うけど(笑)

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

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

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

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

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

>>238
>その時どれくらいの日数が必要なの？ゼロでよいの。

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

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

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

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

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

http://www.ne.jp/asahi/e/yamane/software/engineering/xp/daiary/xp_fever.html

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

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

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

>>242
前半だけど、それがXPの営業の仕方か。おもろい(笑)

ついでにBasicのインタプリター？
もろ、ＸＰ向きじゃないか。

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

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

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

>>208

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

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

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

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

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

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

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

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

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

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

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

>>242

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

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

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

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

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

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

>>244
>一人でいけるな。一ヵ月後あたりにはリリース可能。

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

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

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

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

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

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

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

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

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

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

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

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











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

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

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

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

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

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

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

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

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

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

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

｢質｣とは？

>大規模なものはテスト項目の詰めやテスト環境の開発なども当然やる。

小規模だとしないの？

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

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

>>248

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

よくない。

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

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

スムーズ？

>>253
>>大規模なものはテスト項目の詰めやテスト環境の開発なども当然やる。
>
>小規模だとしないの？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>254
>その程度が何をさしているのかはっきりしないけど、論理的に正しいのは

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

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

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

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

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

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

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

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

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

> 顧客側の担当者が馴れ合いでテストコードを決めていないかどうか、監査可能？

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

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

>>259
>> 顧客側の担当者が馴れ合いでテストコードを決めていないかどうか、監査可能？
>
>そこは、もう XP とか開発とか、そういう領域越えてしまってる。

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

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

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

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

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

XP = eXtreame imPotence

横から素人なんすけど、極論すると、
１．XPでもウォーターファールでもやるべきことは一緒
２．XPはちょこちょこやり、ウォーターはどかんどかんとやる
ということのような気がしてきたんすけど。
それなら、ちょこちょこやった方が絶対いいと思うだけど。

>>261
話の流れに致命的な間違いがある。

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

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

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

※1：完成ではなく、公開のことね。ソフト開発に終わりなど無いのだから。

正直、糞の役にもたたない仕事のための仕事みたいな事務作業
をやりたくないので、XPまんせーです。

>>265
>その点、クライアントに実際の挙動を見せた上で「思った通りか？」と聞くXP的なテストは、
>仕様書通りか？というテストよりは、クライアントの要求を汲んでいると思うのだが…。

だからXPのテストの正当性をささえるのはフィーリングではないの？と
いったのだけどね。（ｗ

フィーリングをよい意味ととるか悪い意味と取るかは人それぞれ。

>XPのテストの「質」。こんな説明ではどうかな？

一つの説明だと思うよ。サンクス。



>話の流れに致命的な間違いがある。
>
>XP本の中でテスト工程として明示されてはいないが、XPにあって、
>ウォーターフルーに無い「テスト工程」があるじゃないか。
>
>XPでは「驚くほど短期間でのリリース(※1)」がテスト工程を兼ねているんだ。
>そうは思わなかったかな？

何も俺はXPのテストはおかしいとか批判しているわけじゃなく、
どういうものなのだ？と聞いているだけなのだから、間違いも何もないと思うが。

>第一、クライアントの一言で変わりかねない仕様書の通りに動くからといって、
>テストの「質」が十分だと思っているらしいが、私にはそうは思えない。

誰が十分だと思っているのかねぇ。目がおかしいんじゃない？
xxxの妥当性の根拠はｙｙｙに基づく、ってのは絶対的にｘｘｘが正しいとか
ｙｙｙが正しいとかいうもんじゃない。当たり前だよね。

駐車違反の取締りの妥当性の根拠を道交法に置くってのは、道交法が正しい
なら、駐車違反の取り締まりは正しいってだけの話だ。道交法も駐車違反の
取り締まりも絶対的に正しいなどとは誰もいっていない。

同じ言い方をすれば

＞その点、クライアントに実際の挙動を見せた上で「思った通りか？」と聞くXP的なテストは、

この部分は

顧客が短期リリースの成果物を使ってみて下す評価を、XPのテストの妥当性の
根拠とするってなるかな。

俺はどっちかつーとテストコードによるテストの方の話をしてたんだけど、
キミの上げた点は、もちろん重要だとは思うよ。異議がなかったからそもそも
話題に出さなかったけど。

>>266
>正直、糞の役にもたたない仕事のための仕事みたいな事務作業
>をやりたくないので、XPまんせーです。

この短い文章がすべて主観で構成されている。見事だ。

>>267
スマソ。最初の行は完全に余計だったな。
俺が話の流れを追えていないだけだったようだ。
逝ってくる。

>>268
いやいや、全体的に俺の文章は煽り調子で書いてあるけど、
腹を立ててるわけじゃないから、逝かなくていいよ。（ｗ

で、いったい何を問題にしているのだ？

オレがいえるのは、
Windows95で動いていたソフトを98対応にするのに、
ウォーターフォールなら、半年や一年はゆうにかかる可能性がある。

Windows2000で動いていたソフトをＸＰ対応にするのに、
動くかどうかの判断さえ、一週間以内に帰ってくることはない。
電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。

あるいは、Linuxのカーネルやglibcをセキュリティ対策で
アップグレードしたら、使えなくなる可能背のあるソフトウェアを
作っていてもウォーターフォールプロセスでは致し方ない。

あるいは、保守メンテナンス費用を払っていても、
アップグレードには時間がかかり実質的には再開発が必要である。
すなわちメンテナンス費用は払う必要のない費用である。

こういったところだが、反論あるの？
というより、ちゃんとテストカバレッジ出してる？
出しているなら金持ちソフトウェアハウスだな。

でもテスト仕様書は、手書きなんだ。ふーん。
結局２，３ヶ月テストするんだ。気狂いそうにならない？退屈でさ。

僕らはボタン一発。GreenかRedかだけだからね。簡単。

結局、ソフトウェア開発で自動化しなければならなかったのは、
設計フェーズではなく、テストフェーズだったという
ベックのアイディアはすばらしい。

ベックマンセー。ＸＰマンセー。

>>270
>Windows95で動いていたソフトを98対応にするのに、
>ウォーターフォールなら、半年や一年はゆうにかかる可能性がある。

それはかかるかもね。

>Windows2000で動いていたソフトをＸＰ対応にするのに、
>動くかどうかの判断さえ、一週間以内に帰ってくることはない。
>
>電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。

これは開発プロセス云々というより仕事のスタイルがそういうスタイルが
多いということでは？開発者がその時別な仕事をしていれば、すぐには
対応できない。

迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
俺はあまりその方向に力を入れるべきとは思わないね。作業者には
一つの仕事に集中させたい。繰り返すけど、にもかかわらず機動性の
ある会社は本当にすばらしいと思うよ。

>あるいは、Linuxのカーネルやglibcをセキュリティ対策で
>アップグレードしたら、使えなくなる可能背のあるソフトウェアを
>作っていてもウォーターフォールプロセスでは致し方ない。

セキュリティ対策はだいたい保守契約の範囲で行うことが多いね。
カーネルを入れ替えて動作チェックする程度のものであれば。
チェックした結果動作せず、ソフトの変更が必要って場合は、別途
話し合う。

ま、セキュリティパッチ程度の変更で動かなくなるのは、もともと
バグに近いようなコーディングをしているとかだね。

他の多くのソフトでも問題がでるようなメジャーアップグレードの場合は
別途話し合いだろうね。

>あるいは、保守メンテナンス費用を払っていても、
>アップグレードには時間がかかり実質的には再開発が必要である。
>すなわちメンテナンス費用は払う必要のない費用である。

それはなんか偏った見方じゃないの？セキュリティパッチにも
対応しないなら、君の言うとおりその会社にメンテナンス費用を
払う必要はない。というよりすぐにそんな会社に仕事を頼むのを
やめろ。

他のソフトでも問題が出るようなメジャーアップグレード
については、メンテナンスに含めないと思うよ。この場合どの
程度かはケースバイケースだけど「再開発」だろうね。

>こういったところだが、反論あるの？

といったところだ。俺があんたの客なら、こういったことがXPだと
魔法のように解決する、とか言われても信じられないねぇ。

>というより、ちゃんとテストカバレッジ出してる？
>出しているなら金持ちソフトウェアハウスだな。

最初から要求する顧客はあまりいないね。というか今のところ俺はないね。
デスマーチになって、不安になった顧客が、要求するってことはあるねぇ。
その場合重要なモジュールについては行うね。開発会社内で自分たちの
デバッグのためには行うことはあるね。

>でもテスト仕様書は、手書きなんだ。ふーん。
>結局２，３ヶ月テストするんだ。気狂いそうにならない？退屈でさ。

まぁ、その辺は考え方だからね。いろんな人間がいるから向き不向き、
好き嫌いはいろいろあるから、ある程度適材適所に配置する。（裁量の
範囲でね。そもそもテストは開発とは別の人間が行うことが望ましいし。）

お役所で働いている人間がいるように、ソフト開発会社でもお役所的
な仕事をする人間はいる。すべての人間がクリエーター（笑）である
必要もないし、あるはずもない。

>僕らはボタン一発。GreenかRedかだけだからね。簡単。
>
>結局、ソフトウェア開発で自動化しなければならなかったのは、
>設計フェーズではなく、テストフェーズだったという
>ベックのアイディアはすばらしい。

で、最初の質問の答えだ。俺は何を問題にしているかといえば、
テストの作業そのものは自動化出来ても、テストの内容の検討
（一種の設計だね）は、当たり前だけど自動化できない。これは
本来のソフト開発と同じように、テスト工程も「開発」なわけだ。

君が言ってるテストの自動化ってのは、ソフト開発で言えば、
コンパイル・リンク作業が自動化された、とはしゃいでるだけだ。

>迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
>俺はあまりその方向に力を入れるべきとは思わないね。

そう思うならXPは永遠に理解できないよ。
価値観が違うからね。

現在の顧客の多くは、迅速性にコストを支払う価値があると考えている、
ということを前提にしているのがXPであるから、その価値観を抜きにして
話しても仕方ない。

>30分で全体の大雑把な構造と重要部分のある程度立ち入った構造が
>見渡せる規模。数1000行〜1万行ぐらいじゃない。

なるほど。鶏と卵だね。

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

242のリンク先が、そう主張しているってこと。
248で誤読しているようだったので、訂正しただけです。

>>273
>>迅速な対応を売りにしている会社の努力はすばらしいと思うけど、
>>俺はあまりその方向に力を入れるべきとは思わないね。
>
>そう思うならXPは永遠に理解できないよ。
>価値観が違うからね。

もとの文脈は、現在やっているプロジェクトのメンバを一時的に
借り出してきて、迅速にイレギュラーな対応（例えばWin95で
開発されたソフトがWin98で動作するかの問い合わせがあれば、
すぐに確認し答える）をすべきか否かについてだ。

どのプロセスでやるにしろメンバをなるべく一つの仕事に集中させたいという
意味だ。念のため書くけどね。だからそれを含めて価値観が違うというなら
（メンバの集中力を重視せず、迅速に顧客対応するのがよい）、そうなのだろう。
俺は集中力の方を重視する。

>現在の顧客の多くは、迅速性にコストを支払う価値があると考えている、
>ということを前提にしているのがXPであるから、その価値観を抜きにして
>話しても仕方ない。

したがってメンバが一つの仕事に集中することと、顧客への対応を迅速に
行うことを両立するなら、（ありきたりの考えだが）規模を大きくして人数を
増やすしかない。

もちろん小規模で迅速な対応を実現している会社の努力には敬意を
評するがね。ただ、例えば過去にやったプロジェクトの量や質にも影響
すると思うがね。少数のプロジェクトなら対応は容易だろう。多量の、そして
そこそこの規模のプロジェクトをどれも迅速にというのは難しいと思うよ。

>>274
>>30分で全体の大雑把な構造と重要部分のある程度立ち入った構造が
>>見渡せる規模。数1000行〜1万行ぐらいじゃない。
>
>なるほど。鶏と卵だね。

そうだよ。あまりにも当たり前だから言い訳さえしなかったけどね。
それともキミは適切に説明できるのかい？
くだらん煽りの域をでないコメントだ。

>>>つまり、他の方法では「その程度の規模ですらスムーズに引き継げない」ってこと。
>>これはそんなことないと思うけどね。
>
>242のリンク先が、そう主張しているってこと。
>248で誤読しているようだったので、訂正しただけです。

同じくくだらんね。言葉遊びだ。

>そうだよ。あまりにも当たり前だから言い訳さえしなかったけどね。
>それともキミは適切に説明できるのかい？

なんの言い訳？なんの説明？

>>248で誤読しているようだったので、訂正しただけです。
>同じくくだらんね。言葉遊びだ。

ああ、元々くだらん煽りでしたか。

>もとの文脈は、現在やっているプロジェクトのメンバを一時的に
>借り出してきて、迅速にイレギュラーな対応（例えばWin95で
>開発されたソフトがWin98で動作するかの問い合わせがあれば、
>すぐに確認し答える）をすべきか否かについてだ。

そうなの？
OSのバージョンアップに伴う、ソフトウェアのバージョンアップという
新たな発注に対して、顧客が考える適切な速度で対応できるかって
話かと思ってた。

>したがってメンバが一つの仕事に集中することと、顧客への対応を迅速に
>行うことを両立するなら、（ありきたりの考えだが）規模を大きくして人数を
>増やすしかない。

ここの論理がわかりません。
規模を大きくしたら、なんで両立できるの？
っていうか何の規模を大きくするの？

>>275
だから聞いているのは、

ＯＳにセキュリティパッチあてるたんびに、
ユーザが本当にこのパッチ当てても大丈夫のか？
こう聞かれて、きちんとドキュメントの形で
以下の、納入時に行った試験項目と同等の試験を行いパスしました。

こういう報告書を出せるのか？
こう聞いているんだが無理だろ？
保守料貰ってても、コスト的に絶対無理なはずだ。
認めちゃえよ。

ＸＰは出せる。それだけだ。
別に主担当者じゃなくても、報告書が作れる。

ＯＳアップデートして、半日無作為にいじって遊んで、「動くようですよ。」
こういう答えを期待しているわけじゃない。
「品質保証」を求められた時、どう対応するんだ？

ついでに動かなくてもそれは仕方ないのだが、
何日で対処できるんだ？すぐ見積もりでるのか？
ＸＰはその類の見積もりは最速で出すぞ。
しかも、かなり精度高い。
どこにバグがあるかの検出が早いからな。

ＸＰというのは、突き詰めて言えば、開発上流から作られた方法論じゃない。
むしろ保守しながら開発する中でできあがってきたものだ。
だから、保守関係のプロセスはほぼ完璧だ。
ほかのプロセスでそういう味付けのモノはオレは知らない。

保守担当者がほしいのは、ドキュメントではない。安全なんだよ。
ＸＰのプロセスはそれを保証してくれるのがマンセーな所以なのだ。

ついで、
今の世の中ＰＣのハードウェア構成、ソフトウェア構成は、
はちゃめちゃに不統一だ。
このような環境で、
「お宅のソフトウェアをおれのマシンで使えるかどうか
すぐに知りたいのだが、どうだ大丈夫か？」

これにちゃんと技術的に答えられるか？
自動化受け入れテストがなけりゃ、こんなもの断言できるシロモノじゃない。

「多分動くと思いますよ。でも、保証の範囲外ですね。」
秋葉原の店員レベルのトークをしなければならないだろ？
何と相性悪いのかもお客さんに教えてもらわなきゃならない始末だ。

だから、ＸＰはすばらしい。ＸＰマンセー。

>>276
ん？あんたのいうことを俺が勘違い
してるのか？鶏と卵を別な言葉で
説明してくれないか？

俺にはあんたが『規模』とは何かって
話を持ち出して話をわやくちゃにしようと
思ってるのかと思ったんだがね。

違うなら謝った上でちゃんとレスするよ。

>>277
新たな発注についてなら計画を立てて
プロジェクトをスケジュールするから、
何も問題は出ないと思うけど？

ウォーターフォールが小回りが効かない、
といってもハードのアップグレードやwindowsの
アップグレードのスピードについていけ
ないほどじゃないと思うが。

ついていけてない製品があるなら、
それは開発形体の問題ではなくて、
会社としてその製品のアップグレードに
どれだけ金をかけるか、って問題だと
思うけどね。

>>277

＞規模を大きく

つまらんありきたりの話だけど、メンテ要員や
ユーザーサポート要員を増やす。。。

>してるのか？鶏と卵を別な言葉で 説明してくれないか

いいですよ。

>>242のリンク先では、「他のプロセスでは、こんなに素早く引き継ぎができない」
という主旨の文章を、>>248では「スムーズに引継ぎが出来る規模だから、
スムーズに引き継げたんだ」という主旨の発言をしているように見えました。

そんな当たり前のアンチテーゼを出す以上、元々引継ぎがスムーズに行くか
どうかなんて議論するつもりがなかったんだと解釈して、

>ああ、元々くだらん煽りでしたか。

となってます。

あなたの発言は、煽りとそうでない部分の判別が付き辛いですね。

>新たな発注についてなら計画を立てて
>プロジェクトをスケジュールするから、
>何も問題は出ないと思うけど？

最初の問い合わせで、↓のような対応しかとれなければ、
多分発注はこないと思うよ。

>Windows2000で動いていたソフトをＸＰ対応にするのに、
>動くかどうかの判断さえ、一週間以内に帰ってくることはない。
>
>電話で聞いただけなら、「動くはずですよ。」こういう願望の言葉が聞けるだけだ。

>>278
＞報告書

可能だよ。もちろんコストはかかるよ。
そのコストを顧客が望むか、どういう形で
望むか（開発費に入れ込むか、保守費
に入れるか、ここに毎回負担するか）は
さまざまだ。テスト環境の構築や維持
の方法もね。テスト用のサーバとかも
必要になるし、自動化できないテストも
ある。（自動化する努力はもちろんすべ
きだから、XPの考えを取り入れるのは
悪くないがね。）

XPはデフォルトでテストツールの作成が
開発費に折込済みであることと、それでも
開発費がそれほど増えないといいたい
のだろう？

その点は特別異論はないかが、テスト内
容（テストコード）の正当性の根拠は何に
基づくのかがに関していまいち説得力の
ある説明が君からは聞けていない。

>>285は極端なインポ

>>278
＞何日で対処

こう聞かれた場合、人のやりくりが一番
ネックだね。XPではネックにならないの？

>>279
＞いろいろなハードウェアへの対応

テストの自動化と人海戦術の両輪だね。
なにも自動化はXPの専売特許じゃない。
開発とテストを密接に連動させる点は
ユニークだが。

客先に環境で動作するか否かについては、
ハード構成もさることながら、微妙な
コンフィグレーションの違いにに悩まされるね。

ま、相手先にテスト環境一式を持ち込んで
テストというのもよいかもね。ただ結局人
件費がねぇ。。。

あー、「ＸＰ狂信者」と「XP信者」ってのがいるのか。

「ＸＰ信者」と「XP信者」だと勘違いしてて、全角ＸＰと半角XPで
あまりにも文体が違うので、ひとりでモード切り替えでもしてるのかと
思ってたYO!

スレ違いかもしれんけど、聞いていい?

UnitTest はすばらしいと思うけど、web の UnitTest って
どうやって実現するの? 各ページは HTML による疎な結合を
してるから、テストしにくい。仮に引数渡すレベルのテストは
実現できたとしても、Javascript のテストはどーなるんだろう。

あるいは、操作記録再生ツールでも導入して、テストパターンは
手で入力し、テスト自体はそれを再生したりするの? (そういう
ツールはあるようだが、時間が取れなくて試してないのっす)

>>283
なるほど、悪かった。

聞きたかったのはXPでこの程度の
規模だとこんな引継ぎの形になり、
別の規模だとまた別のこんな形になる、
といった内容。

規模をどう表現するかって点は棚上げしてね。

その発言が単なる煽り区別がつかなかったのであれば、俺の修行が足りないためだ。申し訳ない。

>>284

おれのその発言は
製品として顧客のニーズを見越して
開発することを念頭においたものだ。

顧客からの問い合わせがあって初
めて動き出す場合については（予想
ができないケース）、機動性が重要
だろうね。けどOSやハードのアップ
グレードについてなら、いつなにを
しなきゃならないかの予測は結構
あたると思うけどね。

は割と

>>289
それについていえば、微妙なタイミングとかもね。Submitボタンを押すタイミングとか、
サーバが過負荷な状態での操作とか、なかなか自動化しにくい。シミュレートは
出来るが、そのシミュレートが本当に妥当なのか、不安が残る。だから
今のところこういった部分は自動化ツールも使うけど、最終的には人手に
頼ってる。

XPを使うとうまい自動化の方法があるんでしょうかねぇ。

>>292
人手だと繰り返しが面倒すぎるので気合をいれて自動化すべきかと。
面倒なテストを人間にやらせると信じられないくらいの確立でサボる、
もしくはミスをします。

で、普通に作ったら自動化が難しくなったりしちゃうんで、
自動化テストを容易になるような設計をしたり（事前の設計ぎみ）、
それ用のツールやらライブラリをそろえたり（YAGNI違反ぎみ）してるんだけど、
それはＸＰ的にどうなんだろう。ダメ？

>>293
>>>292
>人手だと繰り返しが面倒すぎるので気合をいれて自動化すべきかと。
>面倒なテストを人間にやらせると信じられないくらいの確立でサボる、
>もしくはミスをします。

その対策も考える。これを不毛と呼ぶか重要なことと考えるかは、
相手にしているソフトよると思うけどね。

基本的には同じテストを複数人にやらせて、同じ結果になればOK
とする。特異な結果がでれば、テスト内容かテスト対象のプログラムか
テストしている人間のどこかに他と違う要素があるわけだから。

またわざとバグをもぐりこませておいて、それがちゃんとテストでレポート
されるかを確認する。

自動化の努力は言うまでもないのだけど、自動化されたテストが
妥当なものかを検証するために、人間が行ったテストとの相関を
とることが往々にして必要になる。

人間がやったテストと同じ結果がでるなら、その自動化テストは正しい
という考えが必要なことが結構あるからね。

>>292
XPでもツライと思いますよ。
ビジネスロジック層ならいけるのですがプレゼンテーション層はツライ。
UnitTestの弱点はやっぱりこういうビジュアル的なテストだと思います。
グラフィック＆音関係もツライですね。
これも最終的な出力はUnitTestしにくい。
しかし、出来るところはUnitTestをで自動化をしたほうが効率は断然良いと思います。
一番粒度の小さい（メソッド単位）テストですからバグがあった場合はたちどころにその場所が解りますし。

XPのテストで私が一番面白いと思ったのは「テストファースト」の考えですね。
先にテスト（メソッド単位）を書いてそのテストが成功するように実装する。
で、成功したら次のテストを書いてまた実装するって感じで一気に全てのテストを書く場合と違って大変テンポが良いです。
私の経験ですが最後にテストを一気に書くとたいていテスト自体にもバグが混入します。
テスト自体の設計も複雑になりますし書き上げるまでテストできません。
ここら辺はやっぱりXPは優れていると思います。

それからカイロさんの言われているテストも非常に重要だと思います。
実際に目的サービスとして機能しているかのテスト、いわゆる「機能テスト」ですよね。
これは、自動テストは難しいと思います。
XPではこのテストは先ほどのUnitTestと明確に分けていますね。
XPではこのテストの仕様の設計をお客さんにしてもらいます。
お客さんの求めている機能はお客さんが一番知っているという考えですね。
そして、それに合わせてテストを作るまたはテスト計画を立てます。
ここら辺はおそらくカイロさんのおっしゃっているテストとさほど変わりないと思いますよ。
ただ、UnitTestで既にかなりバグは少なくなっているのでバグ取りというよりお客さんの
求めている機能とこちらの解釈した機能が合致しているかの確認作業みたいな色合いの方が濃くなります。

こんな感じですがどうでしょう。
XPは結構実現が環境的に難しいものもありますが（ペアプログラミング、オンサイト顧客など）出来るところだけ使っても
とても役に立つと思います。
今回は書きませんでしたが「UnitTest」は「リファクタリング」をするときにその威力を発揮します。
バグをおそれずに平気でプログラムの根幹を改造できるのもこの二つのおかげです。
この二つだけでも一回実践して見ては。

>>295
> 今回は書きませんでしたが「UnitTest」は「リファクタリング」をするときにその威力を発揮します。
> バグをおそれずに平気でプログラムの根幹を改造できるのもこの二つのおかげです。
> この二つだけでも一回実践して見ては。

漏れもそう思います。
XP そのものにははっきしいってマンセーになれないけど、
個々のプラクティスの中には、単体でも使えるものがごろごろある気がします。
業務用アプリ作ってて、ころころユーザーの仕様が変わるのに迅速に対応できているのも
「UnitTest」 と 「リファクタリング」 のおかげだと日々実感してます。

>>296
禿げ同
使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
結局はさじ加減でしかない。カイロとＸＰ狂信者、ＸＰ信者の話はもうあきた。

>使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
>結局はさじ加減でしかない。
おそろしく不同意だが

>カイロとＸＰ狂信者、ＸＰ信者の話はもうあきた。
こっちは同意。
UnitTest, リファクタリング周りのコードに関わる話題と
それ以外でスレだか板だかを分けた方が良いのかも。

>使えそうなものはなんでも使う。
使えそうなものが無駄足だったとき痛いから、みんな情報収集して
いるんじゃないの？

>XPとかウォーターフォールとかどうでもいい。
では何故このスレをウォッチしているのかと、小一時間（以下省略）

>結局はさじ加減でしかない。
そのさじ加減を定義しているのがプロセスだと思うんだけど。

>カイロとＸＰ狂信者、ＸＰ信者の話はもうあきた。
御意。
では次のネタをどうぞ。

MSはXPやらんのかね
VS.NETに標準でTestingFrameworkつけて欲しい

>>300
J Builder だけでなく Delphi / Kylix / C++Builder にも リファクタリング機構が欲しいぞ！ｺﾞﾙｧ！

J Builder だけでなく emacs / 秀丸 にも リファクタリング機構が欲しいぞ！ｺﾞﾙｧ！

>>297
>使えそうなものはなんでも使う。XPとかウォーターフォールとかどうでもいい。
>結局はさじ加減でしかない。カイロとＸＰ狂信者、ＸＰ信者の話はもうあきた。

恐ろしく無責任な発言だね。何の意味もない。
そのさじ加減が自分で判断できるなら、君はこのスレを読む必要もないし、
そもそもXPの本を読む必要ないんじゃないの？せいぜい本屋で立ち読みぐらいで
用が足りるだろう。

使えそうなものを使うなんてのは君に言われるまでもない。あたりまえじゃないかい？
君は使えなさそうなものを使うのか？

どういうときに何が使えるそうか、何が使えなさそうかを聞いたり言ったりしている
つもりなんだがねぇ。

どこのMLやBBSでもこういう（「使えそうなものを使う」）限りなく無意味な発言する
人がいるもんだね。

例えば、Web アプリケーションの受け入れテストで

「数字、機種依存文字、日本語、英語、など、文字列を入力しても、異常な動作をしない。」

なんてことになっていたら、どうする？

（HTTPUnit, WebUnit は受け入れテストで便利だと思うけど、これは時間が結構かかる。
時間短縮のテクニックがあれが教えてほしい。）

>>303
なんか、熱くなってんねぇ。別に >>297 は、「世の中 XP とか騒いで
いるから、良くわかんないけど導入してみるか (と言う上司がいがち
なんだな)」とか言うのは止めて、冷静に自分の所に合いそうな所を
つまみ食いしましょう。ってことだろ。現場としてはまっとうな意見だ
よ。
> どういうときに何が使えるそうか、何が使えなさそうかを聞いたり
> 言ったりしているつもりなんだがねぇ。
まあ別にそう言う議論をすることには反対しないけど、大概「どういう
とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

>>305
>なんか、熱くなってんねぇ。

んーこの程度じゃくだらなすぎて熱くなれないねぇ。

>つまみ食いしましょう。ってことだろ。現場としてはまっとうな意見だ
>よ。

まっとうすぎて何の参考にもならない意見だけどね（笑

>まあ別にそう言う議論をすることには反対しないけど、大概「どういう
>とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

そうだねぇ。無意味な一般論を出して発散させる人が多いからねぇ。
君や297みたいに。

>>305
>まあ別にそう言う議論をすることには反対しないけど、大概「どういう
>とき」って言うのがきちんと定義できなくて、発散しがちだからねぇ。

この世の中の大半の問題は「きちんと」なんて定義できないもんだよ。
きちんと定義しないままでもやりようはいくらでもある。

というより、きちんと定義できた時は、その問題が解決した（議論する
意味がなくなった）時なんだよ。根本的に君は考え方がなってないね。
君はえせ理想主義者だ。

>>304
結局それをテストコードに直すときに「など」とかの解釈で問題が
起きるよね。こういった「バグ」はXPでは検出できないだろう。

>この世の中の大半の問題は「きちんと」なんて定義できないもんだよ。

これが無意味な一般論か･･･。

>きちんと定義しないままでもやりようはいくらでもある。

>>305で言ってるのは、大概は、議論をするのに十分な程度も
定義できないってことだろ。

まあアンタはきちんと定義しなくても、発散しないんだろうけどね。

>結局それをテストコードに直すときに「など」とかの解釈で問題が
>起きるよね。こういった「バグ」はXPでは検出できないだろう。

詳細仕様書→テスト仕様書→テストプログラムの工程を踏めば
検出できるとでも？

結局、それだけの中間生成物をつくる工数を、XPはレビューに
割当てるから、もっと多くのバグを検出するよ。
バグを検出できるよ。

>>309
いやいや君の発言の無意味さに比べれば俺なんか足元にも及ばないよ。

>>310
なんかくだらな過ぎてレスつける気にならないんだけど。
どうしてもレスほしい？

カイロさん落ち着いてー。あっというまにただの煽り厨に成り下がってるよ。

俺は煽りだよ。（ｗ
過去の発言見てわからんの？

ま、まともな発言にはまともに相手するがね。
君に合わせるとこうなる。

少し整理すれば、XPのテストが強力だというのはあくまでコードレベルの
話であって、システムレベルの信頼性はまったく別の話だということ。

と総括できるかな。

>>314
> ま、まともな発言にはまともに相手するがね。
どもってんの ? クスクス。

まあ、どうでもいいけど。レスの数は有限なんだから、まとめて書けよ。
迷惑だよ。(ま、煽り屋を自認して奴に何言ったって無駄だし、彼に言わせりゃ
「無意味な発言」と言うだけだろうからねぇ。)

>>315
「システムレベルの信頼性」って？
正しく仕様に沿ってコーディングされているのか、
仕様が正しいのか、
の二つに帰着されると思うけど、
これって人の頭で考えないとどうしようもない部分だろう。

検証方法はこういうのとかあるけど、
http://www.ipsj.or.jp/members/Journal/Jpn/3605/article013.html
形式的仕様化の時点で人間の誤謬が混ざるのは避けられない。

見事に無意味な方向へ展開するねえ。
で、何がいいたいのかねぇ。俺の315を
支持してくれてると受け取っていい？
XPが詠う信頼性は枝葉末節なコードレベルだけってことで。

君の317と何も矛盾してないだろ？（笑

>俺は煽りだよ。（ｗ
>過去の発言見てわからんの？

もちろん分かってたよ。邪魔だから消えてくれ。

>>318
じゃあ質問だけ。
「システムレベルの信頼性」って？

つまらん。煽りとしてもマジとしても。
少なくともどっちかで楽しめそうなレスにしてくれ。

いいから消えろって。

>検証方法はこういうのとかあるけど、
>http://www.ipsj.or.jp/members/Journal/Jpn/3605/article013.html
>形式的仕様化の時点で人間の誤謬が混ざるのは避けられない。

会員じゃないんで見れませんでした。

>>304

Web アプリケーションは、やったことがないんで勘で書きますが、

>（HTTPUnit, WebUnit は受け入れテストで便利だと思うけど、これは時間が結構かかる。
>時間短縮のテクニックがあれが教えてほしい。）

受け入れテストは、ある程度なら（３〜４時間？）時間がかかってもいいんじゃないかな？

受け入れテスト専用のマシンを用意して、毎日自動実行する、って事例があったと
おもうけど、それじゃだめなのかな？

>>321
あんたのお眼鏡に適わないレスは書けないスレですか？

>>323
別にアブストラクトだけ流し読みしてもらえばいいけど。
ObTS 関連はこの人が論文公開してる。
http://kt-www.jaist.ac.jp/project/ObTS/publications/

>>325
>あんたのお眼鏡に適わないレスは書けないスレですか？

いや、単に俺がレスつけないだけだよ。（ｗ

>>325

精進が足りない所為で難しかった。

仕様記述言語って馴染みがないせいか、どうも無駄なことをやっているように
思えるなあ。

>>325
リンク先を読んでみた。

読んでみるとなかなか面白いね。ペトリネットは素人同然なんだが、
漠然と階層的に記述できるならもう少し実用的になるのかなぁ、と
思っていた。その意味で階層的記述の部分が面白かったんだけど、
うーん、階層的に記述できる＊だけ＊ではまだいまひとつなのかな、とも
思った。

これが感想。なにぶん素人の感想なんで見当違いだったら許してちょ。

＃リンクは非常に面白かったので感謝するが、いまひとつそこからキミが
＃何を主張したいのかが、＃読み取れないのだが。

>>327 ごめん、ちょっと割り込ませて
>>325 この5年間程、片山たんヲッチ忘れてますた。貴重なリンクありがとさん

少し実用的になるのかなぁ
↓
実用範囲が広がるのかな

に訂正しとこ。言葉尻をとらえて反応されては叶わんから。

XPの悪口を言われて脊髄反射したけど、後が続かなかったんじゃ。

不利になると不可知論に持ち込む人間はいやだね。

ん？仕様記述言語か。
うーむ、結局あれだ。
How to を記述するのが従来言語。ＸＰが通常使う言語も、この範疇。
Whatを記述するのが仕様記述言語。ＸＰのテストコードが該当する。

UnitTestでやってることって、両方から攻めましょう。
しかも、How to 言語だけで、Whatを記述する仕組みを作りましょう。
こういうことなんだよな。

ちなみにテストの正当性？

というより、ひとりのユーザに全権委任している時点で、
ＸＰプロセス内部では、そういう要求満たせないの明らかだろ？
要求するほうがスジ違い。必要なら外でやってくれ。
品質保証が本当に大事なら、ユーザ側でＱＡチームを作るべし。
その程度で終わる話だ。プロセス監視チームも必要ならどんどんやりな。
コストがかかるだけだろし、どんどんノロクなるだろうけど。

いずれにせよ、テストが足りない部分は迅速なリリースによる、
「エンドユーザの大量導入」による実稼動でそのソフトウェアの
バグは早急に発見される。

そういう意味じゃ、ＸＰはある程度我慢できる品質のものを
早く出すことが大事という文脈を狙ったプロセス。
無謬性要求があったりするならやめとけ。

ＸＰという価値観は、ChangeをKeepすることで、適応しつづけること。
それに意義を見出せない人間には、意味のない世界だ。

、

>>307
いいこと言ってるな。
だから、分析なんていい加減にやっても大丈夫なんだよ（苦笑）。
「違う」ーーーこう言われてから直せばよい。
これがＸＰスタイル。ＯＫ？（笑）。

>>304
Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので
HTTPを解析してイベントを起こすような作りにしておいて
イベントを直接起こしてテストすることで逃げる場合が多いです。

画面が正しく表示されているかとか、
JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
機能テストとしての役割はだいたい果たすかと。

受け入れテストに何時間もかけていいもんなのか。頻繁にリリースできないじゃん。

>>336

> Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので

受け入れテストというのは、機能が存在することの証明でもあるから、
これはやらないとうまくない。

特に、リンク切れとか、セッションの保持・開放とか、Web アプリの場合、何かしら
の変更が伴った際に発生する場合が多いから、何かツールを作ってでもやるべき。

（自動的にすべてのリンク辿るスクリプトとか）

>画面が正しく表示されているかとか、
>JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
>機能テストとしての役割はだいたい果たすかと。

UnitTestならそれでもいいですが、受け入れテストではHTTP越しのも
入れないとまずいでしょ。

>受け入れテストに何時間もかけていいもんなのか。頻繁にリリースできないじゃん。

XPでのリリース周期は1ヶ月〜3ヶ月。
しかも、UnitTestとは異なり、常に100％通らなければならないものではない。

1日1回実行可能なら十分な速さだと思うけど。

>>334
>
>要求するほうがスジ違い。必要なら外でやってくれ。
>品質保証が本当に大事なら、ユーザ側でＱＡチームを作るべし。
>その程度で終わる話だ。プロセス監視チームも必要ならどんどんやりな。

そうそう。結局XPでは無理だからXPの外側でやるんだよね。

XPは「俺たちの責任はこの範囲だから、これ以上の責任はユーザーさんが
もってね」ってことだよね。（間違ってないだろ？ｗ）

>いずれにせよ、テストが足りない部分は迅速なリリースによる、
>「エンドユーザの大量導入」による実稼動でそのソフトウェアの
>バグは早急に発見される。

実稼動でデバッグってことだね。（ｗ


そんなのけしからん、なんて無粋なこといわないけど、その分、開発費は安くして
もらわないとね。半額ぐらいなら、結構割に合うと思うよ。（ｗ

>>335
>いいこと言ってるな。
>だから、分析なんていい加減にやっても大丈夫なんだよ（苦笑）。
>「違う」ーーーこう言われてから直せばよい。
>これがＸＰスタイル。ＯＫ？（笑）。

「違う」という主体は誰なんだい？
そしてその人はなぜ「違う」と分かる？
分析するからだろう？
でなけりゃフィーリングや神秘的な力で分かるんだろうね。

>>336
>Webアプリの場合HTTP越しだと書くにしろ実行するにしろテストが面倒なので
>HTTPを解析してイベントを起こすような作りにしておいて
>イベントを直接起こしてテストすることで逃げる場合が多いです。
>
>画面が正しく表示されているかとか、
>JavaScriptがちゃんと動くかとかのテストには全然ならないですが、
>機能テストとしての役割はだいたい果たすかと。

IEのバージョンの違いとかで微妙に振る舞いが異なる部分も、
テストが難しいよね。

>そんなのけしからん、なんて無粋なこといわないけど、その分、開発費は安くして
>もらわないとね。半額ぐらいなら、結構割に合うと思うよ。（ｗ

くだらん。

いやいや現実的な話だよ。

＞>いずれにせよ、テストが足りない部分は迅速なリリースによる、
＞>「エンドユーザの大量導入」による実稼動でそのソフトウェアの
＞>バグは早急に発見される。

テストが『いいかげん』な分、顧客はそのコストを負担するんだから、
開発会社に払う金は減らさないとね。

それに年次決算とか滅多に実行されない処理は実稼動で改良なんてのは
無理だと思うけどね。トラブルからの回復テストとか、どれもこれも
人手がかかるテストばかりだよ。

高負荷時のテストも、シミュレートだけじゃ予想外のトラブルが起こる可能性が
あるから、結局実稼動と同じように実際に人手を使ってテストしないとね。
「予想」は外れるからね。（ｗ

>>341
でも生産量が倍以上違うからねぇ。
別に同程度以上の値段でＯＫだと思うよ。
短納期でもすぐ作っちゃうし、特急料金対応なんでね。

そういや半年プロジェクトの話続けるけど、
一人でやるのが正しいわけだけど、
病気したらどうするんだろうね？
ＸＰはこういうところの対応も完璧。

ところで、ちゃんと違約金払う契約にしてる？
してるならいいけど、してないなら
ＸＰと結局は大した差ないでしょ。
いくら手続きが完璧でも、実質が伴ってないってやつ？

結局ねぇ、ソフト会社にそこまでのリスク負わせる話はありえないし、
負わせたところで、つぶれられたら一緒。金は取れないんだから。

にしても、君ってオープンソースも認めてないんだね。
それとも認めてる？
認めてるならＸＰの狙ってる品質は、オープンソース並だよ。

>>338
> （自動的にすべてのリンク辿るスクリプトとか）

それができればいいんだけど、POST とか Session とか、
<input type=button onClick="goto_nextpage()"> とか、
難題が多くてねぇ。

>>336
> HTTPを解析してイベントを起こすような作りにしておいて
> イベントを直接起こしてテストすることで逃げる場合が多いです。

できるだけそういうふうにしてるけど、うちは注文画面に
入力して、DB に突っ込むだけみたいな感じなので、Bean と
DB 投入のテストしかできないんだよな。

>>292
> 今のところこういった部分は自動化ツールも使うけど、最終的には人手に
> 頼ってる。
自動化ツールの名前を教えて。それとも、自動化ツールを作るってこと?

＞カイロ

くだらん。
何度同じ話を繰り返せば気が済むんだ。
少しはXP本でも読んでから批判しろって。

>>349
だから放置しろって。

>>347
>でも生産量が倍以上違うからねぇ。
>別に同程度以上の値段でＯＫだと思うよ。
>短納期でもすぐ作っちゃうし、特急料金対応なんでね。

んーまあこの辺は内容が違うからなかなか比較しにくいけどね。
顧客側が行うテストなんだか評価なんだかどう呼べばいいのか
分からんが、そういうことにかかるコスト分は、当然予算から
割かれるから、開発会社に回せる金は減ると思うよ。しかも

顧客側にとってはそういうものの専門家ではないのだから、効率が
悪い分、コストはよけいにかかるかと。

ま、業務については専門分野だから有利だろうけど、それは機能の
評価とか取捨選択面であって、安定性や機能障害の評価には無力
だと思うよ。

>そういや半年プロジェクトの話続けるけど、
>一人でやるのが正しいわけだけど、
>病気したらどうするんだろうね？

ん？俺は一人でやるのが正しいとは言ってないよ。念のため言っとくけど。

>ＸＰはこういうところの対応も完璧。

ソースの共有が守られていればだよね。だから前スレとかでその辺がちゃんと
守られているのか、って小一時間問い詰めてたんだけど（ｗ、効率を考えて
ればある程度特定の部分が特定の人に集中するのもやむなし、って意見が
あったと記憶してるけど？

>ところで、ちゃんと違約金払う契約にしてる？
>してるならいいけど、してないなら
>ＸＰと結局は大した差ないでしょ。
>いくら手続きが完璧でも、実質が伴ってないってやつ？

金額に応じて行うよ。請求する立場でも請求される立場でも、
いろいろ考えて。実際そういう話になることもあるね。いやだけど。
ただ、請求する立場で言えば、相手が小規模な会社には、現金は
請求できないね。よほどのことがない限り。（よほどのことってのは
明らかに悪質な場合ぐらいだ。）

相手の会社の打撃が大きすぎるから。ソフトを作ってもらうのが目的
だから、ソフトの代わりに金を取り返してもね。相手が
つぶれちゃったら自業自得なんていってられないし。

>結局ねぇ、ソフト会社にそこまでのリスク負わせる話はありえないし、
>負わせたところで、つぶれられたら一緒。金は取れないんだから。

そのとおりだよ。金は取り返せないけど、ひどいケースでは
なんらかのペナルティは負ってもらうだろうね。信頼できるところに
重要な仕事を回すってのは当然だよね。自分たちも顧客からそう
評価されてるんだから。

>にしても、君ってオープンソースも認めてないんだね。
>それとも認めてる？
>認めてるならＸＰの狙ってる品質は、オープンソース並だよ。

レベルによるね。今日全く認めないんじゃサーバーすら立ち上げられないジャン。
だからオープンソース並といわれても、ピンからキリまでのどの辺かが重要かと。

>>348
>> 今のところこういった部分は自動化ツールも使うけど、最終的には人手に
>> 頼ってる。
>自動化ツールの名前を教えて。それとも、自動化ツールを作るってこと?

表現が悪かった。君が望むようなツールは持っていない。ようするに
人手主体だよ。

人手でテストしてみて、特定の操作部分が高負荷に弱いとか割り出せれば、
その時個別に特定の操作を繰り返すようなツールを作ってさらに負荷をかけた
テストをすることはある。

>>349
>＞カイロ
>
>くだらん。
>何度同じ話を繰り返せば気が済むんだ。
>少しはXP本でも読んでから批判しろって。

キミは教科書の丸暗記的な反論しかできないのだろう？（ｗ

>>347
>ＸＰと結局は大した差ないでしょ。

だから俺はXPでも従来型でも信頼性も効率も、大差ないって言ってるんだけど（ｗ
顧客から見ればトータルのコストは減らない。開発会社の負担は減るだろう。
だからその分、開発会社に払う金は安くなるだろう、ってことだよ。

何もXPの利点をすべて否定するわけじゃないよ。高い金もらって不毛な
仕事をするより、相応の金をもらって楽しくやる、ってのはいかにも開発者
好みだと思うけどね。そりゃ金は欲しいだろうけど（ｗ

>キミは教科書の丸暗記的な反論しかできないのだろう？（ｗ

教科書も読まずに反論するやつにはそれで十分だろ？（ｗ

他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう？

名前

単に言い換えただけだし

構造化技法で新しいことはなんでしょう？
OOPで新しいことはなんでしょう？
AOP新しいことはなんでしょう？

XPに新規性がないことが分っただけで十分です

さようなら

>>355
ずばり形式的手法の否定では？（ｗ
言い換えれば、メタ形式化だね。

その意味ではCMMレベル5もいわばメタ形式化だからXPと同じだ。
と言ってみるテスト。（ｗ

>>354
相手して欲しければ、中身のあること書きな。笑

>相手して欲しければ、

相手してるじゃん（ｗ

>>359
ごめん。メタ形式化が良く分からない。
形式的手法の否定だと、ほとんどの方法論は開発プロセスに形式的手法を採り入れていないが、
否定というのは採り入れていないという意味ではないの？

げ、マジレスがきた。悪い。言葉遊びだったんだ。すまん。申し訳ない。

>他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう？

焦点を当てているのが生成物（プロダクツ)でも生成方法（プロセス）でもなく、
生成者（開発者）という点では。

---そこそこマジレス。

bye

XP信者って厨房ばっかだなー

そろそろブームも下火だね。

厨房にウケがいいのは事実だろうね。

>>355-359
355はテスト技法、方法論、形式的手法をひとくくりにしてる段階で何も分かってないと思われ。

こいつ何が言いたいんだ？

「修正も変更の一種です。」にはﾜﾗﾀ

------------------------------
>
>> 欠陥が多いとXPのように変更を繰り返す
>> と欠陥が欠陥を生んで収拾がつかなくなるおそれがあります。
>
>それを回避するためのテストでは？

はい。ですから、収拾がつかなくなることを防ぐため、欠陥をある程度
以下に押さえ込んでおけるようにテストするわけです。XPにおけるユニット
テストは、欠陥を虱潰しに捜して積極的に欠陥を減らすようなものでは、
通常ありません。


>欠陥が欠陥を生むのはむしろ
>
>> 信頼性を高めるためには、可能な限りソフトウェアを変更しないように
>> すべきであり
>
>という従来の考え方だと思います。

ソフトウェアを変更しなければ欠陥は増えません（減りもしませんけど）。

従来の考え方は、ソフトウェアを変更しないようにするために、仕様変更や
リファクタリングをせずにすむようなソフトウェアを開発するということ
であって、仕様変更やリファクタリングがさけられないソフトウェアを
開発しておいて仕様変更やリファクタリングをしないということでは
ありません。

しかし、仕様変更やリファクタリングをせずにすむようなソフトウェアの
ソフトウェアの開発は不可能と言ってもいいほど困難ですし、コストも
多大になります。ですから、変更を減らすのではなく、変更によって欠陥を
作り込む確率を減らすという考え方をXPなどは取り入れたのです。

>変更しないことで信頼性を高めるという主張は、変更前のコードの信頼性が十分
>高いことを前提としています。ところがソフトウェア開発においてはある時点で
>の信頼性の高さはあまり意味がありません。顧客の要求により突然仕様が変更さ
>れれば、変更前の仕様を前提とした信頼性の高さは無意味です。

そんなことはありません。欠陥の多い、わかりにくいソフトウェアの仕様を
変更するくらいなら、最初から作り直した方がましとはよく言われることです。

>　　　　　　　　　　　　　　　　　　　　　　　　　　　　　従来の考え方で
>は、仕様変更によって意味を失ったコードを無理矢理延命させるために場当たり
>的な修正を加え、その結果として潜在的欠陥が累積されるというパターンが度々
>見られます。

修正も変更の一種です。変更しているのだから欠陥がふえても不思議では
ありません。


片岡さんが批判しているのは、従来の信頼性を重視したソフトウェア開発手法
ではなく、従来の信頼性を＊軽視＊したソフトウェア開発手法のように
見えます。

全体的に支離滅裂だけれど、特にこの辺が激しいね。

>>変更しないことで信頼性を高めるという主張は、変更前のコードの信頼性が十分
>>高いことを前提としています。ところがソフトウェア開発においてはある時点で
>>の信頼性の高さはあまり意味がありません。顧客の要求により突然仕様が変更さ
>>れれば、変更前の仕様を前提とした信頼性の高さは無意味です。
>
>そんなことはありません。欠陥の多い、わかりにくいソフトウェアの仕様を
>変更するくらいなら、最初から作り直した方がましとはよく言われることです。

作り直すなら尚のこと変更前の信頼性の高さは無意味だから、反論にさえなってない。
すごく分かりやすい『議論のための議論』の例だ。

＞他のテスト技法、方法論、形式的手法に比べてXPで新しいことはなんでしょう？

こういう質問に譬え話で答えて見るテスト。

かつてOOが登場した時、開発者達は笑って言ったものでした。
「俺はソース単位でグローバル変数を管理してカプセル化していたよ。」
「俺はポインタを使って処理を振り分けていた。これはまさに多態性じゃないか。」
「俺だって継承を取り入れたプログラミングをしていたぞ。」
「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」

そしてXPと呼ばれる開発手法が登場した時、開発者達は笑って言っています。
「俺は昔からテストコードを書いていたよ。」
「俺は後輩と組になってコードの保守をしていた。これはまさにペアプロじゃないか。」
「俺だってユーザにプロトタイプを提供して意見を聞いていたぞ。」
「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」

幸せそうな開発者達はさておいて、逆にみなさんに質問してみましょう。

みなさんは昔から、デフォルトでOOを実践していましたか？
開発途上で結果的にOO的な状況になっていたことを思い出して、それを本当のOO開発と混同していませんか？

みなさんは昔から、デフォルトでXPを実践していましたか？
開発途上で結果的にXP的な状況になっていたことを思い出して、それを本当のXP開発と混同していませんか？

ごめんよ。書き方まずった。XPを否定しているわけじゃないんだ。
次の点を簡潔に知りたいんだ。

他の手法と差別化して主張しているのはどこか？

どういう技法などを改良して採り入れたのか？

>>372-373

>「「「なんだ。結局従来の方法と同じじゃないか。バカらしい。」」」

と思うのはさすがにアホだけれど、、

>開発途上で結果的にOO的な状況になっていたことを思い出して、それを本当のOO開発と混同していませんか？

「結果的にOO的な状況になる」と「本当のOO開発」はどの程度違うのかね。
延長にはあるし、個々にOOを再発見しなくてよいってだけって気もする。

しかし、鶴亀算や旅人算を駆使して問題を解くのと一次方程式を立てて解くのだと、
結果的に同じことをやっているにもかかわらず、後者はずっと整理され一般化されているから、
前者の延長ではたどり着けないような領域にまで展開可能だ。

結局ばかばかしいかばかばかしくないかは、従来と同じ土俵で比較していては、
判断できないってことだと思うけどね。従来の方法では扱いきれないものを
どれくらいうまく扱えるかって点に尽きる。

>>374
Pert1から順に過去ログ読むのをお勧めする。
たぶん休日使って読むくらいの価値はアル。

>>374

> 次の点を簡潔に知りたいんだ。

従来の方法論はそこそこ知ってるようだけど、キミはそれらの「次の点」を
簡潔に説明できるわけ？見本を見せてくれれば、それにそって説明できるかもね。

>他の手法と差別化して主張しているのはどこか？

それはやっぱりテスティングとリファクタリングでしょう。
ここまで極端に、この２つを取り入れている手法を他には無いでしょう。

>どういう技法などを改良して採り入れたのか？

これはXPのプラクティスが全部そうでしょう。
逆にいえば、その他の事柄は、（プラクティスほどは）重要視していない、
というところが特徴です。

よく誤解されているのではないかと思うんですが、XPでのドキュメント不要論は
「ドキュメントを書かない」というプラクティスがあるわけではないので、重要視さ
れているわけではないのです。

ただ、「変化ヲ抱擁スル」こととXPのプラクティスを実践することによって、
ドキュメントを作成/メンテナンスすることが非常に難しくなってしまうだけ
なのです。

例えば、たった一つの機能を追加するのに、１０ものドキュメントを修正しなけれ
ばならないとすると、手を出しかねてしまいますし、物理的に短期リリースも
不可能となってしまうでしょう。

だから、コミュニケーションに役に立ち、自立テストによって正当性を検証でき、
追加/修正が容易なドキュメント作成/維持方法があれば、XP的にドキュメント
を不要と考える理由はなにも無いはずです。

そして、XPではソースコード/テストコードをドキュメントと同一視することで
それを実現しているのです。

>>370-371
「従来の信頼性を＊軽視＊したソフトウェア開発手法」なんてものがあるのかねぇ。
どれもこれも、手法としては、うんざりするくらい重視してると思うけどね。

「従来の信頼性を重視したソフトウェア開発手法」とは何を念頭において言ってるのか
聞いてみたいね。（ｗ

いくら手法が立派でも、それにそって実際に運用しきれなきゃね。

そこから運用できるレベルまで手法の方を軽量化しましょう、って考えるか、
運用できるように組織を充実させましょう、ちゃんと運用されているかどうか
チェックする組織も作りましょう、って考えるか、だね。

> そこから運用できるレベルまで手法の方を軽量化しましょう、って考えるか、
> 運用できるように組織を充実させましょう、ちゃんと運用されているかどうか
> チェックする組織も作りましょう、って考えるか

まんまCMMやね

チェックしてもしちゃんと運用されていなければ、組織自体も改良していきましょう、
ってのがCMM5かな。（ｗ

>>379
開発手法の運用を語る人にしては、文章がちょっと支離滅裂ぎみだと思う。
レス番も違うみたいだし。

>>382
＞レス番号も違うみたいだし

藁

>>382
現実は支離滅裂なもんだよ。
ご本だけ読んでてもね。
＞ぼくちゃん。

>>282
ところでさぁ､part1の頃から思ってたんだけど､
いつも少し前レスの煽り文句をそのまま真似て
つかってる人がいるなぁと思ってるんだけど､
みんな君なのかな？（ｗ
いや、悪くはないんだけどね。何事も猿真似から始まるんだからね。

残念だけど君がチットモ意味あることを書いてくれないから､
俺もこんなレスしかつけてあげられないんだ｡
ごめんよ｡

すみません。
そうなんです。

ばれました？

>>378
だね。そういう意味では、
javadocやdoxygenによる自動生成ドキュメントはＸＰでは、
多少の負荷にしかならないから、この程度はやるんだよね。

ついでに、自動生成テストケース結果レポート作成が今はブームで、
これのやり方がある程度、普及すれば、顧客納品ドキュメントの体裁
ぐらいは整えられる。

>>386
君は誰やねん（ｗ

おい、カイロに絡んでる厨、ウゼエ
お前がこのスレを荒らしてんだぞ。うせろ！

>>385
ﾜﾗﾀ
もしかしてHAMIかもな。

なんでUnitTestってテストされるクラスとは別にテストするクラスを作るの？
テストされるクラス自体にテストメソッドをつくり自己テストにしたほうが
Private変数のテストも出来るし、いいような気がするんだけど。

>>391
リリースビルド時に簡単にテストメソッドだけ削除できることと
元の継承ツリーとは別にTestCaseクラスを継承できれば
(つまり多重継承できる)それでもいいけど
両方可能な言語はそれほど多くない。

>>391

自己テストはリファクタリングの妨げになりやすいのでXP的には却下なのれす。
実装をテストするのではなくインターフェイスをテストするのれす。

やってみなきゃわからないでしょう？
やる前からあーだこーだ言ってると、
それ以上進まないですよね？
ただ僕はXPを知ってほしい。
僕はね。XPで本当に幸せになれたんです。
昔は、僕もあなたと同じ考えでした。
でもまぁ僕の話なんだけども、ウォーターフォールで仕様変更に悩まされてて、
先生にXPを信じてやってみなさいって言われたんです。
で、それから一生懸命ね。XPを勉強して
信心したらね。ｽｯﾄ頭の中が整理されて、バグもなくなったんです。
なんでもっと早くXPを習わなかったのかなぁと今は思ってます。
なんで僕がね。こんなことを言うかと言うと、
あなたに幸せになって欲しいからなんです。
だから一度、XPの集会がや日曜にやってますんで、
一度でいいですから来てみてください。
そしたらXPについて今の誤ったイメージが間違っていたと
思うようになると思います。もしXPがやっぱりだめだと
思ったらそれは構いせん。それは自由です。
でも幸せになれないでしょう。一度集会に顔出してみてください。

>>394

出すタイミングが1週間は遅いね。

どこを立て読みするんですか？

>>394
駅前とかで勧誘するといいんじゃない？

ごめん。
394は俺が書きました。
っていうか、戦場OOスレからコピペ＆置換しただけなんだけど、なんで皆そんなに
余裕の無いレスばっかりなの？

だからカイロなんかになめられる。
と言ってみるテスト。

>>398
出来がよすぎるんだよ。しゃれになってない。

>>398

いや、そのネタはもう飽きたから。

>>400

余裕の無いレスの典型だな（ｗ

相変わらず何も根拠を挙げないただの独りよがりの意見だね。
---------------------
XPは、ソフトウェア開発の目的をまがりなりにも意識していますが、
CMMはほとんど意識していません。目的を意識せずに戦略は立てられません。
そういう意味で、XPの方がまだしも戦略的です。

戦略と戦術とでは、戦略の方が優先します。もし、XPとCMMとが対立したら、
XPを優先させるべきだというのが、私の考えです。

あーうっとうしい。
これだけ長い文章で意味のあることを何も書かないってのは特技かもしれない。
-----------------------------
目的は「提供」であって「開発」ではない。このことは、「開発」の効率
向上が必ずしも「提供」という目的の達成に貢献しないことを示しています。
それどころか、「開発」の効率向上は「提供」という目的の達成の障害
となるおそれすらあります。

このことは意外かもしれませんが、理解しづらいことではありません。
例えば、フルマラソンにおけるゴールタイムと10kmまでの区間タイムを
考えてみましょう。区間タイムが速ければ速いほどゴールタイムも速くなる
でしょうか。もちろん、そんなことはありません。区間タイムの向上は他の
区間のタイムの低下につながり、ある程度以上区間タイムを向上させれば
全体としてのタイムの低下につながります。スタミナは有限なので適切な
配分が重要なのです。

企業における、ヒト、モノ、カネといったリソースも有限です。
ある部分にリソースを投入するということは、他の部分に投入できたはずの
リソースを奪うことでもあります。開発のために、開発の効率向上のために
リソースを投入するということは、他のもっとリソースを投入すべきだった
かもしれない箇所からリソースを奪うことでもあるのです。
部分的な効率向上は、全体的な効率の低下につながる危険性が多分にある
のです。

細かいことを二つほど言うと。
「最終的」ということは、中間的な目的とかもあるのでしょうか。
ソフトウェア開発において、重要度の高い目的、重要度の低い目的、
長期的な目的、短期的な目的というような区別はできても、最終的な
目的、中間的な目的というような区別は無いと思います。

「お客様が提示した要求への回答（ソリューション）を提供する」
には、「満足」と「価格」の二つの条件が抜けています。
これらを無視できるなら目的の達成は誰でもできることでしょう。


>ＣＭＭの場合、経営側の責任（契約や要件定義、品質管理など）に重
>点を置いているため、ＸＰよりも経営側の視点に近い気がします。
>そういった意味では、ＣＭＭの方が戦略的かもしれません。

トップが下す判断が常に戦略的とは限りません。旧日本軍など典型的な例
でしょう。戦略的に考えることは難しく、特に日本人は苦手のようです。
戦略的ではなく、戦術的に考えているケースは多いです。

これも何を言ってるんだか。
質問者はこの程度の答えを期待していると思っているんだか。
--------------------------------------
>・ドキュメントについて
>　XPの基本方針としてドキュメント作成等の上流工程より、「テスト」を中心と
>　した開発という事が謳われています。確かに開発時はこれで効率が良いとは思
>　いますが、リリース後の保守において、ソースしか見るものがないというのは
>　、保守担当者にとっても大変効率の悪いものとなりがちです。XPでのドキュメ
>　ントの重要度はどう考えられているのでしょうか。

XPでは、製品としてのドキュメントまでは否定していないです。

　
>・オンサイト顧客について
>　プログラマからの質問にその場で答えると定義されていますが、質問内容を文
>　書として残さなければ、あとで「言った、言わない」の押し問答にならないの
>　でしょうか（更にその場での回答が必ずしも適切な回答とはならない事も多々
>　あると思う）

食い違いが生じたら、次のイテレーションで修正すればいいことでは。
誰の責任とか、不毛な議論をするよりさっさと修正する方がXP的でしょう。

「変化ヲ抱擁セヨ」の「変化」には、ミスの修正による「変化」も入っている
と思っています。

人口無能？
---------------------------
>気持ちはXP on CMM

私は、CMM on XP というところでしょうか。
# で、のらない部分は切り捨てる。

>そして、ＸＰは戦略的かどうかも問題でなく
>ＸＰを戦術と位置づけることで
>「戦略は経営陣に従うが戦術は現場に委譲すべきだ」。
>と議論を展開で、導入しやすいだろうなと思っただけです。

XPが戦略的だとは思っていません。CMMはより戦略的でないと
思っているだけです。


>現場が戦略論を打ち上げたら経営陣は拒絶を示しませんか。

トップが誤った戦略を打ち出したら現場は反対せざるを得ません。

このスレ、無能ばっかりだ…

面白くない。

無能？苦悩？久能？

>>406
ｵﾏｴﾓﾅｰ

>>406
HAMAIタンいらっしゃい

カイロうざい

この人はCMMをわかってないな。
CMMレヴェル5のどこが「あるきまったプロセス」なんだ？
-----------------------------------------
>> > XPは、ソフトウェア開発の目的をまがりなりにも意識していますが、
>> > CMMはほとんど意識していません。目的を意識せずに戦略は立てられません。
>> > そういう意味で、XPの方がまだしも戦略的です。
>> >
>> > 戦略と戦術とでは、戦略の方が優先します。もし、XPとCMMとが対立したら、
>> > XPを優先させるべきだというのが、私の考えです。
>>
>> 「開発の目的」とはなにか？が重要になると思います。
>> ＣＭＭでもＸＰでも、最終的には「お客様が提示した要求への回答
>> （ソリューション）を提供する」ことが目的だと思いますが、いかが
>> でしょうか？当然、同時に自社も儲けるのが前提になりますが。
>
>CMM と XP では観点が違うような気がします。CMM は組織として
>のソフトウェア開発力の成熟度を見ているし、XP は個々の具体
>的なソフトウェア開発のプロセスをどう最適な物にするかだと
>思います。そう言う意味では CMM の方が XP よりはより大局的
>だとは思います。戦略と戦術ですが、これは対象となる目的の規
>模によるでしょうね。

目的を達成しやすいように条件を整えるのが戦略です。
ソフトウェア開発の目的は端的に言えば、「顧客の満足する製品やサービスを
顧客と提供側双方にとって妥当な価格で提供する」といったところでしょう。

開発は提供するための複数ある手段のさらにその一部にすぎません。開発
という手段に固執しているCMMは、大局的でも戦略的でも無いです。
XPも開発に固執している点は同じですが、顧客の要求を中心にすえている
という点でCMMよりははるかにましです。[XP-jp:03278]で述べられている
ような顧客の要求を断ることは、コストや納期に無理がある、法律や倫理に
反している、というような場合以外、行うべきではありません。CMMの成熟度
レベルを維持するために顧客の要求を断るということがCMMの矛盾を
示しています。


>＃実際にインドの CMM レベル５企業の組み込みソフトの品質は
>＃CMM レベル２相当の日本の企業の組み込みソフトに比べて実は
>＃低かったと言う報告を見た記憶がありますし。・・・

ワインバーグは、レベルの違いではなく文化の違いに過ぎず優劣ではない、
と言っていたはずです。

開発物に対する要求だけでなく、開発プロセスに対する要求もプロジェクト
ごとに異なります。それどころか、プロジェクトの期間中にさえ変化します。
あるきまったプロセスでのりきろうとするCMMの考え方に無理があります。
スポーツなら、試合開始直後、終盤勝っている時、終盤負けている時、各々
別のやり方で戦うはずです。

なんかXPってよくわかりません。幼稚園児でも理解できるように説明してください。

>>413
俺は幼稚園児じゃないので幼稚園児が理解できるかどうか知りません。

>>414

ソフトウェア＝泥だんご
のメタファで何とかならないか？

最初から大きくて割れない泥だんごを目指すんではなくて、
小さな泥だんごを作ってみて、落として割れなかったらもう少し泥を付け足す。
付け足したらまた落として割れないことを確認する。
だんだんひび割れなどが見えてくるので、そこには水をかけてならしたりする。

無意味なレスつけるのが趣味なんだろうな。
きっとそうだよ。それ以外ないよね。
ーーーーーーーーーーーーーーーーーー
濱井です。引用の順番を入れ替えています。
2002/07/09 20:57:21 +0900に[email protected]さんが送られた
メールに関する返信です。

>> >ＣＭＭの場合、経営側の責任（契約や要件定義、品質管理など）に重
>> >点を置いているため、ＸＰよりも経営側の視点に近い気がします。
>> >そういった意味では、ＣＭＭの方が戦略的かもしれません。
>>
>> トップが下す判断が常に戦略的とは限りません。旧日本軍など典型的な例
>> でしょう。戦略的に考えることは難しく、特に日本人は苦手のようです。
>> 戦略的ではなく、戦術的に考えているケースは多いです。
>
>そこが問題ですよね。
>ＸＰを導入すれば、この辺も改善されていくのでしょうか？

ある程度の改善は期待してもいいと思います。ただ、XPが特効薬になるとは
考えない方がいいでしょう。「銀の弾丸」はまだ見つかっていません。


>> 「お客様が提示した要求への回答（ソリューション）を提供する」
>> には、「満足」と「価格」の二つの条件が抜けています。
>> これらを無視できるなら目的の達成は誰でもできることでしょう。
>
>顧客満足、価格、納期などは、すべて提供する「回答」に含まれる
>ものだと思ってます。これらを無視するつもりはありません。
>＃ というより、無視できないでしょう。実際。

要求内容と回答内容が１対１に決まるようなものではないので、「回答」
だけでは、意図が読みとれません。

人は、他人の書いた文章をそう注意深くは読んでいないものです。
ましてや、記述者の意図通りに読みとってくれるとは思わない方がいいです。

うちもXPだなんだってやってるが、XPチームとかでやってるやつらは２期連続デスマーチ・大赤字だ。
どんどん人員を増加しているしな。他のプロジェクト潰してでもだ。おかげでボーナスも遅れてる。
俺はXPなんでどうでもいいから詳しくは知らないが、
うちのバカどもが学習できないのか、XPが完璧な人間の集まりでしかできないのかよくわからん。
こういう会社はXPやめたほうがいいですか？
おまけにJava以外の開発やりたくねーってよ！カス共め。

人のレベルを上げるか仕事のレベルを落とせ。

つーか、ぜひ詳細レポートきぼんぬ。
今の時点で人数ってどれくらいなの？
XPでなけりゃうまくいきそうだった？

移転age

>>418
>どんどん人員を増加している

もしかしてすでに10人を超えてるとか？
だったらチームのリーダーはXPを理解してない可能性大だな。

>どんどん人員を増加している

それを人はXPではなくデスマーチと呼ぶ

XP=コントロールされたデスマーチ状態
↓
正真正銘のデスマーチ状態

シームレスでスケーラブルですな（ｗ

40時間労働の制限と同様に人員増加の制限も必要。

クラウゼウィッツの「戦争論」に、こんな言葉があります。
・巧妙な戦法は、時の流れとともに、より簡単な戦法に道を譲らねばならない
・各時代には、それぞれの時代に適応した独自の戦争理論がある

ＸＰとウォーターフォールの両方とも経験がある方の「脳内感覚」でいいので、
・ＸＰとウォーターフォールではどちらが「簡単か」
・ＸＰとウォーターフォールではどちらが「時代に適応しているか」
教えていただけないでしょうか・・

>>425
HAMAIタンですか？

>>426

濱井本人でなくてもかなり似通った精神の持ち主だろうな。
具体的経験が乏しいもんだから自分の知識からメタファをひねり出して議論に参加
したつもりになってるんだろう。
425が社会人でこの業界に身を置いてるならウォーターフォールの経験が無いなん
て有りえないし、XPの内容を少しでも実践してみればウォーターフォールとは対象
としているプロジェクトの規模も目指すところもかなり異なっている事ぐらいすぐ
に気が付くはずだし、少なくとも、

>ＸＰとウォーターフォールではどちらが「簡単か」

なんてバカな問いは出てこないだろうな。

結論はHAMAIタンが馬鹿ってことでいいですか？

ＸＰやってます・・・。
チームメンバーは理解してくれてますがヽ、チーム外の人にはわかってもらえないです。
XPは派手すぎて目立ちゃうくせに経験してない人に説明するには難しすぎます。
はー。ただの愚痴でした。

XPは戦術、CMMは戦略だと思うのだが。ﾏｧｲｲﾔ

>>429
実際に経験してみないと、あの感覚はわかんないね＞XP

デスマーチなら常に経験してますが何か？

ペアプロが一番不評です。
やっぱり無駄に見えるようです。
ベつにXPじゃなくても本当に良いチームはコミュ二ケーションとれてるから自然にペアプロ状態になるんだけど、そのへんの説得がとても大変です。
皆さんは上司の許可をどうやって得たのですか。

>>433

「XP検証編」読みなされ。（水色のやつじゃよ）
ペアプロのコストを検証した論文が載っとるぞ。
（但し、図表の説明文に誤訳が有るがの。）

>>434
ありがとうございます。
本はもってるので読んでみます。
んー。でも問題は簡単ではないですよね。いかに優れていても周りの人に納得してもらわないといけないので・・・。
いきなり論文なんかもちだしたら「儲ける気あるんかー！」と言われそうです。
やっぱり上司とコツコツとコミュ二ケーションして「よっしゃ、やってみい。」って言わせるのが近道ですよね。

>>435
>いきなり論文なんかもちだしたら

人を説得したかったらネタ帳は見せてはいけない。
論文を咀嚼して日常会話の単語で語れるようになるべし。
まあ、相手が権威主義者の場合は論文でハッタリかますのも一手ではあるが。

そうですね。
うまく租借してペアプロ効果を説明してみます。
話が脱線しますが、プログラマのあつかいが低い会社なので（ＰＭ、ＳＥはえらい）、XPというだけで､プログラムにこだわんなよといわれそうで不安です。
日本でプログラマの待遇の良い所があれば良いのですが。
？？？ケン卜・べックはプログラマなんでしょうかね？？？

>？？？ケン卜・べックはプログラマなんでしょうかね？？？
eXtreme Programmerです。もちろん。

限りなく無意味な一般論しかいえないやつ
＞「大本をおろそかにしていた〜」
おろそかにしていたことがなんだったのかを看破できた者にのみ許される
言葉なんだが。
--------------------------------------
> 水を差すことになるかもしれませんが、カバレッジ率を重視しすぎない方が
> いいかもしれません。
>
> マイヤーズの本にも書かれていますが、カバレッジ率100%でも見つからない
> 種類の欠陥があることがわかっています。あるべき処理が抜けていると
> いうようなケースは、カバレッジ率は役に立ちません。CodeRedやNimdaで
> 悪用されたバッファオーバーフローや、最近ウェブサイトで次々と
> 見つかっているクロスサイトスクリプティング脆弱性などはその例です。
>
> このように仕様そのものに欠陥がある、仕様そのものが考慮不足である
> というような例は珍しくありません。

> ある点ばかり重視していると、それ以外のところが疎かになりがちです。
> カバレッジ率ばかり重視していると、それでは見つからない欠陥を見逃す
> リスクが高くなります。
> そもそも、品質は信頼性だけではありません。[XP-jp:02842]でも
> ふれられているように、デマルコが「ゆとりの法則」の「第16章 品質管理」
> において、品質向上プログラムが品質低下プログラムになっていると批判
> しています。やっていることが欠陥数の削減だけで、品質全体としてはむしろ
> 低下しているということです。
>
> カバレッジ率が無意味だとは思いませんが、カバレッジ率が重要か否かは
> 一概には言えないでしょう。

> 「品質」とは何か、「定量的」とはどういうことなのか、といった大本の問題
> をソフトウェア工学は疎かにしていたように思います。

HAMAIﾀﾝは「人生とは何か」といった大本の問題を考えてほしいYO!
その答えが出るまでほかの事を考えないでほしいYO!

hamaiってほんとうざいな

さすがにレベルの差にびびってHAMAIは引っ込んだと思われ

このスレにいた煽りのまねっこクンはやっぱHAMAIだな。

＞>> カバレッジ率が無意味だとは思いませんが、カバレッジ率が重要か否かは
＞>> 一概には言えないでしょう。
＞>
＞>ここはちょっと一般論として扱うのは大雑把なような気がします。
＞
＞「カバレッジ率」だけを取り出して、「ソフトウェア品質指標についての考察」
＞と大上段に構えていたので、「カバレッジ率」を重視し過ぎない方がいいと
＞述べたまでです。「カバレッジ率についての考察」であれば、そこまで
＞言わなかったかもしれません。

だれも大上段に構えてなどいないけどねぇ。HAMAIタンは日本語が読めないか、
ちょっとでも自分の考えに反する可能性のある話題は冷静な解釈ができない人なんだろうなぁ。

＞それは、CMMの過大評価のような。というか、ソフトウェア工学の過大評価と
＞言う方が適切かもしれません。
＞# ソフトウェア工学を「裸の王様の服」に喩えた「ソフトウェア職人気質」
＞# (29ページ)と私はほぼ同意見です。　

聞き飽きたんだけど。

＞>そもそもソフトウェア品質で重要なのは生産性だと思っています。
＞
＞生産性は品質ではないです。

ことばじりをとらえて毎度ご苦労さま。普通の人は適切に読みかえるけどねぇ。
よかったね。HAMAIタンにも揚げ足取りとはいえ、コメントをつけられる話題があって。
さびしかったんだね。

谷某もねぇ、いいたいことはわからないでもないが、その内容をその表現で発言したら、
こういう結果になるってことが予想できないのかねぇ。いいたいことがそもそも何も目新しいもんじゃないし。

作業の前に何をするか互いに説明しあう→バグが出たり、分からなくなったりしたら、口に出す→二人でさっさと解決する→はじめに戻る
OSや作業環境が違うためPCの共有は無理でした。しかたないので情報共有だけをやってます。

相変わらずことば遊びが好きだなぁ。
きっとこういうくだらない話題にしかついていけないんだろうな。
ーーーーーーーーーーーーーーーーーーーー
>> 品質は、直接的には顧客側にとってのみ重要な特性であり、生産性は、直接的
>> には開発者側にとってのみ重要な特性です。
>ソフトウェアの品質について顧客と開発者の観点が相違する部分があると思います。

「品質とは顧客が評価するものであり、開発者による品質評価とは暫定的な
代替に過ぎない」と私は考えています。

品質向上の目的は、顧客の評価を高めるためのもののはずです。開発者の自己
満足のためではないはずです。そう考えれば、「品質とは顧客が評価するもの」
ということになるはずです。

Javaを例にとると

宣伝に踊らされた顧客が導入
信者な開発者は自己満足
出来た製品の顧客の評価は低い
冷静な開発者は評価を修正

という具合に顧客の評価が開発者にフィードバックされます
もちろん「冷静な」開発者ならですが
出来た製品よりソースを眺めて満足するタイプは除きます

おい、おまいら
　　　　　　　　　　　＿＿＿　００　　　　　　　　／
｜＿＿　＿＿　　＿＿＿＿　　　　　　　　　／
｜ 　　　＿_｜　　　｜　　　＿＿＿＿　　／｜
｜＿＿　＿_｜ 　 ／　 　　　　　　　　　　 　｜　

を流行らすのじゃ！

参考スレッド 森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
http://comic.2ch.net/test/read.cgi/comic/1025843878/551-591

ここにさらされてるHAMAIってやつは、よほどのDQNらしな。

>>450

濱井ﾀﾝに興味を持ってもXPMLに参加しようとは思わない事。
直接見たら目が腐りますよ。

HAMAIがからむとどうしてこうレベルが下がるんだろうね

こいつは問題がはっきり解明できるまで、それに対して
何も議論すべきではないといいたいのかね。

あらかじめわかっていることだけを勉強する教科書教育の賜物だね。

---------------------------------

このメーリングリストメンバは、それこそ色々なドメインの
>ソフトウェア開発者がいて、開発環境も色々、役割も違うのに、
>ちょっと表現が一方的だったかな反省しています。
>数値の独り歩きの危険性などは、その通りだと思います。
>
>僕がカバレッジ率に期待するところを補足させてください。
>http://objectclub.esm.co.jp/eXtremeProgramming/
>からのリンクで日本科学技術連盟ホームページ内−
>「小規模・短納期プロジェクトにXPを導入する際の課題」
>という文章があるのですが、その中でXPは品質保証の面から
>課題があると指摘されています。

私はこの指摘にはうなずけません。

確かに、仕様に対する品質という点からすると、XPは従来の手法に比べて弱い
かもしれません。しかし、顧客の要求に対する品質という点からすると、
他の手法より優れているように思います。

ソフトウェアの真の品質＝仕様の品質×仕様に対するソフトウェアの品質

というような式でソフトウェアの品質は表せると思います。
「仕様の品質」という問題を無視して、「仕様に対するソフトウェアの品質」
だけを議論しているように思えます。
「数値の独り歩き」の一種だと思います。

数字の独り歩きを防ぐには代案を示すしかないんだけど、彼はそれをしないからね。

笑えるねぇ

水分子の構成要素は水素原子と酸素原子です。
水素原子と酸素原子は水分子ではないと思いますが。

ｸｽ
------------------------------------------

濱井です。
2002/08/08 16:24:19 +0900に[email protected]さんが送られた
メールに関する返信です。

>品質の構成要素は、
>・生産者
>・顧客
>・製品
>・仕様(納期も含まれる)

これらは、「性質・性能」ではないと思いますが。

>JISでは品質の定義を、
>「品物またはサービスが、使用目的を満たしているかどうかを
>決定するための評価の対象となる固有の性質・性能の全体。」

菊池さん自身の中で品質の定義が混乱しているように思います。

age

HAMAIなんざ、だれももう相手にしてねーからほっとけって

　　　　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 ∧,,∧ｸﾙｯ　／
　 _　ミ,,ﾟДﾟ彡_＜　　とりあえず、XPML(のHAMIﾀﾝ投稿)
.=| |=ﾐ 　　ミ=| |= ＼を読むのは辞めますた
　| | ﾐ＠　ミ　| | 　　 ￣￣￣￣￣￣￣￣￣￣￣￣￣
　| |　∪''∪　| |
　| |　　　　　 | |.

俺はこのスレもほとんど読まなくなったよ。
MLネタはマ板かMLでやれよヴァカ共が。

HAMAIタンおひさしぶり

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

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

くだらねぇ。文才もユーモアも無い人間がこんな文書いちゃいけないよ。
テクニカルライターなら中身で勝負しろよ。

似たような書き方をしたのがあったような。

> ・事前にテストの設計を行うので，自分がどんなプログラムを作るべきかがよく分かる
> 　やめてくれ。どんなプログラムを作るべきか分からないから，プログラミングは楽しいのだ。そのだいご味を奪うな。

激しくﾜﾗﾀ

（真島　馨＝日経ソフトウエア編集）
（真島　馨＝日経ソフトウエア編集）
（真島　馨＝日経ソフトウエア編集）
（真島　馨＝日経ソフトウエア編集）
（真島　馨＝日経ソフトウエア編集）
（真島　馨＝日経ソフトウエア編集）

これって、元ネタを辿れば、「本物のプログラマは・・・」になっちゃうんでしょうか？

　　 ＿＿＿＿＿＿＿＿＿＿＿＿＿
　／
　|　とりあえず、|>　皆様の評価を見る
　|　クリクしとけ。
　＼＿　＿＿＿＿＿＿＿＿＿＿＿＿
　　　　|/
　　 ∧,,∧
　　ミ,,ﾟДﾟﾐy━~~
　　 U　　 ﾐ　読者の反応に、カナリ　ﾜﾗｴﾀﾖ
　〜ﾐ　 　ﾐ
　　　Ｕ''Ｕ

ピアソンのページ見たら、XPの本がものすごく出てた。
未翻訳もかなりある。

あんなにたくさん読まなくちゃわからないのかなあ。
誰かおせーてください。

それと、日本でXPやってる人って、事実上Java屋さん？

>>468
なぜageた？

（>>465＝ドキュソ２ちゃんねらー)
（>>465＝ドキュソ２ちゃんねらー)
（>>465＝ドキュソ２ちゃんねらー)
（>>465＝ドキュソ２ちゃんねらー)
（>>465＝ドキュソ２ちゃんねらー)
（>>465＝ドキュソ２ちゃんねらー)

>>468
とりあえずピンク本(導入編)読んどけ。

「アジャイルソフトウェア開発」 良書だ。
とくに 「OO は戦場では必要なし」 スレの人に読んでもらいたい。

>>472
それってCockburnのやつ？邦訳ってあったっけ。

>>473
出てる。
http://www.cbook24.com/bm_detail.asp?sku=4894715791

>>474
ｻﾝｸｽｺ
原書で読んだんだが、割と読みやすい文章でこっちもお勧め。
ちなみに宮元武蔵の五輪書からたくさんの引用があるんだけど、微妙な
違和感がなんか面白い。

おまいら何かネタだせ。

>>476
MLの馬鹿が散々荒らしまわったスレなんて使えないから
すっぱりと次スレ立てて仕切りなおしてくれよ。

>>475
漏れはあの日本語訳に違和感感じまくりです。
原著で読めるようになりてえ。

今野さんが監訳に入ってもあの程度とは･･･。
やっぱ、長瀬&テクノロジックアートが絡むとだめだな。

>>478
今野が監訳に入っている本はくそ訳ではないとはいません
今までで最悪は某XML本
長瀬が関わった本は間違いなくくそ訳，売名行為が目的なので
仕方なし

ttp://www.geocities.co.jp/Technopolis/8931/#・エクストリームプログラミングの光と影〜XP%20or%20XoPの似非科学
どうよ?

>>480
読んでみたけど・・・プログラマが飲み屋で酒飲みながら
言ったXPの悪口って感じでしかないな。
全く批判になっていない。読む価値なし。

>>481
禿同。読む価値なし。時間のムダ。

XP自体が飲み屋の愚痴から作られたようなものだろ。

>>483
確かにそんなかんじがする(w
逆にRUPは研究室で生まれたような雰囲気があるね。
本当の成り立ちはよく知らんけど。

意味不明の会話を楽しむスレはここですか？

特に>>480-484

XP厨降臨。某大手メーカーでテスト自動化を推進する模様。

テスターですが何か？
http://pc.2ch.net/test/read.cgi/prog/1034346679/

テストの自動化＝UnitTestとは限らないのでは。
XPなんて言葉が出始める以前にテストの自動化ツールはすでにあったし。

C0 C1 のテストケースを自動作成して実行とかね。

三冊ほど読んだけど、計画ゲームが良く分からん。
ストーリーとタスクの定義が良く分からん。
タスクポイントやらも良く分からん。

誰か頭の弱い漏れに教えてプリーズ。

ストーリー = ユーザ側から見た機能
タスク = 開発者が実装すべき機能
タスクポイント = そのタスクをプログラミングハイ状態で
　　作ったとしてどのくらいでできるかの目安。

>>490
回答ありがとう。

＞ストーリー = ユーザ側から見た機能
＞タスク = 開発者が実装すべき機能

ここが良く分からないんですよ・・・
ストーリー =タスクになることが多いような気がして。
それにタスクカードはあるのにストーリーを管理する手段はないの？
自由フォーマットでうまく行くのだろうか。

＞タスクポイント = そのタスクをプログラミングハイ状態で
＞　　作ったとしてどのくらいでできるかの目安。

これもストーリーポイントとタスクポイントとの区別が分からなくて・・・
ベロシティはストーリーポイントとタスクポイントのどっちを基準にするのか
良く分からん。

漏れってやっぱり頭悪い

>>491
毛並みつやつやのいかしたクマちゃん人形を作るとして、
ユーザが
・腕が動かせる。両腕連動きぼんぬ。
・足が動かせる。連動しなくていい。
・首も動かせる。エクソシスト嫌いだし回るのは150度だけ。
というストーリーを要求してきたとする。

タスクはこのストーリーを実現するための方法なので
・ジョイント（というかよくわからんが）を使って回るようにする
・糸を使って連動する仕組み
・回転止めを付けて、必要以上に回らないように
なんてのがタスクかもしれない。
一番目のタスクは三つのストーリーで共通している。

>>492
ありがとう。
何となく分かったような気がするよ。

最近、急に雑誌とかでアジャイルって言葉が目立ってきてるような気がするんだけど、結局アジャイルって何？

ストーリーもカード作るよ。
http://home.att.ne.jp/gamma/shata/articles/XP_UMLPress.html
http://objectclub.esm.co.jp/eXtremeProgramming/XpPracticeReport.html

>>494
こんなところ。
http://www.metabolics.co.jp/XP/AgileCommentary.html

ペアプロのパートナーとテストユニットを脳内に構築したら
さらに軽量なプロセスになるな。
最強かも。

ついでにプログラミングも脳内に押しとどめとけよ

XPを実践しているソフト会社に転職したいんだけど、
実際、存在するのかね？

５００はもらった。

ついでに転職も脳内に押しとどめとくと(転職先のソフト会社が)吉。

>>499
取引先に依存する部分もあるから、難しいかと。
実際運用できるのって回帰テストぐらいなんじゃないの？

俺的にはペアプロだけはしてほしい。

ペアプログラミングって実際に可能なの？
デバッグのときはいいと思うけど、コーディング時の効率は確実に落ちるのでは？

>>504
実際にやって見たことがあるんだが、そんときはものすごく速くなったよ。
40時間ルールがジョークじゃないってことも理解できた。（疲れるから）
実はXPの一環としてじゃなくてたまたまだったんだけどさ。

もし機会があったら試して見るといいかも。
意外性はテストファーストよりはるかに上だったよ。

ただいつもうまくいくかは、やっぱり疑問が残った。
もちろんレベルもある程度合ってないと難しいだろうし。

>>505
やっぱり重要なのは、技術レベルが合ってるかどうかだよなー
で、お互い実力を認めあえる仲でないと喧嘩になりそうだし

バカだけど自己主張が烈しい奴と、
形だけでも一緒に仕事するのは、
非常に手間がかかる。
(ｱﾌｫでもわかるｱﾌｫ理論を構築して時間をかけないと納得しない。
ｱﾌｫにはｱﾌｫ担当が必要)

技術力が会わない奴や、自己主張が激しい奴。コミュニケーションが下手な奴。
ペアプロをしないとしてそれで上手く開発できるか？

ペアプロが上手くいかないという状態はそれだけで問題があると思う。
ペアプロは開発に重要なことから逃げられないようにする方法でもあるのではないだろうか。

具体例示せ。つか、思い込みの決め付け強そう

ソフトウェア開発する時に
仕様書はあった方がいいと思いますか？
なかった方がいいと思いますか？

私はない方がよいと思っているのですが

「プログラマな仕事ばかりしていると
いいように使われるだけだよ」
と、暗に仕様書書き出来た方がえらいよ
という意味の事を言われました。

その割に、会社で仕様書書いて外に発注している
プロジェクトはオオコケで
俺のやっている仕様書無しで開発してXPを
意識して運営しているプロジェクトは
大体、成功しています。
(出来ない事は出来ないと早めにいうから
　大きく失敗はしない)

日本の体質で仕様書を重んじる風土があるように
思いますが、それって本当に重んじる事が
優れた事・正しい事なのでしょうか？

仕様書はある種コミニケーションの手段だから、
時間（保守）と空間（外注）をこえて、十分なコミニケーション
がとれるなら必要ないだろ

>510
仮に、そのコけてる所が中途半端にXP取り入れて仕様書カットしてもやっぱりコけるだろう。
仮に、君のいるプロジェクトで今度は仕様書使いましょうって事になっても成功するだろう。
XPはどんなプロジェクトでも成功させる万能薬という訳じゃない。

秀和システム出版の「よくわかる最新XPの基本と仕組み」という本で良く分からないところがあります。

----------------------------------------------------------
P97
「ベロシティを宣言する」のルール

ユーザ
・何もしないこと

開発者
・前回のイテレーションで達成したストーリポイントを申告
・はじめてのイテレーションはもとにするデータがないため、便宜的に以下の値を使用するとよい

人数×イテレーションの長さ÷３

例）６人のプロジェクトでイテレーションを２週間とした場合、

６×２÷３＝４

よって、４ストーリポイントと宣言する。

（注）1ストーリポイント＝1理想週
----------------------------------------------------------

上の式で使われているマジックナンバーの３はどのような意味があるのでしょうか？
単純に考えると６人×２週間で１２週間ですが、ペアプログラミングや割込み業務等の
オーバーヘッドを考慮したら３で割る程度の効率しかないということでしょうか？

>>510
> 仕様書を重んじる風土があるように
> 思いますが、それって本当に重んじる事が
> 優れた事・正しい事なのでしょうか？
正しいことです。現在には脳内キャシュに残っている仕様も
数十年後には消えてしまっている確率はかなり高いです。
消える前に仕様書として何らかのストレージに吐き出しておく
必要があります。

おそらくXPの小規模のプロジェクトの保守は２人以上ではできない
可能性が大です。（おそらく１人か０．？人）

XPにはプロジェクトの保守がかなり曖昧に書かれてますが
結局、プロジェクトには保守があり、その場合には
２人で対応することは現実的に言って難しいでしょう。
そして、１人で行った作業は１人の脳内にしか存在せず、
その人が辞めたりしたら大変なことになります。

仕様書は必要です、但しソースと乖離している仕様書は
有害無益で必要はありません。

仕様書がどーのこーのゆう奴等は、プログラマが実際に
何をやっているのか把握できないもんだから、自分の権限を
アピールするためにも、仕様書書け書け言ってるだけ。

奴等はいなくなった方がプロジェクトがスムーズに
進むのはまちがいない。

>>514
長文でｱﾌｫな意見書く前に
開発を進めるために開発中に仕様書を書くことと
開発が終了してから製品マニュアルとして
仕様書を書くことを区別して考えて出直し。

漏れは必ずしもXPマンセーじゃないが、ほぼ同意。>>516

「引継ぎの資料としてのドキュメント」が必要だっていいながら、実装に
先立って無理やりドキュメントを完成させようとする糞がまだ生き残ってる。

開発を進めるための仕様書
→利害関係者の脳みその中身の同期を取る手段
→目的が達成できるなら手段は何でもいい
　→人数が少なければXPライクでおっけ
　→関係者の人数が多かったり、特に顧客が度を越したアホ系だった場合
　　は、永続化しておかないと脳内の同期は難しいので、仕様書という書
　　類にしておくべし

公開する仕様書
→説明書
→なければ売れません

>>516
> 開発を進めるために開発中に仕様書を書くことと
クライアントの考えていることと、自分の考えていることが
一致しているかの確認と証拠
また、受け入れテストの設計を行うための資料となる

> 開発が終了してから製品マニュアルとして
> 仕様書を書くことを区別して考えて出直し。
クライアントに出来るだけ運用を任せるように書くのが製品マニュアル
何か障害が発生してもリカバリ手順などが書かれていれば
こちらは呼び出されなくて済む
また、他人に引き継ぐときに１子相伝の口伝みたいなことをして
情報の欠落を防ぐことが出来る（伝言ゲームってやってみたことある？）

近くのコンビニ行くぐらいの規模しか使えない
限定的な方法論のXPでは仕様書は必要ないのには同意
しかし、引き継ぐときには仕様書ぐらいは書いておけよ。
そして、１度も行ったことのない遠くの目的地に仕様書という地図もなく
期限内にたどり着けることが出来るかい？
XPのプラクティスを信奉するのは個人の自由だけど
XPの限界も見えずに吠えるのは君はXPを使っているのではなく
XPに振り回されて無いかい？

↑読む気がしない。。。

>>519
>クライアントの考えていることと、自分の考えていることが
>一致しているかの確認と証拠
>また、受け入れテストの設計を行うための資料となる
仕様書では結局クライアント（それどころか開発者同士でも）との意思疎通ができない
からＸＰみたいな方法論が出てきたんだと思うけど？

ＸＰ的には受け入れテストを先に書く。
だから受け入れテスト＝仕様書って考えてもいいんじゃない？

出直しと言ったのに、出直せてない。
長文でえらそうに書いてもｱﾌｫはｱﾌｫだと認識。氏んで治せ。

>近くのコンビニ行くぐらいの規模しか使えない
>限定的な方法論のXPでは仕様書は必要ないのには同意
>しかし、引き継ぐときには仕様書ぐらいは書いておけよ。

XPではそういう引継ぎのやり方は推奨してないですね。よく嫁。
個々のﾌﾟﾗｸﾃｨｽだけ実践しても抜け落ちる部分はある。

それに"引き継ぐときの仕様書＝製品ﾏﾆｭｱﾙ"は必要あるとは思うが
"開発を進めるための開発中に書く仕様書"は書く必要があるのか？
それを、小一時間問い詰めたい..

>XPのプラクティスを信奉するのは個人の自由だけど
>XPの限界も見えずに吠えるのは君はXPを使っているのではなく
>XPに振り回されて無いかい？

>>514=>>519の【脳内XP】について信仰する香具師、
限界を見る香具師、振り回される香具師、誰もいません。

>（伝言ゲームってやってみたことある？）
お絵かき伝言ゲームってTVで見たことある？

>クライアントの考えていることと、自分の考えていることが
>一致しているかの確認と証拠
それを口頭で伝え合えないのに、仕様書なら伝わるか？
仕様書を書くコストに見合う分の密接で迅速な意思疎通が
出来るというメリットはある？私はないと判断する.
忘れる？
仕様書とは呼ばないが、議事録や進捗報告などを
箇条書きメモとして残しておけばよい。

XP原理主義ならカードを用いるはづだ。


>また、受け入れテストの設計を行うための資料となる

受け入れテストを書いてしまえば、仕様書はいらないのか？


まあｱﾌｫと問答しても仕方ないか。

>>521
> だから受け入れテスト＝仕様書って考えてもいいんじゃない？
ふむそういう考え方もあるのか。少し考えてみる。

>>522
> XPではそういう引継ぎのやり方は推奨してないですね。よく嫁。
少なくともXPでは２人以上の人数を必要とされる。
しかし、XPが適用できるようなチンケなプロジェクトに
保守を２人も付けられるのか？１人以下が現実じゃないか？
どうやって小規模プロジェクトに保守人数を２人も置けるような
体制を組むことが出来るのか小一時間問いつめたい。

> "開発を進めるための開発中に書く仕様書"は書く必要があるのか？
> それを、小一時間問い詰めたい..
必要がある。各個人の意志を統一するためには口頭だけでは不十分
何らかの文書か図、メモとして残しておく必要があり、
それが変更されたときにすぐさま変更できるような物であることが望ましい。
また、差分を取ったり、ロールバック出来たりするのが最高だろう。

>>523
> 仕様書とは呼ばないが、議事録や進捗報告などを
> 箇条書きメモとして残しておけばよい。
> XP原理主義ならカードを用いるはづだ。
私はそれを「仕様書」と呼んでも良いと思っているけど何か？

少なくとも大規模になればなるほどソースの概観と
そのシステムで可能なものと不可能なものを示すものが必要
取りあえず私はそれを「仕様書」と呼ぶことにする。

>>522
> >>514=>>519の【脳内XP】について信仰する香具師、
> 限界を見る香具師、振り回される香具師、誰もいません。
でも、「仕様書」に固定観念を持っている香具師は何人かいるようだね。

> 仕様書を書くコストに見合う分の密接で迅速な意思疎通が
> 出来るというメリットはある？
密接で迅速な意思疎通が出来るメリットがある分だけの仕様書を書けばいい。
それが書けない理由って何？

>>525
＞それが書けない理由って何？

>>522じゃないが単純に時間と言ってみる。

C3 プロジェクトも XPer な連中がチームから離脱したら瓦解したらしいね。
引継ぎのためのドキュメント作りもストーリーにして、
プライオリティをつけてもらえばいいと思う。

>>527
そういうことも含めてAgileスレで語りたかったんだが、
時期が早かったのか、そもそもこの板とは相性が
合わないのか・・・

>>528
この板は学生が多いと思われ。
漏れもしがない院生だったりする。
体験談も交えて語るならマ板がいいんじゃないだろうか。

>>529
マ板でXPなんか知ってる奴はおらんだろ

>>526
> 単純に時間と言ってみる。
時間は言い訳にならない。なぜならXPは自分で時間を見積もることができるから

>>527
> 引継ぎのためのドキュメント作りもストーリーにして、
> プライオリティをつけてもらえばいいと思う。
問題はクライアントに価値を認めてもらえるかどうかだな。
クライアントに対しては引継ぎのためのドキュメント作りは
何のビジネス的な価値もない。（まぁリファクタリングもそうだけど）

で俺の最大の疑問点
> どうやって小規模プロジェクトに保守人数を２人も置けるような
> 体制を組むことが出来るのか小一時間問いつめたい。
には誰も答えてくれんのか？

趣味でプログラムをやってるので、XPはどこまで一人プログラミングに適応できるかが興味あります。
UnitTest は使ってるけど

>>531=514
スレの流れから無理ないけど、俺はXPの人じゃないよ。

だけど非常に圧迫されたスケジュールでとにかく納品が優先される
状況だと、主に口頭と軽量なツールでコミュニケーションをとるのが
一番効果的だったりする。と、経験上漏れは思う。

ツールとは例えばIP Messengerとか。
ログが残るのでいつでも確認できるけど、これを「仕様書」とは
呼ばない。（呼ぶか？？？）

＞時間は言い訳にならない。なぜならXPは自分で時間を見積もることができるから

レス>>525と合わせると、「自分で時間を見積もる」ことによって
「密接で迅速な意思疎通が出来るメリットがある分だけの仕様書」
を書く作業量を、口頭での意思疎通にかかる作業量より少なくできる、
と読めてしまうんだけど。どういう意味？
よかったら説明キボンヌ。

# 横入りしてアレだけど、なんでもかんでも「仕様書」って言うんだったら、
# 話が成り立たないと思うんだが。
# まあマターリしようや。と言ってみるテスト。

議事録を仕様書と呼ぶ514の早変わりには驚くな。
IPﾒｯｾのログも514には仕様書なのだろう。

XPが[引継ぎと保守に関してあまり考慮されていない]
という意見には同意。

受け入れテスト＝仕様書というのは
その通りだけど、それだけでは
保守や引継ぎの資料として少ないのではないか？

>>534
素の XP を実施すると以下のドキュメントが得られる。
ストーリーカード、受け入れテスト：要求仕様
タスクカード、ユニットテスト：設計仕様
Javadoc、Doxygen（インテグレーションついでに作るだろう）：実装仕様

たしかに足りない気はするが、結局ソースコード読まなきゃ理解できないと思うのだけれど。
（200 クラス程度の Java プログラムを上から引き継いで改造した経験から言って）

>>535
＞たしかに足りない気はするが、結局ソースコード読まなきゃ理解できないと思うのだけれど。

結局は読むことになるソースコードが読めるソースコードになってる事が重要な
わけだけど、その点XPに分がある。
コーディング規約じゃなくてリファクタリングの方を指して言ってるわけですが。

>>533
> ツールとは例えばIP Messengerとか。
別にそれでも構わない

> 「密接で迅速な意思疎通が出来るメリットがある分だけの仕様書」
> を書く作業量を、口頭での意思疎通にかかる作業量より少なくできる、
> と読めてしまうんだけど。どういう意味？
口頭での意思疎通には迅速だが、互いの認識が異なる確率も高い。
そして、意識が異なった場合、再び意志疎通を行わなければならない。
文書化すれば、互いの認識が異なる確率は口頭よりも低くなる。
また、引き継ぐときに同じことを別の人に言わなくても済む。

> # 横入りしてアレだけど、なんでもかんでも「仕様書」って言うんだったら、
> # 話が成り立たないと思うんだが。
>>524で
　　少なくとも大規模になればなるほどソースの概観と
　　そのシステムで可能なものと不可能なものを示すものが必要
　　取りあえず私はそれを「仕様書」と呼ぶことにする。
と規定してますが何か？

>>535
> 素の XP を実施すると以下のドキュメントが得られる。
> ストーリーカード、受け入れテスト：要求仕様
> タスクカード、ユニットテスト：設計仕様
> Javadoc、Doxygen（インテグレーションついでに作るだろう）：実装仕様
で、仕様書は「必要」ということでよろしいか？

あと、先週からの疑問
> どうやって小規模プロジェクトに保守人数を２人も置けるような
> 体制を組むことが出来るのか小一時間問いつめたい。
には誰も答えてくれんのか？
学生やプロジェクトリーダにもなったことのない底辺PGには無理かな？

「小規模プロジェクトに保守人数を２人も置けるような体制を組む」
また脳内断定ですか。

XPはファーストテストで仕様を確定させてるから
いつでも即座にリファクタリング、
保守人数は0人というスタイルだろうから。
小規模プロジェクトに保守2人も置くという事はない。
何が疑問かわからんな。

＞学生やプロジェクトリーダにもなったことのない底辺PGには無理かな？
10人で出来る事を100人でやって、えらそうに振舞う514には
XPはいらないだろうし、そういう警告がXPにもかいてあるのに。

XPだと、ペアプロやコードの共有などがあるから、開発に関わった全ての人が
即保守にも関わる事ができるっていう考えでいいんでしょうか？

>>539
君はXPを知っているようだから教えて欲しい
できれば俺のようにステハンか何かで議論してもらえるとありがたいのだが
もちろん強制はしない。俺の希望だ。

> XPはファーストテストで仕様を確定させてるから
> いつでも即座にリファクタリング、
> 保守人数は0人というスタイルだろうから。
> 小規模プロジェクトに保守2人も置くという事はない。
最初はストーリをたくさんもらって頻繁にイテレーションを行うだろう。
しかし、一通りシステムを作り終えて、もうストーリがなくなった場合、
頻繁にイテレーションを行うことは無くなり、人員の縮小を行わざるを
得ないと思うけど以下質問。
・XPのプラクティスを全て満たすための最小単位は2人だよな。（確認）
・ストーリが無いのに2人を張り付けておけるのか？
　（俺の経験から言って、せいぜい1人が限界、クライアントに
　　なぜ、2人も張り付かせておかなければならないかの説明が出来ない）
・保守人数が0人の場合、バグが発生した場合、どう対応するのか？
　（XPでバグは少なくなるとは思っているが、0になるとは思えない）

上記2点について君の意見が聞きたい。

> 10人で出来る事を100人でやって、えらそうに振舞う514には
また脳内断定ですか。　
俺は100人も指揮するような才覚もないしするつもりもない。
プログラムと煽りには多少の自信はあるけどね。

>君はXPを知っているようだから教えて欲しい
本を精読して知ってるだけだけどな。

あなたの質問はXPでは具体的に語られていない部分だから
わたしの解釈と思ってください。
>頻繁にイテレーションを行うことは無くなり、人員の縮小を行わざるを得ないと思うけど
だろうね。

>・XPのプラクティスを全て満たすための最小単位は2人だよな。（確認）
そうなの？
既に人員縮小状態ではﾌﾟﾗｸﾃｨｽ全てを満たす必要はないと思う。

>・ストーリが無いのに2人を張り付けておけるのか？
終了ﾌﾟﾛｼﾞｪｸﾄならもう"開発工程"になっていないから
無理にXPﾌﾟﾗｸﾃｨｽを実践していく必要性がなさそう、だと考える。
わたしがｵﾝｻｲﾄ顧客なら、保守要員なんていらないと判断するが。

>・保守人数が0人の場合、バグが発生した場合、どう対応するのか？
他Projとの兼ね合いもあるが、UnitTestと受け入れテストを
実施してそれがｺｰﾄﾞに落とされているなら
バグ修正は、開発に関わった者ならすぐに。開発に関わらない者でも
迅速に対応できるだろうから、開発要員を0人から1,,2人にするのは
容易じゃないか？

何も仕事がないのに保守人数を確保するという形式が理解できないが。
そういう形式が暗黙常識な業界？

わたしは、XPはﾌﾟﾗｸﾃｨｽじゃなくて
ｽﾋﾟﾘｯﾄなのではないかと考えています。
臨機応変。それもXP。

＞　　少なくとも大規模になればなるほどソースの概観と
＞　　そのシステムで可能なものと不可能なものを示すものが必要
＞　　取りあえず私はそれを「仕様書」と呼ぶことにする。
じゃあ、会議と打ち合わせを録音した媒体も仕様書と呼ぶことで。同意？（ｗ

514も格式ばった仕様書は必要ないという意見のようだから

開発において、いわゆる上長の判子をもらうような仕様書は
必要ないという事で、よろしいか？

>>542
> あなたの質問はXPでは具体的に語られていない部分だから
> わたしの解釈と思ってください。
了解、ちなみに実際に複数人で開発したことはなさそうだな。
それどころか一人で1万行を超えるプログラムも作ったことがなさそう。

> 無理にXPﾌﾟﾗｸﾃｨｽを実践していく必要性がなさそう、だと考える。
> わたしがｵﾝｻｲﾄ顧客なら、保守要員なんていらないと判断するが。
XPは基本的に脳内に仕様を置いておき、必要最小限の仕様書しか書かないことで
でスムーズに開発を進める方法だと思っている。
また、１人で脳内の仕様を置いておくと、忘れたり間違えたりするので、
常に複数人で開発を行い、脳内仕様の信頼性を高める方法だと思っている。
# 単体では信頼性の低いハードウェアを2重化して信頼性を高める方式と似ている。

要するにペアプログラムはRAID-1だと思ってる。
保守が1人の場合、脳内仕様の信頼性が低いし、バグを潰したつもりで
新たなバグを仕込む「エンバグ」が発生する可能性が高い。
これではせっかくXPで開発をした意味がない。

> 何も仕事がないのに保守人数を確保するという形式が理解できないが。
> そういう形式が暗黙常識な業界？
保守契約って知らないのか？ちなみに請負契約とSES契約も知らないのか？

> わたしは、XPはﾌﾟﾗｸﾃｨｽじゃなくて
> ｽﾋﾟﾘｯﾄなのではないかと考えています。
保守というシステムの寿命のなかで一番長く一番難しいことを論じていない点
クライアントがスーパSE並のスキルを持っていることを前提としている点
俺はXPは宗教かイデオロギーだと考えてる。良いことは言っているが所詮机上の空論

>>543
> じゃあ、会議と打ち合わせを録音した媒体も仕様書と呼ぶことで。同意？（ｗ
いいよ

> 開発において、いわゆる上長の判子をもらうような仕様書は
> 必要ないという事で、よろしいか？
ここは「SES開発において、厳格な仕様書は必要ない」に訂正させてくれ
請負契約では厳格な仕様書は必要で、クライアントの判子をもらう必要がある。

>保守が1人の場合、脳内仕様の信頼性が低いし、バグを潰したつもりで
>新たなバグを仕込む「エンバグ」が発生する可能性が高い。

仕様書もテストケースもソースの中にあるのだからこれは無いんじゃね？
確実なテストを行うことができ、誰でもソースに手を入れられるって事は、
開発完了後の保守性も高いという事になると思う。

　14：細かい部分のミスを指摘し相手を無知と認識させる
　　　　　「犬って言っても大型犬から小型犬までいる。もっと勉強しろよ」

>それどころか一人で1万行を超えるプログラムも作ったことがなさそう。
ﾌﾟﾌﾟ.簡単にひっかかるね。煽りには自信があるんでした？

> 要するにペアプログラムはRAID-1だと思ってる。
> これではせっかくXPで開発をした意味がない。
ﾍﾟｱﾌﾟﾛでは確かにそういう効果をねらっているが
そこでRAIDの話を出すあたり知識ひけらかしたい厨の514らしさだ。

>保守契約って知らないのか？ちなみに請負契約とSES契約も知らないのか？
知らないが、それがどうかした？（藁
ケントベックはさぞ熟知しているんだろうね。

> > わたしは、XPはﾌﾟﾗｸﾃｨｽじゃなくて
> > ｽﾋﾟﾘｯﾄなのではないかと考えています。
> 保守というシステムの寿命のなかで一番長く一番難しいことを論じていない点
> クライアントがスーパSE並のスキルを持っていることを前提としている点
> 俺はXPは宗教かイデオロギーだと考えてる。良いことは言っているが所詮机上の空論
文がずいぶんつながってないな。またやり直しだぞ。
わたしを机上だけで語って人間と、いつものように脳内で断定してるからかな。

大きい数字が好きなようだからいっておこうか。
(XP白い本のP17は君の為に書かれているからあと5回)
人生で2番目に書いたまともなｱﾌﾟﾘは確か1.6万行
下手だったからかなり冗長だったけどね。今なら2000行くらいに絞れるかもな。

>> じゃあ、会議と打ち合わせを録音した媒体も仕様書と呼ぶことで。同意？（ｗ
>いいよ
冗談がわからない？（ｗ
会社の人の同意を得てきたほうがいいな。
外注が会議の録音を仕様書だとして提出してきたら
誰だって怒るだろ。（藁、あなたは許容するのかい？

>請負契約では厳格な仕様書は必要で、クライアントの判子をもらう必要がある。
ああ、XPにもそういうﾌﾟﾗｸﾃｨｽがあったはずだ。
何番目だっけ？256番目？重要じゃなさそうだな。なるほど後回しにしよう。

まあ、大筋で間違ってはいないから、変な勘違いをせずにがんばってくれ。

>>546
> 仕様書もテストケースもソースの中にあるのだからこれは無いんじゃね？
> 確実なテストを行うことができ、誰でもソースに手を入れられるって事は、
> 開発完了後の保守性も高いという事になると思う。
１回か２回の修正ならば問題は無いかも知れないが、何年にもわたって修正が加わり、
かつその履歴や経緯がドキュメントとして残されていないと問題
特に１人で修正を行い、ドキュメントがその人の脳内にしかなく、
その人が辞めてしまったり、病気などになってしまうと他の人に引き継げない。

>>548
> そこでRAIDの話を出すあたり知識ひけらかしたい厨の514らしさだ。
メタファを示しただけなのに「知識ひけらかしたい厨」と思い込みたいのが548らしいね。
XP読みのXP知らずという言葉を君に捧げよう。

> 知らないが、それがどうかした？（藁
一度検索してみてくれ、XPはSES契約では効果を発揮するが、
最初から納期と金額が決まっている請負では
最初に仕様をキッチリ決めておかないと泥沼にハマル

> わたしを机上だけで語って人間と、いつものように脳内で断定してるからかな。
いや、君を机上だけで語ってる人間と言ってない、
XPを机上の空論と言っている、机上の空論である理由は以下のとおり
・保守というシステムの寿命のなかで一番長く一番難しいことを論じていない点
・クライアントがスーパSE並のスキルを持っていることを前提としている点

> 人生で2番目に書いたまともなｱﾌﾟﾘは確か1.6万行
ふむ、そうは見えなかった。じゃあそれは撤回する。
ちなみに複数人で開発したことはあるか？