eXtreme Programmingの12のプラクティスを、自分の本を書く過程と対比させてみました。
とても一致するところと、一致しないところがあります。
12のプラクティスの項目と解説文はXP FAQのページから引用させていただきました
（問題がありましたらご連絡ください）。
-
計画ゲーム(The Planning Game)
-
XP:ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。
-
結城:レビューアへの原稿送付の時期は、おおよそのところは前もってレビューアに提示するが、実際には書かれた段階でリリースする。
-
小規模リリース(Small Releases)
-
XP:シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。
-
結城:目次をレビューアに送付する。それから各章をはじめから順番にリリースしていく。
-
比喩(Metaphor)
-
XP:どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)をメンバーが共有することで全ての開発を導く（ガイドする）。
-
結城:1冊の本全体を貫いているシンプルなメタファー（または、テーマ？）を提示することで読者を導く。
-
シンプルデザイン(Simple Design)
-
XP:いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。
-
結城:読者が理解しやすいように本は構成されるべきだ。読者を混乱させる情報は見つけ次第取り除かれるか修正される。
-
テスティング(Testing)
-
XP:プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。
-
結城:著者はテキストから自動的にサンプルプログラムを抽出して動作させるPerlスクリプトを使う。
-
リファクタリング(Refactoring)
-
XP:２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を換えることなくシステムを再構成する。
-
結城:著者は読者の読みやすさと理解しやすさを改善するために、コードとテキストを編集する。
-
ペアプログラミング(Pair Programming)
-
XP:全てのコードは２人のプログラマにより一台のマシンで書かれる。
-
結城:全てのコードとテキストは著者により一台のマシンで書かれる。
-
共同所有権(Collective Ownership)
-
XP:誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。
-
結城:どの章でも、どこででも、いつでも、著者はコードとテキストを修正できる。
-
継続的インテグレーション(Continuous Integration)
-
XP:システムを一日に何回もインテグレードしビルドし、テストを 100% パスさせる．
-
結城:プログラムを書いたら、動作を確認する。テストまでは作っていない。
-
週40時間(40-Hour Week)
-
XP:週４０時間以上仕事をしてはいけないのがルール。
-
結城:疲れた状態で仕事をしてはいけないのがルール。
-
オンサイト顧客(On-Site Customer)
-
XP:現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。
-
結城:現実の読者層をレビューアとして迎えて、フルタイムで質問・意見・感想を受け付ける。ただし返事は約束しない。
-
コーディング標準(Coding Standards)
-
XP:プログラマは、コーディング標準に従って全てのコードを書く。
-
結城:著者は、あるテキストベースのマークアップ言語を使ってすべてのコードとテキストを書く。
なお、以下では、『伽藍とバザール』のバザール方式との比較も書かれています。
