［Kent Beck XPセミナー特集］
XP Seminar 参加報告
4月19日(木)、東京ファッションタウンにて「eXtreme Seminar on eXtreme Programing (以下 XP Seminar)」が開催されました。UML Forum での Jacobson、Fowler に続き、今回も「XP エクストリーム・プログラミング入門」の著者 Kent Beck が来日し、丸一日 XP の考え方、実践方法について直に話を聴くことができました。では、セミナーの内容を簡単に報告したいと思います。
はじめに
まずはじめに、事前の広告や Web の案内等では開始 10:30 となっていたのですが、実際会場へ行ってみると 11:00 から開始とのこと、多くの人が無駄に30分時間を過ごすことになり、これはちょっといただけないなと思いました。で、その30分ですが、他のオージスのメンバと話をしたり、先行発売されていた K. Beck と M. Fowler の「XP エクストリーム・プログラミング実行計画」を買って見たりしていました。この本まだじっくり読んではいませんが、通勤途中などで気軽に読めそうな本だと思います。
テイラリズム vs. ソフトウェア開発
午前の講演では、テイラーが提唱した、専門化と完全分業を行うという工場などでの管理手法 (テイラリズム) と、そのソフトウェア開発への影響、そして、それに対する XP からのアンチテーゼという形で話が進められました。テイラリズムは、労働者の生活向上と労使関係の改善を行ったが、労働者を「頭が悪く」「怠惰で」「欲が深い」、あるいは単なる「物」という視点でしか見ていないと、Kent Beck は指摘していました。そして、ソフトウェア開発においても、このテイラリズムの考え方が大きな影響を与えていると。それに対して、XP では、労働者すなわちプログラマを「人間」として扱おうとしていると言っていました。
このような XP のいわば哲学の話に続いて、12のプラクティスなど XP の特徴がいくつか紹介されました。詳細は書籍等を見ていただくとして、いくつか印象に残った点 (質問への回答を含む) を上げておきたいと思います。
- 12のプラクティスについて
… 単独で実行できるのもあれば、相互に関連しているものもある。- Rapid Prototyping との関係
… Rapid Prototyping はその日暮らし、XP は継続的。- スパイラルモデルとの関係
… スパイラルモデルは Water Fall を細かくして繰り返したもの。各フェーズでは 分析-設計-実装 という同じ手順で行う。XP ではこれらを並行して行う。- メンバーの役割
… 設計者、実装者のような細かい役割分担はない。ただし、ビジネス側と技術側の2つの役割はある。
XP での計画
午後は、「Tea Maker の絵をかく」という課題で、8名 (顧客側4名、開発側4名) ずつのグループに分かれ、XP での計画を実際に体験するという時間でした。私は開発側だったのですが、お客様の要求を Story という形に整理し、見積もりを行い、各イテレーションで実装する Story を決め、実践し、修正し、また実践する、といった作業を行いました。最初、やり方を飲み込むまでに時間がかかってしまったので、もう少し時間があればとも思いましたが、なかなか面白かったです。ただ、XP では「実装しながら設計を行っていく」という考え方のようですが、実際にやってみると、機能を追加していくにつれて、だんだん全体の整合性が取れなくなってしまうので、ある程度の事前設計と、途中での設計見直しはやはり必要だなと感じました。
会場では、あるチームが描いた Kent Beck の小便小僧型 Tea Maker が発表され、大いに受けていました。
休憩時間中、Kent Beck のサイン&握手会(?)が開催されました。私も買ったばかりの「XP エクストリーム・プログラミング実行計画」にちゃっかりサインをもらってきました。内表紙の「ケント・ベック」とカタカナで書かれた部分を線で消して、その上に英語でサインされていたのですが、これってお決まりなのでしょうか?
テスト・ファースト、質疑応答
テスト・ファーストの話とデモのあと、質疑応答の時間となりました。これもいくつか印象に残った点をあげておきます。
- ドキュメントについて
→ ドキュメントの目的は Communication であるが、そのドキュメントが必要なときには既にゴミになっていることが多い。また、変更時の障害にさえなる。それに替わるものは Team である。もし、顧客から Paper が必要だと言われたら作成すればよい。それは (技術的な決定ではなく) ビジネス的な決定である。- 大規模開発
→ 大規模な開発は本当に必要か? 私なら、数人のチーム、数ヶ月の期間でまず First Release を開発する。- ペアプログラミング
→ 席の配置の仕方のアドバイス。E-mail はプログラミングをするマシンから外す。追加で次の質問がありました。
- ペアの相手が消極的な場合はどうするか?
→ 自分がもっと消極的になる(笑)。- 開発ツールにこだわりがある場合は?
→ チームの成功よりツールが大切なのか? ツールが異なってもできることはある。場合によっては、プロジェクト開始前に少し時間をかけて話し合う必要もあるかもしれない。- CMM との関係
→ 人とプロセスの相対的な関係が異なる。CMM はプロセス重視。XP で最も重視しているのはプログラマ。CMM はドキュメントを重視している。CMM と XP とでは哲学が異なる。- 他のプロセスからの移行
→ 何をするかでなく、姿勢の問題である。
[方法1] 徐々に移行する - 1つのプラクティス (例えば Test First) から始める。その際、プラクティスの相互依存性に気をつけること。
[方法2] 全てを1回やる - 新人が多い場合などに有効。
以上で報告を終わりにします。全体的に Kent Beck の主張が伝わってくる面白いセミナーだったと思います。
≪関連 URL≫
| © 2001 OGIS-RI Co., Ltd. |
|
