牛尾でございます。
スピード重視で書いたので文書メタメタで訳もしょぼくて申し訳ないですが、
とりあえずソルトレークのレポートを公開いたします。
内容としては
１．From Agile Modeling(AM) to Agile Deata Techniques
２．受入テストあれこれ
３．Collaboration for Agile Projects（長いので次のメール）
という感じになっています。
-------------------------------------------------
１．From Agile Modeling(AM) to Agile Deata Techniques
Scott W.Ambler
私がAgile Develop Conferenceの最初に参加したセッションは
Scott W.Amblerの「アジャイルモデリングからアジャイル
データテクニックへ」というとても興味深いセッションでした。
Scott W.Ambler氏はAgileModelingで有名ですが、EJB使いの
Mastering EJBなどでも名前を見かけますし、幅広い
守備範囲と現実的なアプローチを持った面白い人だと思って
注目しています。彼自身は「Agile Modeling」「Software Mentoring」
「Object/Component Development Mentoring」のコンサルタントだと
答えています。
セッションが始まったときにアンブラー氏にサインをもらいました。
なんと彼のセッションには１０名足らずの出席者しかいなかった
ので、とても得をした気分になりました。彼は私が日本からきたことを
告げると「Taku（藤井さんのことです)を知っているか？」と聞いてきました。
もちろんだよと答えました。
今回のカンファレンスでは興味深いセッションが目白押しで
どのセッションを選ぶかは大変難しいことでした。
さて、セッションの内容ですが、彼の著作に関しての報告がありました。
このセッションの名前にもでてくるとおり、今度の秋に出版される
興味深い書籍に
Agile Database Techinquesという書籍があります。これは要注目と
思います。
また、私はまだ読んでないので、どんな内容かはわかりませんが
「Object Primer 3rd Edition」という本も同時期に発売されるようです。
セッションの内容は
・「ラディカル」なアイデア
・ソフトウェア開発の現実
・アジャイルモデリング
・アジャイルデータ
・それらを実際にうまくやるには
・成功の秘訣
・アジャイルを続けよう
です。
最初にお断りしておきますが、私の英語力はたいしたことがないので
内容に関しては保証いたしかねます :-)
■「ラディカル」なアイデア
このパートでは彼の基本的な考え方に関して説明しています。
・モデルとドキュメントは違う
特に印象深い言葉としては「モデルはドキュメントではない」という話です。
彼は設置されていたホワイトボードの紙バージョンのようなボードに
ユースケースを書いて「これはモデルだけど、ドキュメントではない」と
いっていました。私の英語の理解力はあまりよいとはいえませんので
間違っているかもしれませんが、モデルとドキュメントの違いは
ドキュメントは残すものでモデルはそうじゃないというイメージです。
＃ドキュメントに関しては後述します。
個人的な意見ですが、モデルはプロジェクトの中で定常的に行って、
「ドキュメント」はある意味プロジェクトの完了までにあればいいとおもって
います。（例外はありますが）
・モデルとドキュメントは有効な使い方をしよう
これは説明はいりませんね。それぞれをうまく使いましょうという話です。
アンブラー氏の説明ではモデルとドキュメントのダイアグラムがでてきました。
下の中で○をつけたものが残すもの「ドキュメント」でほかのものは
あくまで「テンポラリ」だという話です。また、AMDD(Agile Modeling Driven
Development)のプロセスでは「初期要求でのモデリング」「初期のアーキテクチ
ャ」
モデリングのあとにイテレーティブに「詳細なモデリング」と「実装とテスト」
を行き来するようなイメージで説明していました。
ただし、最初の２つも「初期の・・・」と説明していることから変わらないも
の
とは考えていないようです。
--------------UMLの枠を越えたモデリングと彼が説明したもの
内容 残すか
User Interface Flow Diagram ○
User Interface Prototype ○
Essentioal Use Interface Prototype ○
Change Cases(アーキテクチャらしい) ○
Essential Use Case Model or
User Storyies
Use Case Model or User Stories
CRC Model ○
Business Rules ○
Constraints ○
Non-Functional Requirements ○
Sequence Diagram
Class Model(Analysis)
Activity Diagram
Essential Interface Specification ○
Component Diagram
Deployment Diagram
Collaboration Diagram
State Chart Diagram
Class Model(Design)
Persistance Model(データモデルのことと思う) ○
Source Code ○
のこすものと残さないものを明確に定義してくれている
ので、かなり参考になりました。私も自分のプロジェクトで
「Business Rules」を残していなかったので、これは
残しておけばよかったと思っていたところです。
・IT産業は「専門化」の害を受けている
今までの開発の考え方ではたとえば「分析」「設計」
「コード」「テスト」とそれぞれ専門化が進んでおり、
問題はそれらの分野たとえば分析者はコードのことをしらない
ということである。といっていました。
そしてその専門化の間（たとえば分析と設計）で
コミュニケーションギャップが起こっているという話を
していました。ITもいろいろあるけど、とりあえず技術者は
継続的にいろいろ勉強するべきという感じです。
・データプロフェッショナルはアジャイルになりうる
今回の主眼のひとつの「アジャイルデータ」にかんすることです。
・AMDD(Agile Model Driven Development)はTDD(Test Driven Development)は
いっしょに使います
AMDDはモデルを書いてコードという感じではなく、お互い行き来するもの
なので、アジャイルモデルをしてコードを書くときにはTDDをするのがお勧め
と彼は言っていました。
アジャイルデータ
・アジャイルデータはITプロフェッショナルが組織のなかで
ソフトウエア開発を行うにあたってのデータに関する
哲学のセットである。
・アジャイルデータはアジャイルアライアンスの価値のプリンシプル
に沿っている
・AMDDアプローチの開発でうまくいくと思われる
（すみません。訳があやしい）
http://www.agilemodeling.com/essays/amdd.htm
アジャイルモデリングの哲学
・データ
データはソフトウェア開発において重要な要素のうちの一つである
・Enterprise Issue(企業・組織または複雑な仕事の問題）
エンタープライズグループはほかのチームをサポートしないといけない。
また、エンタープライズグループはアジャイルの作法(agile manner)に
のっとっている必要がある。
・毎回状況は変わる
プロジェクトごとに状況が違います。
・いっしょに働こう
ITプロフェッショナルはいっしょに働きましょう。
（先ほどの専門化の話にも関連していると思います）
・スイートスポット
問題のスイートスポットを見つめましょう「白黒はっきりさせる」
じゃなくて、あなたの状況にもっともうまくいく「灰色」を見つけよう
アジャイルデータの役割
アジャイルデータでは、いくつかの役割（ロール）がでてきました。
ほかのチームと連携をとったり、プロジェクトを取りまとめるレベルの
・Enterprise Administrators(Data関連の管理者のとりまとめ）
・Enterprise Architects(アプリケーション系のとりまとめ）
また開発チームは
・AgileDBAs
・Apprication Developer
のそれぞれがコミュニケーションします。
たとえばDBAはデータ（モデルや制限）に関することをアプリケーション
開発者に話しますし、アプリケーション開発者はDBAにアプリケーションに
関するモデルや制限を教えます。これらの４つのロールがお互いやりとり
する感じです。
イテレーティブ＆インクリメンタル
アジャイルデータではデータモデルもEvolutionary（進化的）に
開発するという話をしていました。イテレーティブ＆インクリメンタル
に実施するものとしては
・オブジェクトモデル
・データモデル
・オブジェクトからデータモデルのマッピング
・実装
・リファクタ
・パフォーマンスチューニング
という話をしていました。これらをイテレーティブにインクリメンタルに
実施するという話でした。
アジャイルデータベースのテクニック
・データベースリファクタリング（マーチンファウラーのとは別）
http://www.agiledata.org/essays/databaseRefactoring.html
このURLは今見れる状況でないのでどんな内容かは興味深いのですが、
１例としてはいろいろなアプリがDBにアクセスするようなケース
＃JavaだけではなくてCOBOLとかほかの言語が混じってるとか
どうするか？という話もしていました。
・マッピングテク
・継続的なユニットテスト
・変更用のスクリプト
これらはあまり説明はなかったですが、とくに要らないとおもいます。
上記URLにいろいろ書いてあることが期待されます。
オブジェクト指向とデータの問題
このパートではいろいろなオブジェクト指向とデータの問題が
説明されています。
・キャッシング
・同時実行のコントロール
・データベースのアーキテクチャ
・レガシーのデータ
・Referential Integrity
・Versioning object
・カプセル化
・XML,web services,
・O/R のインピーダンスミスマッチ
・オブジェクト指向技術者とデータ技術者の文化の違い
UPの２つのフェーズの追加
アジャイルデータやアジャイルモデリングはXPやUPといっしょに
使うのですが、UPの説明のところでフェーズを追加していました。
＃XPは同じでした。
私はUPはよく知らないですが、多分新規のフェーズです。
・Production
・Retirement
普通のUPではプロダクトを作って終わりですが、メンテナンスという
か、２次の機能追加などに相当するのがProductionで、
さらに、そのプロダクトが引退の時期を迎えたときもいろいろ
するでしょうが？という話がRetirementでした。たしかになぜかどこにも
Retirementに関しては記述がないですよね。
成功の秘訣
・チームワーク
−ほかのチームもしくは人と近くで働くこと
−AMやADやアジャイルであることのよさを会社で話をすること。
ただし、いわゆる信者にはならないこと
・考えを改めつづけること
−ソフトウェア開発に関する考えを考え直せるようにしておくこと
−モデルとドキュメントは意味のあるようにしよう
−UMLは完全ではない。十分でもない
−全般的なスペシャリストになろう
・教育
−生涯まなぼう
−メンタリングをうけよう
−読書・読書・読書
−AM、ADのメーリングリストにはいろう
http://www.agilemodeling.com/feedback.htm
http://www.agiledata.org/feedback.html
UMLは完全でないに補足をしておくと、先ほどの残すドキュメントの
話でもあるとおり、UMLですべてをあらわせるわけではありませんし、
それですべてを表せるわけではないということを注意しましょうという
ことです。すべてを残すのではなく「モデリング」のために有効なときに
だけ使うだけのもです。
どうでしょうか？私も生まれて初めて海外にきました。英語は一応
一生懸命勉強してあるていどわかるつもりだったのですが
やはり、本場の英語は容赦ない感じで自分の語学力の不足が大変
悔しいです。平鍋さんはさすがでがんがんいっておられました。
以上です。
--------------------------------------------------------------------------------
２．受入テストあれこれ
Salt Lake CityでのAgile Development Conferenceも
日程の大半を過ぎてのこりは１日となりました。
今回の反省としてはやはり英語力不足です。
英語は勉強していったつもりですが、とりあえず
映画を字幕抜きで見て理解できるレベルが必要なようです。
悔しいので今年いっぱいはその能力習得に集中したいと
思っています。
さて、某プロジェクトでも唯一できなかった受入テスト
の自動化に関していろいろまとめてみます。
近年ではWebベースのプロジェクトが増えているのですが、
画面はやはり変わりやすいのでHttpUnitなどをつかっても
JavaScriptが使えないことや変更に弱いことなどあり、
なかなか実際には使えませんでした。
最初に断っておきますが、私のチープな英語力での理解
なので、内容に関しては保証いたしかねます。:-)
■fit and fitness
Ward Cunninguhamのセッションに出席しました。彼のセッション
では、ペアプログラミングをやったのですが、向こうの人には
TDDが浸透しているようで、普通にFake Itなどをやっていたのが
印象てきでした。
さて、fitですが、これは受入テスト用にカニンガム氏が作成
したもので、表ベースで受け入れテストが簡単に作成できるという
ものです。
デモンストレーションでは、Wikiで表を作って、そこに、属性・
メソッドおよび、値と結果を書いていきます。するとその
内容をテストしてくれます。JUnitのようにテストクラスを書かなくても
よいので、ユーザレベルでもそのテストがかけるという特徴
を持っています。
たとえばThiryThreeSixtyというクラスをテストするときは
以下のようなHTMLベースの表を作ります
------------------------------------
| Thirty ThreeSixty |
------------------------------------
|from |to |days() |
------------------------------------
|2001,1,10 |2001,1,20 |10 |
------------------------------------
|2001,1,10 |2001,2,10 |30 |
------------------------------------
この表を含んだHTMLをFITに読み込ませてテストします。
FITはfit.jarというJarファイルに含まれていて
java fit.FileRunner input.html output.html
という感じでテストするとoutput.htmlにテスト結果が追加
されたものが作成されます。
受入テストというものを実感できたきがして大変よかったです。
詳しくは http://fit.c3.com/にあるようです。
■Canoo
個人的にfitよりも強力だなと思ったのがこのCanooです。
CanooはHttpUnitのラッパで、Web画面をテストできます。
テストをXMLで作成するようになっています。
なによりもいいことはJavaScriptにも対応していますし、
フレームの制御をするような画面にも対応しているようで
あるということです。
XMLを単に記述していくだけでテストできますし、
デモでは結構複雑な画面をテストしていました。
関係ないですが、向こうの人から受入テストの様子を
聞く機会があったのですが、受入テスト用の環境を作って
そこでテストを流しているようです。
上記のfitでもそうですが、テストファーストが徹底
している気がしました。
こちらはデモであまり詳細なことはわかりませんが、
とりあえず以下のURLに媒体はありそうです。
また最後にデモをしていた兄ちゃんに「日本語対応してる？」
と聞いてみましたが、「考えてもないからやってみてくれ」
といわれました。ためしてみよ。
http://www.canoo.com/
両方のツールとも思想が違いますが、面白そうです。
fitでユーザがテストをかけるようにするのもあり、
canooでGUIベースの詳細なテストを定義するのもよし、
次回は完全なる受入テストを実施したいなと
思う次第でありました。
以上です