アジャイルモデリング ― XPと統一プロセスを補完するプラクティス
私は、すでにあるいろんなコンテンツをつなげて新たなエクスペリエンスを生み出すサイトを構築する、という業務に携わっています。
そうなると、作るサイトの構成がどうしても複雑になってしまいます。それをうまくスタッフに説明するために、状況遷移図を作るのは必須です。
Powerpointで状況説明して「これが仕様です」と言って済ますわけにはいかないのです。
そうでなくても、企画部門と開発部門で、その考えを一つにするのはなかなか難しいものです。
エクストリームプログラミング（XP）を含むアジャイルモデリングは、新たな開発フローとして注目されているわけですが、そのなかで利用されるUMLを使えば、企画と開発の意思疎通に役立てることができるのでは？と考えついて、そのイキオイで購入してみました。
もしかしたらソフトウエア開発者からしたら、アジャイルモデリングなんて当たり前なのかもしれません。
そこに企画者もこれを理解することで、業務が円滑に進むことが期待できるのではないでしょうか。
とりあえず、いまやっている業務から、仕様書にUMLを利用しています。おおむね好評のようですので、しばらくはこれで行ってみようと思います。
そうなると、作るサイトの構成がどうしても複雑になってしまいます。それをうまくスタッフに説明するために、状況遷移図を作るのは必須です。
Powerpointで状況説明して「これが仕様です」と言って済ますわけにはいかないのです。
そうでなくても、企画部門と開発部門で、その考えを一つにするのはなかなか難しいものです。
エクストリームプログラミング（XP）を含むアジャイルモデリングは、新たな開発フローとして注目されているわけですが、そのなかで利用されるUMLを使えば、企画と開発の意思疎通に役立てることができるのでは？と考えついて、そのイキオイで購入してみました。
もしかしたらソフトウエア開発者からしたら、アジャイルモデリングなんて当たり前なのかもしれません。
そこに企画者もこれを理解することで、業務が円滑に進むことが期待できるのではないでしょうか。
とりあえず、いまやっている業務から、仕様書にUMLを利用しています。おおむね好評のようですので、しばらくはこれで行ってみようと思います。
第1部 アジャイルモデリングへの招待状(導入 アジャイルモデリングの価値 ほか)
第2部 アジャイルモデリングの実践(コミュニケーション アジャイルな文化の育成 ほか)
第3部 アジャイルモデリングとエクストリームプログラミング(誤解の解消 アジャイルモデリングとエクストリームプログラミング ほか)
第4部 アジャイルモデリングと統一プロセス(アジャイルモデリングと統一プロセス 統一プロセスのライフサイクルを通じてのアジャイルモデリング ほか)
第5部 さらに先へ(アジャイルモデリングの採用あるいは逆境の克服 結論:成功するために)
Comments
いや、当たり前じゃないですよ。
ボクもXPまでしか勉強しませんでした。
割と自然とこういうのって実践してたりしますしね。
> とりあえず、いまやっている業務から、仕様書にUMLを利用しています。
と言うか仕様書って何よ。って話あたりから考えたくなりますね、僕は。
設計上、UMLを使うとしたらクラス図、後はたまーにシーケンス図くらいですな。
ユースケースは自分の為に大昔に書いた事もありますが、どうなんでしょうね。
もう一度勉強しなおしてみようかなぁ。
ちなみにマーチン・ファウラー先生のUMLモデリングのエッセンスが私的にはお勧めです。
誰のための何のためのUMLなのかが分かりやすく書かれています。
思うのですが、「プランナー」って、その実いろんな仕事の種類がありながら、それを一まとめにしすぎていると思うのです。
本来なら「○○プランナー」というのが何人もいて、その仕事内容によってそもそも必要とされるプランナーも違うはずですし、書く仕様書も違う。
だから「仕様書」と言ってもいろいろあるのに、その区別がよくわからずに混乱するのかな、と思っています。
UMLの役割ですが、単純にPGさんに「こいつ、システムのことわかってるんじゃないか？」と思わせる（＝騙す）ことができる、というメリットがあります。:-)