Agile Conference 2007 Day 4 - NAgiler航海日誌v2

今日は長文なのでさっそくセッションレポートへ。

【An Adaptive Performance Management System】
ジム・ハイスミスのプロジェクト管理系のセッションです。このセッションで言うところのパフォーマンスは生産性の方ですね。内容的には、パフォーマンスの測定をいかにビジネス価値に変えていくかという話です。他のセッションでも出てきたのですが(同じジム・ハイスミスのセッションだったか？)、インテルが公開している下記ホワイトペーパーがかなり使われているそうです。ビジネス価値とは？という議論をする際に役立ちそうですね。

Definitions the value of e-Business
http://www.intel.com/it/pdf/e-business-value.pdf

【Mingle: A New Agile Project Management】
こっちにきて初めて知ったのですが、ThoughtWorks社が新しく発売したMingleというアジャイル向けのプロジェクト管理（コラボレーションといった方が適切かも）のツールです。このMingleは、Ruby on Rails＋MySQL(or PostgreSQL選択可能)で開発されたAJAX型のWebアプリケーションです。

さっそくローカルマシンにインストールして動かしてみました。Windows ファイアウォールのある環境（私の環境はVistaです）ではMySQLの通信のブロックを許可する必要があったのでご注意を。

複数のプロジェクト（こっちではプロジェクトポートフォリオと呼んでました）も作成でき、プロジェクトのテンプレートをXP,スクラム,ハイブリッドから指定可能。今回は試しにスクラムで作ってみました。

カード上に表示されたタスクやストーリーをドラッグ＆ドロップで移動可能。画面キャプチャには無いですがTO DOやDONEなどにドラッグ＆ドロップで変更できます。もちろんビューを一覧形式に切り換えることもできます。

上記はスクラムのプロジェクトテンプレートで、トップページにバーンアップチャート（バーンダウンは...？）が表示される。また、Subversionと連携してソースコードも参照できます。（コードのdiffも見れるらしい）アジャイル開発者にとっては便利なツールですね。しかも他のツールと違ってシンプルでわかりやすく、使いやすい印象です。

有償の製品ですが、30日間は無料で使えるのと5人までは無料で使えるライセンス体系のようです。
またブースでも展示してましたがWiiリモコンを使って操作するデモも行っていました。おもしろ〜い！！

残念ながら日本語版は無いようですが、英語版でも試してみる価値はあるのではないでしょうか。ちなみに名前が似てますがGoogleとは関係なさそうです。名前の由来は何なんでしょうね？気になるところです。このmingleはさっそく会社で使ってみようと思うのでまた面白い発見があったらこのブログで紹介します。

【Refactoring Database】
アジャイルモデリングの執筆者のScott AmblerとThoghtWorksの方の３時間セッション（途中３０分ほど休憩あり）です。DBAを置いてその人だけがDBの管理をする・・・という典型的な手法からよりアジャイルにDBの変更管理を行うかというセッションです。アジャイルDBのテクニックに入る前に、まずは今までの習慣（文化？）を変える必要があります。

専任のDBAを置くのではなく、DBAという役割を兼ねた開発者が他の開発者と共同で作業する
開発環境は１つのDBを複数の開発者で共有して使うのではなく、開発者ごとに独立したローカルDBを準備する

まずはDBの変更をするためにDBAに変更依頼を提出して、DBAがDBを変更して・・・というプロセスを変えて、各開発者がDBの変更を行うように頭を切り替えるひつようがあります。これはAgilityを高めるためには当然のことですね。じゃあ、DBAは必要なくなるのかと言うとそういうわけじゃなく、役割が若干変わってきます。DBAは開発者とペアで作業を行い、開発者がテーブル設計やインデックスの設計、クエリチューニングをする手助けをする形になります。

それと開発者が独立したローカルDBを使って開発するというのは、開発の独立性を高めて、複数の開発者による並行作業を円滑に進めるためです。というのも１つのDBを共有していると誰かが変な変更をかけてしまった場合、他の開発者の作業が止まってしまう原因となるからです。

上記のことが可能になるにはユニットテストの存在が大前提になります。このセッションのデモでも見せていましたが、DBの変更は当然ソースコードにも影響があるため、DBの変更とコードの変更はセットで行う必要があります。
ユニットテストの成功／失敗によってDBの変更の影響範囲を知ることができるので、DBを変更した後もアプリケーションが問題なく動作することを確認することができるのです。また、DBは他のアプリケーションからも使用している可能性があるので、今回のDBの変更によって他のアプリケーションに悪い影響が出てないかを確認するために常時結合が威力を発揮します。ここまでできるようになるとかなーりアジャイルに開発を行うことができますね。

アジャイルDBのテクニックは、DBの作成から初期データの投入、DBスキーマの変更などをスクリプトで管理するのが基本になります。それとこれも知らなかったのですが、ThoughtWorksでDBの変更管理ツールを公開してますね。

dbdeploy
http://dbdeploy.com/

上記はJava&Antで利用できるツールのようです。.NET用に無いかと思ったら上記Webサイトにコンペのツール名が並んでました。個人的にはliquibaseがよさげだったのでちょっと調べてみることにしよう。

DB Ghost(有償)
http://www.dbghost.com/

liquibase
http://www.liquibase.org/

リファクタリングデータベースに興味のある方は、Scott Amblerの次の本が参考になりそうです。アジャイルとは関係なくDBの変更管理でお悩みの方は、いろいろヒントがあると思いますよ。私も読んでみたいと思います。