eXtreme Programming Part.2

>>851
>たとえば、資料を整理するときに、何もしないという方法がある。

あるねー。俺反対派なんだけど。（ｗ

>ただただ、時間順に格納していくだけ。
>これが実は、非常に効率的なんだ。
>人間というのは、時間の流れと関連づけると、驚くほど記憶している。
>また、作業コストがほとんどかからない。

一理あるけど、これは整理自体は人間の頭の中で別な方法で
行われており、現実の資料の整理はそれと関連付けているだけだと思う。

整理の本質は物の整理ではなく、思考の整理であること、そして
物の整理にとらわれて本質的な整理をおろそかにしがちであるということ
に対するアンチテーゼとしては価値がある。

でも、それじゃあ「思考の整理とは？」となるんだけどね。なんかXPと似ている。

>この手法の欠点は、同じ時間を共有していなかった人間には、資料を検索不可能なことだ。
>だからといって、この手法が役にたたないと言えるか？

「整理」の本質がどこにあるかが明らかになるね。すなわち
「整理」するのは「資料」じゃない。頭の中にある情報だということを
いやおうなしに気づかされる。なかなか有益だ。

ただし（頭の中の）整理にはぜんぜん役に立たない。
これもXPと似ているね。

いや、なかなかいい例を出してくれた。超整理法とXPの類似点を考えてみるかな。

>ほとんどの情報処理部の人間が、定年まで勤めるような会社なら、何の問題がある？

まさか定年まで第一線でコーディングするわけじゃないだろうから、
記憶をいつかは新人に引き継がなきゃならない。その引継ぎのときに
役に立つのが「資料」だよね。資料がなかったり、整理されてなければ
その引継ぎ作業の負担が増えるってだけの話と思うが？
ようするにそれが問題だろ。

>>853
>マジこれが難しいドキュソユーザ相手なら撤退しろってことやな。
>ＸＰの場合はダイレクトコミュニケーションが基本なので、
>伝言ゲームはない。

>その点は勘違いしないでくれ。
>君が何を問題にしているのかがわからないんだが？
>ユーザ側の伝言ゲームって何？どういう状況のこと？

何度かいってると思うが、君がいう「伝言ゲーム」は開発者側
にはないってことだよね。顧客側にはある。ユーザーが一人とか
数人のソフトを無意識に想定してない？

ユーザーが数百人いて、使い方や望む機能がまちまちで、
顧客側の担当者がそれをまとめきれなければ、どうするの？
開発者がプログラム作りながら個々のユーザーと話し合うわけ？

>>858
>ユーザーが数百人いて、使い方や望む機能がまちまちで、
>顧客側の担当者がそれをまとめきれなければ、どうするの？
そんな状態になったらどんな手法でもそのプロジェクトは破綻するんでは(笑)

ともあれ、XPでは顧客は「決定権のある人」を要求している。
その例ではそもそもXPはできないな。

>>858
ＯＫそういうものに関して言えば、ＸＰは無力だよ（苦笑）。

ただ、良いソフトウェアをつくるためには、
超ハードユーザの助けが必要だというのが、これまでの知見なのだ。
その人選に問題がある場合は、どの道ソフトウェア開発はうまくいかない。
「万人の意見を聞くのではなく、たった一人の要望を限りなくかなえていく。」
このことが逆説的に万人のためのソフトウェアの作成方法なのだってね。
ＸＰはそういう思想に基づいている。

で、突き放すだけではあれだから、別の方法についても提示しておくよ。
ハーバードプレスの「隠れた人材価値」という本がある。
http://www.amazon.co.jp/exec/obidos/ASIN/4798102245/ref=sr_aps_d_1_1/250-2897484-1399424
リンクうまく行くといいんだけど。

この中で紹介されているのが、ＳＡＳインスティチュートの例だ。
ＳＡＳのスタイルはＸＰではないが、ＸＰと思想が同じものになっている。
人に優しく、ユーザに優しく。サステナブルに開発を継続していく。

ユーザ会などを通じて、どのような機能が必要か常に聞き続ける姿勢を
つらぬいているよ。

あとはオープンソースなら、バグトラッキングシステムを使いながら
Voteを使って優先順位を決めたりしているね。

何でもかんでもＸＰでってのは無理さ。でも、やり方はあるし、
それとＸＰを組み合わせるのもそう難しくはない。

がんばっていこうじゃないか。

>>859
>>ユーザーが数百人いて、使い方や望む機能がまちまちで、
>>顧客側の担当者がそれをまとめきれなければ、どうするの？
>
>そんな状態になったらどんな手法でもそのプロジェクトは破綻するんでは(笑)

破綻するプロジェクトってのはだいたいそういうもんだよ。
そうでなきゃウォーターフォールでも破綻しない。

>ともあれ、XPでは顧客は「決定権のある人」を要求している。
>その例ではそもそもXPはできないな。

だからウォーターフォールが破綻するようなプロジェクトはXPでも
破綻する。

>>860
>
>ただ、良いソフトウェアをつくるためには、
>超ハードユーザの助けが必要だというのが、これまでの知見なのだ。
>その人選に問題がある場合は、どの道ソフトウェア開発はうまくいかない。

同上の答えだ。なんとなくキミと俺ではプロジェクトが窮地に立たされる
主原因の想定に違いがあるようだ。

俺は基本的に顧客からの要求仕様の確定にネックがあると思っている。
顧客もSEもこの部分が分析しきれないから、破綻する。

一方キミが想定している破綻の原因はなんだい？顧客側に自分たち
が望むもののとりまとめが出来る人物を想定しているわけだよね。

となると設計や実装の方にネックがあるといってるの？それもあるけれど、
一番の原因は要求仕様のほうだと思うけど。

で、設計能力の未熟さはXPで改善できるが、要求仕様について
XPは開発者側から顧客側に責任を押し出しただけで、全体としては
なにも改善されていないだろう、と俺はいっている。

>で、突き放すだけではあれだから、別の方法についても提示しておくよ。
>ハーバードプレスの「隠れた人材価値」という本がある。
>http://www.amazon.co.jp/exec/obidos/ASIN/4798102245/ref=sr_aps_d_1_1/250-2897484-1399424
>リンクうまく行くといいんだけど。

ふむ。読んでみようかな。

>何でもかんでもＸＰでってのは無理さ。

俺の言いたいこともまさにそれだ。XPの考えはよいが、XPだけじゃ駄目だ。

ん?>>861は XPだけですべてが賄えると信じている人を相手として想定してたの?
そんな人いないんでは。
もともとXPは対象を限定してるのに。

>>862
微妙に違うな。
XPだけでは「何も」賄えない、といってるんだよ。

そりゃ誰かに要求仕様をまとめてもらってあとはプログラムを作るだけに
してもらえれば、できるだろうね。けどそれはウォーターフォールでも
おなじなんだよ。

＞もともとXPは対象を限定してるのに。

ではXPが対象としているのは、何だい？
それはウォーターフォールでは無理なのかい？

無理じゃないんだよ。XPでうまくいくならウォーターフォールでも
うまくいくんだよ。

XPはただ省エネだってだけだよ。

＞XPはただ省エネだってだけだよ。
それで十分じゃん。

顧客の要求をそんなに簡単に確定できるのなら、
何でやっても成功するでしょう、それは。

プロジェクトの初期に顧客の要求を大部分捕らえることができる、
などと考えるのは傲慢だと思うんだけど、どうだろう？
ウォーターフォールな人は、自分の馬鹿さ加減を少なく見積もり過ぎてないか？

>>866
それは俺にいってるのか?
相変わらず馬鹿のひとつ覚えだな｡
まともにレスつける気にもならん。
相手してほしけりゃもう一度俺の文章読み返せ｡

逃げに必死

少しヒントをやろう｡
俺は要求仕様はそんな簡単に確定できない､といってるんだ｡
にもかかわらずあんたの文章の出だしがそんなんじゃ､まともにレスする気力がなえるのもわかるだろう｡

いまモバイルだから長い文章を書けないが､864がすべて反語表現になっていることさえ読み取れない自分を恥じるように｡

＞にもかかわらずあんたの文章の

相手は一人、という事にしたいのですね？:-)

くだらん｡

＞反語表現になっていることさえ読み取れない自分を恥じるように｡

ちゃんと自分の表現力の無さには恥じているんだろうな？

つｰことでこてはんはこの辺で止めるよ｡
こてはんにすると厨房が群がってきてうざいからな｡

わるいね>狂信者

>>870
顧客相手にもそんな感じなの？

>>873
そのレベルの煽りなら一人でやっててくれ｡
もすこしベルの高い煽りなら､おれも煽りあいは嫌いじゃないから参加するがね｡(w

ま､煽るにしても相手の文をちゃんと読むのが基本だけどな｡そして論理の上げ足を取るの｡

モバイルで一生懸命書きこんでくれてるんだ…。いい人だなあ。

で、簡単にはできないが、俺のようなかしこい人間が努力すれば
それは可能である、と思っているように見えるが？

>>875
お､ちょっとだけ煽りのレベルがあがったね(w

これは対厨房モードだよ｡まともな議論するなら、なともに対応するが､君のレベルでは無理だろうな｡ありがちなことをならべるだけだろ?

>>877
駅についちゃったじゃねーか｡つｰことで終わり｡
ひとつだけ答えれば､いくら賢くたっていくら努力したって要求仕様は確定しないんだよ。XPの教科書読め｡

862=866=873=875=877
こんな感じかな。809や813や824あたりも同一人物かな。

XPの教科書に書いてあることを丸暗記しているだけのやつ。

深い話になるとXP擁護、XP批判のどっちの立場でもついていけなくなって、なりを潜めて、
自分でも相手になりそうな発言（実は当人の読解力がないだけの誤解なんだけど）にだけレス
つけるやつ。

こういうのがのさばるからXPは宗教だとかいわれるんだろうね。
迷惑な話だ。

>>854
期待して待ってるんだけど、まだ？

一人を相手にすることで万人に売れるのか？

これは実は割合に基本となる考え方なんだ。
やわらない商売の筆頭のＣＤ業界でも
プロデューサーが絶対だ。

一般受けを考えるともう駄目。答えがでない袋小路にはまってしまう。
それならいっそたった一人のためのモノを作ったほうがいい。
似たような人は必ずいて、そしてその人たちに売れるのだから。

昔は、マーケッティングで統計的に処理するのが、はやったようだけどね。

今は、avexの松浦やケミストリの松尾のように、「ユーザ代表」の
ツボにくるものを納得いくまで作る体制で、自分と似た連中に
必ず売り込む体制を作る連中のほうが成果を出している。

売れるソフトウェアを作りたいのなら、
自分が一番ほしいソフトを開発すべきだ。

ここらへんが、オープンソースやシェアウェアと同じ発想だね。
ＸＰは、そういう事実を素直に認めているだけなんだ。

>無理じゃないんだよ。XPでうまくいくならウォーターフォールでも
>うまくいくんだよ。

煽りあいにはしたくないので、それほど拘っているわけじゃないんだけど、
上のは、「XPでうまくいくプロジェクトはウォーターフォールでも必ずうまくいく」
って意味でしょうか？

単純に考えても、ウォータフォールじゃ工程移行コスト・工程戻りコストが大きくて、

・短納期
・開発体制が10人規模
・ビジネス上の理由により、要求仕様が確定しない

っていうようなプロジェクトがうまくいかない気がするんだけど。

>>882
>一般受けを考えるともう駄目。答えがでない袋小路にはまってしまう。
>それならいっそたった一人のためのモノを作ったほうがいい。

これは別に否定するつもりはないけど。

>売れるソフトウェアを作りたいのなら、
>自分が一番ほしいソフトを開発すべきだ。

これもね。

>ＸＰは、そういう事実を素直に認めているだけなんだ。

ここに飛躍がある。別にXPがそれを認めているとか推奨している
事実はないと思うけど。

ま、いわんとすることはわかるよ。
少なくともXPはそういうものと相性は抜群にいいだろう。

となるとXPは受託とかよりは一般向けに販売される商品開発と
相性がいいだろうね。実際XPと呼ぶか否かは別として、規模は
さまざまだけど、それに近い形で開発されてると思う。

けれど受託は、その点、XPに向かないんじゃない？（ｗ
イテレーションをやったところで、最初は造った部分も
少ないから、それに対する仕様変更とかも少ないかもしれない。

けどだんだん作った部分が増えていくが、それに対する仕様変更
の割合は減らない。仕様変更がくるのは新たに作った部分に対して
一定の割合でくるのではなく、そこまでに作った部分に対して一定
の割合でくる。

XPは、設計を先延ばしにして作業を暫時的に行うことで、変更が生じたときに
まだ作っていない部分を作り直す必要がない点を強調する。ウォーターフォール
では極端な話すべてを同時に作り始めるから、変更が生じた場合にすべてが
作り直しになる。この点XPは確かに優れているだろう。

しかし変更の頻度が問題だ。最悪

1回目 モジュール1を修正
2回目　モジュール1と2を修正
3回目　モジュール1と2と3を修正
　：
n回目　モジュール1と2と3と・・ｎを修正

なんてことになるんじゃないの？（ｗ

すくなくとも顧客側の取りまとめ役が思いっきり馬鹿で近視眼的なしなりお
しか書けないなら、こんな悪夢のような状況になると思うけどね。

そうならないのは、やっぱ全体を見通してモジュール1とかモジュール2を作るからだよね。

つまり全体設計ってのは要るんだよ。XPでも。必要にもかかわらず陰に隠れてしまっている
ところが、むしろ始末が悪い。

>>883
>
>煽りあいにはしたくないので、それほど拘っているわけじゃないんだけど、
>上のは、「XPでうまくいくプロジェクトはウォーターフォールでも必ずうまくいく」
>って意味でしょうか？

いや、それは俺の煽りだよ。あえて飛躍した論法だ。（笑）

>単純に考えても、ウォータフォールじゃ工程移行コスト・工程戻りコストが大きくて、
>
>・短納期
>・開発体制が10人規模

そうだね。普通そういった小規模の開発は教科書どおりのウォーターフォールでは
しない。ウォーターフォールと呼ぶかどうかは別として、各工程の人をダブらせて
（例えば設計した人がコーディングもするとか）、現実的な範囲で運用する。

それをウォーターフォールの変形とするかXPの変形とするかは、さて。

工程の面から見たXPの本質はやっぱり段階的な開発だよね。(工程以外の
面から見たXPの本質はいろいろあるけど、ここでは置いとく。。。と書かないと
また厨房につっこまれてうっとうしいから。)

だから軽量型ウォーターフォールはやっぱりウォーターフォールじゃないかと思う。

この辺は実はどうでもよくて、

>・ビジネス上の理由により、要求仕様が確定しない

ここが焦点だと思う。この場合>>884の末尾のようなことにならないの？ってこと。
軽量型ウォーターフォールだと設計の見直しもコーディングの見直しもわやくちゃ
になっちゃうから、確かによくない。その点XPはこれをちゃんと扱っている。
ただしちゃんとあつかっているのは「開発者の側だけ」。

顧客の側を含めれば、何も変わってないんじゃないの？
だからくりかえし同じだといってるんだよ。

使用が確定しないのは顧客の自業自得だからしったこっちゃない、という
感じではないの？

開発者側が一方的に辛酸をなめるような自体がよいとはいわない。もちろん。
けど顧客のことを考えないなら、おそらく顧客はそんな開発方法を支持しないよね。

>>885
別に悪夢でもお金もらえれば全然問題にしない。
そういう割り切った部分はあるよ。

モジュールという言葉を使うとあれだけど、
タスク毎にかなりのクラスに手を入れるのがＸＰスタイルなので、
そういう状況は、むしろ大歓迎。

その手を入れるチャンスを使って、
トップＰＧが、大胆なリファクタリングをすることで、
設計品質を一定にするんだ。

ＸＰがいかに優れたプロセスだからといって、
プログラマの無能をカバーはしてくれない。
そのチームの一番優秀なＰＧの力次第で、
どこまでやれるかは決まってしまうのさ。

経験豊富で優秀なＰＧを２割は押さえておかないとね。
そいつらが実質的に全体設計するんだよ。

ただ、そいつらが仕事するには、準備が必要で、
そのために、テストケースという形で、どこまでいじっていいのかを、
知らせてあげなくてはならない。

それさえできるなら、ダサイインプリでガリガリする
レベルの低いプログラマがやはり２，３割いても
問題にはならない。

まぁ、ＯＯＰを極めた人間を何人抱えているかが問題だな。

>一方キミが想定している破綻の原因はなんだい？
これだけど、一言で言えば、報告と事実とのカイリということだな。

プロジェクトの破綻の元の原因はともかくおいておくとすると、全ての罪はこれから始まる。

ウォーターフォールでやった場合の、ＳＡの進捗どう図るんだい？
ＳＤの進捗どう図るんだい？
「ClassXXX 設計進捗４０％、まだ不明な点が多い。」

こんな報告に何の意味があるんだい？
ＸＰはここの部分を明らかにしてくれる。それもシンプルで確実な方法で。
ついでに、失敗することを許容してくれている。
これにより、悪い情報を早く取ることが出来て、それに対する対策が取れる。

だからアグレッシブな見積もりもできるし、全力疾走やる気にさせてくれる。

ＸＰマンセーの所以だよ。

http://www.tech-arts.co.jp/xp/OneTeamJ.pdf

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

>>887
>>>885
>別に悪夢でもお金もらえれば全然問題にしない。
>そういう割り切った部分はあるよ。

うーん。既存のプロジェクトでもデスマーチになる原因の
多くはこれだと思うんだけどね。で、問題は3つ。

　1）XPにしたからといって現実に金はおそらく取れない。
　2)XPにしたからといって、顧客らか見てスケジュールが遅れれば、さまざまな圧力はあるだろう。
　3）金とは関係なしにPGの士気が下がる。

仮に俺が顧客側だとして、1)と2)は認めがたい。というか
そこを譲歩して得られるメリットがよくわからない。

>モジュールという言葉を使うとあれだけど、
>タスク毎にかなりのクラスに手を入れるのがＸＰスタイルなので、
>そういう状況は、むしろ大歓迎。
>
>その手を入れるチャンスを使って、
>トップＰＧが、大胆なリファクタリングをすることで、
>設計品質を一定にするんだ。

>ＸＰがいかに優れたプロセスだからといって、
>プログラマの無能をカバーはしてくれない。
>そのチームの一番優秀なＰＧの力次第で、
>どこまでやれるかは決まってしまうのさ。


うん。よいね。この辺は実にいいと思う。
プログラミング面ではXPに文句はないよ。

>経験豊富で優秀なＰＧを２割は押さえておかないとね。
>そいつらが実質的に全体設計するんだよ。

>それさえできるなら、ダサイインプリでガリガリする
>レベルの低いプログラマがやはり２，３割いても
>問題にはならない。

なるほど。それはそんな感じかもしれないね。

>>886

>顧客の側を含めれば、何も変わってないんじゃないの？
>だからくりかえし同じだといってるんだよ。
>
>使用が確定しないのは顧客の自業自得だからしったこっちゃない、という
>感じではないの？

XPの思想としては、そういうわけではないと思います。

仕様が確定しないのも、変更されるのも、顧客のビジネス上の都合であるのは
許容していて、その上で、

・最初に言っておいてくれないからいまさら対応できない
・いまから変更するのは莫大な工数が必要になる
・最初にFixした仕様にサインがあるから最初のとおりに作る

っていう状況を発生させないことを目指している。

それにしたって、仕様の変更も追加もコストはかかるので、
どちらを選ぶにしても、いつでも顧客が適切な負担で選択できるように
オプションを提示しよう、提示できるようにしよう、っていうのがXPの思想
であると思う。

で、そのオプションを提示できるようにしているプラクティスが
・リファクタリング
・ユニットテスト
・スモールリリース
であると考えています。

>>888
>これだけど、一言で言えば、報告と事実とのカイリということだな。
>ウォーターフォールでやった場合の、ＳＡの進捗どう図るんだい？
>ＳＤの進捗どう図るんだい？
>「ClassXXX 設計進捗４０％、まだ不明な点が多い。」
>
>こんな報告に何の意味があるんだい？

なかなか鋭いとこ突いてくるね・・・

つーとXPだと進捗管理がより正確にできる、ということでOK?
それには同意してもいいよ。

ただし分子（やったこと）ははっきりわかるけど、分母（やらなきゃならないこと）は
未定なんだから、進捗率は出せないだろうけどね。

XPでなくても、やったことは嬉々として答えてくれるよ。残件を聞くと表情が曇るけど。
ま、やったことが実際のプログラムやテストで確認される利点は、確かにある。
反面、設計で試行錯誤することになった場合、後の工程もそのまま振り回される。
その点は「本来の」ウォーターフォールもXPも変わらん。それがいやで、すでに
作成済みの部分をなるべく生かそうと適当にごまかすから現実のウォーター
フォールはぐちゃぐちゃになる。

でもXPでも同じことがおきないのかなぁ。だってやっぱりせっかくコーディングして
テストしたのに作り直しなんていやじゃん。って考える人は多いと思うけどね。

分母は明らかだよ。
チームレベルなら、
アクセプタンステストの項目数が分母。分子は通った数だな。

個人レベルでの責任範囲はタスクだから、
イテレーションスタート時にサインアップしたタスク数が分母で、
分子は完了数だ。

君が問題にしているのは、ＸＰに対する問題じゃなくて、
スパイラル形式、イテレーション形式一般に対する問題のようだ。

そういや XP の場合、
分析・設計=ストーリー・タスク作成にどれくらいかかるかは見積もるの？

>>893
>君が問題にしているのは、ＸＰに対する問題じゃなくて、
>スパイラル形式、イテレーション形式一般に対する問題のようだ。

確かにそうだね。

正直、自分が顧客側のプロジェクト責任者だったら、XPを提案してきた
会社に発注するか、悩む。

例えば>>461であげられているようなプロジェクトの責任者になったと
して、俺はXP方式を提案する会社に怖くて発注できない。

俺なら、まず社内の業務形態を徹底的に分析しなおす。かなりの
リソースをかけて。その後必須の機能をウォーターフォールで作ら
せる。そして実運用開始。足りない機能は人間系が補う。
次の段階で再度必要と思われる機能を分析。同様にウォーター
フォールで作らせる。

こんな具合が俺のやり方だ。これをXPでやるとどうなる？
最初の分析＆概略設計にどれくらいの時間をかけるかが知りたい。

多分俺なら全体の1/4〜1/3ぐらいの工数が、（2回の分析それぞれで）
必要と思う。

>>889
XP自身も「変化を抱擁」の対象なんだね。
確かに、XPのプラクティスはあくまでもKent Beckたちが実践してきた中で遭遇した問題に対応して
修正し、リファクタリングしてきたものなんだな。
ということは、導入するときもKentたちの対象と完全に一致するものでない限りボロは出るし、
金科玉条のように各プラクティスに従うのではなく、修正して今後に反映していかないといけないんだ。

>>896
XP 自体をリファクタリングするという考えには禿しく胴衣！！！！

お邪魔します。

顧客側の要求定義をどうやってまとめるか？
どうやって設計作業の中に取り込むか？
を議論しているように見えたので一言。

ウォーターフォールでは、設計を開始する前に要求定義を完全に終了させようと
している。漏れた仕様は仕様変更でフォローする。

ＸＰでは、要求定義、設計、実装、テストを含めて、イテレーションという
ループ作業の中に入れようとしている。

ウォーターフォールは、設計以前に完璧な要求定義を必要とし、
ＸＰは、完璧な要求定義を持った顧客がイテレーションの中に入ることを
必要としている。

どちらも完璧な要求定義は必要であるが、その時期、タイミング、設計や実装に
与える影響などが違うと思う。

>>898に追加です。

ウォーターフォールとＸＰの大きな違いは、設計者と顧客との距離なんだと
思います。

|・ユーザの役割：大部分はプログラマの視点からXPについて述べた。
|（「簡単なストーリーが多く必要だ」「すべての質問に答える」
|「修了したことがわかるように多くのテストが必要だ」など）。
|ソフトウェアのユーザになることは難しい。
|このテーマに関してはもっと多くのアイデアが登場するだろう。
XP アドベンチャー pp.140

決定解はまだ持っていないということだね。
XP 本を読んだ限りでは、
日常的にさまざまなソフトウェアを使いこなしていて、
こういうソフトウェアを作りたいとビジョンが
抽象的ではなく実際のソフトウェアの形で想像でき、
できればプログラミングの経験もあるユーザが
適していると思った。

>>897
XPをリファクタリングしたらウォーターフォールになっちゃいました。（ｗ

>>889のリンク先見れば、アナリストはあるはQAはあるは、マネージャーはあるは。

>>898-899
そりゃそーだが、で、何が言いたいの？

>>900
> 日常的にさまざまなソフトウェアを使いこなしていて、
> こういうソフトウェアを作りたいとビジョンが
> 抽象的ではなく実際のソフトウェアの形で想像でき、
> できればプログラミングの経験もあるユーザが
> 適していると思った。

適しているどころか、そうでないユーザーはXPの「ユーザー」には
なれない。だって「ユーザー」が要求仕様を決定するんだぜ？
最低SE並みの分析能力は必要だよ。

>>889のpdfを要約しとこう。反XPのバイアスをたっぷりかけて。

「XP エクストリーム・プログラミング入門」における最大の過失は、1 人のユーザだけ
を相手にしている」と想定していたことである。

モデラやテスタのスキル及び存在がチームにとってどれくらい大きな資産になるか
ということは充分わかっている。しかしXP のイメージが「プログラマチームの周囲を
旋回する1 人のユーザ」である限り、彼らの居場所は「どこにもない」ということになる。
彼らが正しいとすれば、私の持つXP のイメージが間違っているということだ。

では、テスタやモデラはどこに当てはめられるか？　ビジネスチームである。リリー
スされるソフトウェアの範囲と品質によって活動に影響を受ける人々が、全員
で情報収集、記述、検証など、とにかく何でもサポートするのである。
・アナリスト
・ユーザ代表
・テスタ
・マーケティング担当者
・ユーザサポート
・営業
・モデラ
・実際のユーザが行うことを観察し「道の舗装」の手助けをするインタフェ
ース設計者
・ビジネス戦略担当者

次スレ用意した
がんがん行こうぜー。

http://pc.2ch.net/test/read.cgi/tech/1023709462/

ﾎｼｭ