Web2.0ベンチャーにおけるAgile Process
今のベンチャーでは、XPに限りなく近いプラクティスを実践しています。プラクティスを実現するために徹底的にツールを作りこんでいる点と、分散開発でXPのプラクティスを実現している点は特に興味深い点だと思います。では、実際にXPのプラクティスと今のベンチャーのプラクティスを対比して、書いてみたいと思います。
XPのプラクティス | XPのプラクティス説明 | 今のベンチャーのプラクティス説明 |
計画ゲーム(The Planning Game) | ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。 | 計画は現実に合わせて変更をする。ソフトウェアにおいて正確な見積りが無理であることを理解しており、見積りには時間を掛けない。 |
小規模リリース(Small Releases) | シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。 | 新バージョンを2週間に1回のリリース。顧客からのフィードバックを重視し、とても短いタイミングでリリースをする。 |
比喩(Metaphor) | どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)をメンバーが共有することで全ての開発を導く(ガイドする)。 | 特にはない。 |
シンプルデザイン(Simple Design) | いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。 | Test Drivenな開発が行われており、余計な複雑さはない。日本のように「WORD」を使った設計フェーズは存在しない。コーディングが設計であることをよく理解している。 |
テスティング(Testing) | プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。 | Storyという顧客にとって価値のある機能単位毎に実装を行い、Story毎にAcceptance Testを行う。Acceptance Testは主にSeleniumとWikiを組み合わせたテストケースを書くことで実現している。Seleniumで書かれたAcceptance Testは完全に自動実行ができ、Storyのデグレードを確認できるようになっている。 |
リファクタリング(Refactoring) | 2重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を換えることなくシステムを再構成する。 | テクニカルリード(プロジェクトのチームリーダ)がコードレビューを行い、定期的に指摘を行い、コードの改善を行っていく |
ペアプログラミング(Pair Programming) | 全てのコードは2人のプログラマにより一台のマシンで書かれる。 | 分散開発をしており、Screen上のセッションを共有することでペアプログラミングを行う。SkypeとScreenによるペアプログラミングを行っている。 |
共同所有権(Collective Ownership) | 誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。 | XPと同じ。チームごとに開発するものは決まっているが、誰がどこを修正してもよい |
継続的インテグレーション(Continuous Integration) | システムを一日に何回もインテグレードしビルドし、テストを 100% パスさせる. | 単体テスト全てを日に数回自動実行する仕組みを使い、テストが失敗したらメールで通知する仕組みがある。これにより、デグレードを防ぐする仕組みを構築している。 |
週40時間(40-Hour Week) | 週40時間以上仕事をしてはいけないのがルール。 | 開発時間は、週35時間程度、その他を含めると40時間は越えているが多くはない |
オンサイト顧客(On-Site Customer) | 現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。 | これは行っていない |
コーディング標準(Coding Standards) | プログラマは、コーディング標準に従って全てのコードを書く。 | プロジェクト共通の整形ツールがある。ツールを使えばコーディング標準を開発者が意識することはない |