XP 2000 カンファレンス

4つの戦争物語

カンファレンスの初日は、4つの招待講演で始まり、そのすべてが適応型プロセスを使用したプロジェクトとチームについて語りましたが、そのうちの1つだけがXPを完全に利用していました。もちろん、それは頻繁に言及されるクライスラーの給与プロジェクト、通称C3でした。ロン・ジェフリーズがそれについて語り、その成功だけでなく、キャンセルにつながった原因についてもかなり詳細に説明しました。要約すると、このプロジェクトは最初の1年ほどで非常にうまくいき、クライスラーで毎月約10,000人の給与所得者に支払いを行うシステムを納品しました。その後、トラブルが徐々に発生しました。ロンは、これらのトラブルの原因を次のように特定しました。

• 給与部門（システムを使用）とIS部門（費用を負担）との間の目標の混在
• チームと、給与部門とIS部門両方の管理層との間のコミュニケーションの崩壊

次にロバート・マーティンが、教育試験会社のプロジェクトをテーマに講演しました。このプロジェクトは、ロバート、ジム・ニューカーク、およびさまざまな協力者によって数年かけて行われました。要件は非常に曖昧で変更可能であったため、短い（1週間）イテレーションと顧客との頻繁な接触によってこの問題に対処しました。彼らはXPの実践を完全に利用したわけではありませんが、重要な要素が困難な状況を成功に変え、このようなタイトなイテレーションがC++環境でも機能することを発見しました。この経験は、彼らの会社であるObject Mentorが昨年XPを熱心に支持するようになったきっかけとなった最高の例でした。

ラルフ・ジョンソンの開発例は、リファクタリングツールで可能となることを象徴する、有名なSmalltalkツールであるリファクタリングブラウザの開発でした。大学での博士研究の一環として開発されたもので、再びいくつかのXPの実践を使用してツールを開発しました。ここでも、タイトなイテレーションと設計への進化的なアプローチが中心であり、設計におけるリファクタリングの積極的な使用も同様でした。

最後の例は、Object Technology International（OTI）の創設者であるデイブ・トーマスの例でした。OTIは、組み込みシステムでSmalltalkと仮想マシン技術を使用した、要求の厳しい初期のオブジェクト指向プロジェクトで知られていました。彼の重点は、人を中心とした考え方、自動テスト、そして再びタイトなイテレーションでした。カンファレンスの多くの参加者とは対照的に、彼はこれらの技術を固定価格プロジェクトで使用できることを強調しました。

これらの講演の累積効果は、軽量な方法論で成功するための多くの方法があるということでした。他の方法論と同様に、軽量なアプローチは万能薬ではありませんが、人々を成功に導くことができる原則を提供します。

XPは統一されるのか？

繰り返されるトピックは、XPとRational Unified Processの関係でした。多くの人々は、さまざまな理由から、2つがより緊密に連携する必要があると考えています。デイブ・トーマスは、イヴァー・ジェイコブソンがRUPにXPを採用させ、事実上XPをRUPのインスタンスにすることを非常に望んでいると報告しました。ロバート・マーティンは別の路線を取りました。RUPを主張するかもしれないボスを満足させるために、XPをどのようにRUPのように見せるのか？ロバートは、ブーチの古典的なOO設計書の第3版で、グラディ・ブーチとジム・ニューカークと協力して、これをどのように行うことができるかの非常に確固たる例を作成しました。彼はまた、XPがRUPのインスタンスになり得るように、公式のRational Unified Processドキュメントに資料を含めるようRationalから委託されたことも発表しました。

ここで、2つの質問があります。XPとRUPを一緒に適合させることは可能ですか？また、もし可能なら、それは望ましいことですか？ロバートのアプローチとイヴァーの願望は、適合を時間の問題にしているようです。RUPが存在する場合、XPは確実にメニューに載っています。望ましさは別の問題です。ほとんどのXP支持者は、業界でXPを採用しやすくするためのアプローチを歓迎しているようです。しかし、懸念されるのは、RUP-XPを使用するとXPが希薄になり、人々が重要な実践を見逃してしまうということです。

私の見解では、ほとんど違いはありません。RUPにXPを含めることを阻止するものはありませんし、XPの部分的な使用の問題は、RUPがあろうとなかろうと変わりません。結局、最大の問題は人を中心に回ります。適応型プロセスは本質的に人中心であり、人々を抽象的なリソースとして扱う環境では機能しません。XPがRUPの旗の下で採用されるかどうかは、このより重要な問題には影響しません。

オープンな心

インターネット上でXPに関する投稿をたくさん読むと、しばしば、1つの真のXPのやり方からの逸脱に反対する熱狂的な信者の集まりという強い印象を受けます。このカンファレンスの最も良かった点の1つは、その熱狂がほとんど家に置いて行かれたということでした。その代わりに、私はXPのトピックに焦点を当てながらも、特定のXPの教義を過度に押し付けようとはしないカンファレンスを目にしました。

テーマは、XPがソフトウェアプロセスの良い基礎を提供しているものの、バリエーションが許可され、受け入れられたということでした。カンファレンスのほとんどの参加者は、せいぜいXPの部分的な採用者であり、カンファレンスのトピックは、リファクタリング、テスト、ストーリー収集などのXPの特定の側面に焦点を当てた多くの講演を可能にしました。

私自身も、デイブ・トーマスのように、このオープンさに非常に安心しました。XPの姿勢は人々の注目を集めるのに役立ちましたが、抵抗も引き起こします。私はその実践が非常に価値があると感じていますが、アプローチ全体を従うべき厳格な規則として捉えるような人間ではありません。方法論は、それを使用する人に合わせて選択および適応されるべきであり、その逆ではありません。

新しい方向性

カンファレンスの最後のパネルについての驚きはありませんでした。それは、ソフトウェア業界でXPがどのように採用できるかという必然的なトピックでした。そして、パネルのテーマは、XPがビジネス界で成長しようとしている他の新しいテクノロジーとまったく同じであるということでした。多くの人々にとっての問題は、彼らが自身の組織でXP、またはXPの一部をどのように使用できるかということでした。たとえ参加者がそれを使用したいと思ったとしても、彼らは上司に許可してもらえるでしょうか？

私は、これはやや的を外れていると思います。適応型手法の強力なテーマの1つは、技術的な決定を下す責任を技術者が負うということであり、技術者は技術的な決定を下すべきであるということです。問題は、会社がXPを許可するかどうかではなく、会社が技術的な決定を技術者に下させるかどうかです。それがなければ、XPの問題は無意味になります。あなたの会社がそうでない場合、問題はあなたの会社に変化をもたらすことができるかどうかになります。

その変化が不可能であれば、なぜそこに留まるべきなのか疑問に思う必要があります。パネルディスカッションで私が即興で作り出した言葉で言うと、「組織を変えられないなら、組織を変えなさい！」これは、Thoughtworksの純粋な採用宣伝ではありません（常に悪い会社から良い人材を喜んで受け入れていますが）。それはまた、ソフトウェアのプロフェッショナルが、最終的には、自分のキャリアに対する責任は誰よりも自分自身にあること、そしてこの市場は仕事に不満を感じる時ではないことを忘れないようにという呼びかけでもあります。

ジャックの見解

（ジャック・ボレス寄稿）

XP2000は終わりましたが、話題ではなく、議論と参加者の質が非常に優れていました。同僚のFoemmelが（XMLOneについて）言うように、テーマの最初のカンファレンスは多くのマーケティングと旗振りになる可能性があります。テーマのかなり極端な性質を考えると、後者がたくさんあるだろうと予想していましたが、嬉しいことに期待を裏切られました。そして、ロバート・マーティンの「契約の箱」のスピーチを除いて、実際にはマーケティングはほとんどありませんでした。;>

聴衆は、現在主にJavaで作業している、現役および元Smalltalkerでいっぱいでした。また、主にCで作業している、かなりの数の通信業界の人々もいました。これらの2つのグループと話していると、彼らがXPに惹かれた理由がわかりました。後者は、共同作業環境に慣れています。作業環境がシステムでもある場合、作業をテストし、同じイメージを使用して他のチームメンバーと共同作業し、コミュニケーションを取る傾向があります。通信業界の人々は、非常にタイトなスケジュール、特定する必要がある見つけにくいバグ、および慎重なコーディング標準を必要とする小さなフットプリントを持っています。

これらのグループを繋ぎ合わせ、セッションやその他の会話で繰り返し話題になったのは、開発プロセスに関与する全員の間での良好なコミュニケーションの絶対的な必要性でした。XPの12のプラクティスはすべて、コミュニケーションを明確に促進します。開発者間、開発と顧客間、顧客間のコミュニケーションもあります。XPを採用した人々によると、真の利益は、すべてのプロセスが実行されているときであり、コミュニケーションが部分の線形和よりも大きな改善を促進することです。

私が気づいたことの1つは、XPの12のプラクティスが2つのグループに分けられるということです。最初のグループは、あなた自身が行うために（ほとんど）他の人に依存しない個々のプラクティスで構成されています。これには、テスト、リファクタリング、シンプルな設計、および程度は低いですが、ペアプログラミング、まともな労働時間、コーディング標準が含まれます。2番目のグループは、チーム全体が必要です。それは、小さなリリース、継続的インテグレーションプランニングゲーム、オンサイトの顧客、集団所有権です。開発者が個々のプラクティスを個人的に使用できない理由はありません。コードをテストしたり、リファクタリングしたりなど、良い例を示すことは、人々に影響を与える傾向があります。逸話的な証拠によると、XPの静かな浸透が成功裏に使用されています。

グループの慣習を変えようとする場合は、効果が薄れます。特に、開発チーム以外のチームが関わる慣習はそうです。なぜでしょうか？個々のプラクティスは、主に開発者向けで、誰もが行うべきよく知られたベストプラクティスです。チーム指向のものは、顧客やマネージャーが不慣れで、実績がなく、コントロールを失うと感じるようなことを要求します（たとえ彼らが真にコントロールを持っていなかったとしても。例えば、プロジェクトのスケジュール）。

プロセスに全員を巻き込むことは、本当に難しい課題でした。特に経営陣や顧客に、試してみるように説得する方法について、かなりの葛藤がありました。マーティン・ファウラーは、もしあなたの組織が、あなたがそうあるべきだと思うことをしていないのなら、「あなたの組織を変えるべきだ」と何度も二重の意味を込めて言いました。それが、組織の働き方を変えることを意味するのか、働く組織を変えることを意味するのかは、学生への課題として残されました。

しかし、XPの文献や伝承において、顧客やマネージャーに「変化を受け入れてもらう」方法が、明らかに欠落していることを否定するものではありません。XP2001までには、それが変わることを願っています。