山口どの
牛尾でございます。お久しぶりでございます。
Ｗｅｂ系の現場でのメリットデメリットなら適当に、、。
>On-Site-Customer
・これはデメリットは思いつきません。というか、
やらんと怖いなぁ。
>PlanningGame
・デメリット：サブシステム間での微妙なずれ。あと、人数が増えて、サブシステム
が増えると時間がかかる。→お目付け役の設置で、サブシステムに
メンバー分割で対応。ゆるやかな縛りが必要か？
ユーザが要求に不慣れな場合がある。画面のみにこだわって仕様が右
、左にばかり（つまり機能強化じゃなくげ）変化ヲ抱擁して無駄な場合
がある→ユーザを引っ張ることで対応。
・メリット：少しずつものをみながら仕様を交渉するのはとっても今の現実に沿っている。
>SmallRelease
・デメリット：２週に１回リリースで、心の休まる暇が無い。
実際のリリースはなかなかできないと思いますができたところまでデモ環境
で見せると効果的。
>CustomerTest
・デメリット：できないところは、できない。でもテスト仕様ぐらいならできるユーザもいる。
>SimpleDesign
・デメリット：人によってシンプルの定義が違うことがある。Ａさんにとってシンプルなものが
Ｂさんにとって違うなど。
・メリット：引継ぎがめちゃめちゃ簡単になる
>Metaphor
・つかってません。
>PairProgramming
・メリット：教育効果、アーキテクチャの伝達効果。仕様書要らず。集中する。
・デメリット：効果的なやり方がわかりにくかったので、やりかたを勘違いしていた。
>TestDrivenDevelopment
うーむ。これは答えるのが難しいですが、
・テストコードも変化させる必要があるので、簡単な変更でも、テストコードの変更は
大変だったりします。
・でも、変更は安心してできます。
>Refactoring
・メリット：なしには生きていけない。
・デメリット：やりすぎてしまうことがある。
>CollectiveOwnerShip
・メリット：誰でも変更できるので、一人（たとえば河野君）がインフルエンザでダウンしても
コードを修正できて、プロジェクトがこけない。
・デメリット：とくにない。コンフリクトが面倒 ;-p
>CodingStandard
・メリット？： まもってなかったらたまにわからんようになる。
・デメリット？：コーディング標準を守らない、、人が多い。わしもそう。;-p
人によって書く癖がある。
>ContinuousIntegration
・メリット：結合しないと安心できません。
・デメリット：実際の客先では本当の結合には時間がかかりますので、工数と時間がかかる。
（ただし、マシンごとのクラスの結合？は当然やってますが）
>40-HourWork
、、、というか、ＸＰは疲れる。めちゃ疲れるのでこれをしないとつらい。
、、、、、で今終盤ですが、できてないので疲れています。
そのかわり上記プラクティスでプロジェクトは破綻せずやっています。
という感じでしょうか？とりあえず、もう滝が流れるやつには戻れない
体にはなっていることは確かです。
以上 ご参考になれば幸いです。