2014年3月6日木曜日

DAD本読書会#4に参加しました

DAD本読書会#4 @21cafe

DAD本こと、「ディシプリンド・アジャイル・デリバ​リー エンタープライズ・アジャイル実践ガイド」の
読書会#4です。
今回は、監修者の藤井さんに質問して、お話を聞いたり、みんなでディスカッションする方式でした。
DAD本勉強会ですが、RUPの話で盛り上がってしまいました。
以下、メモです。
誰がしゃべったのかは、もう覚えてませんので、藤井さんの見解とズレもあると思いますので、ご注意を。

方向付けフェーズ

方向付けフェーズは重厚じゃない。ゆるいRFPをつくるイメージ。

お客様がアジャイルについてわかっていないとDADを提案するのは難しい?
教育をして、DADでできるか判断する。
RFPでてからだと遅い。

検討不足と学習や発見との違いは?

そもそも、検討不足と学習や発見の分類に意味がない。
抜けが見つかってよかったと言えばいい。
結果的に価値のあるものをつくるために、つくってみて、動くものをみた方が抜けを見つけやすいことが多い。

推敲フェーズ

Unified Processの「アーキテクチャ中心」は捨てた?

なんでDADでは推敲フェーズがないのか?

出版前には推敲フェーズがあった。
Unified Processの「アーキテクチャ中心」を完全に捨てた訳ではない。
アーキテクチャを初期に確定させるのはNGだけど、変える前提で、ある程度アーキテクチャの見通しをたてて、リスクを潰すという発想。
そうなると、フェーズとして残さない方がよいという判断だと思う。

XPではアーキテクチャをはじめに考えない?

Kent Beckはテクニカルなリスクを優先順位に一切考慮しないと言っていて、Martin Fowlerは少しは考慮すると言っている。
このレベルの人たちは、飛行機の中でxUnitつくっちゃう人だから、頭のなかでアーキテクチャのこともちゃんと考えてるから崩壊しない。
DADでも他でもそうだが、stabilizationという機能を追加しないでアーキテクチャの整合をとるためのイテレーションを設けることがある。
大規模開発や金融系の開発をバックボーンに持つ人はアーキテクチャを重視する傾向にある。

DADは合意を重視

DADはアジャイルスケーリングモデルの中間。
意思決定やコミュニケーションの仕方を整理している。
常に早くリスクヘッジする。
それがビジネスリスクかテクニカルリスクかは問わない。
重要なのはそれを合意すること。
フェーズの区切りは、合意ができていること。

WaterfallとUnified Processは何が違う?

Waterfallで1次開発、2次開発とやっていたら、繰り返し。
Waterfallはアーキテクチャを重視する。
そもそも、ロイズの論文ではWaterfallは規模が大きい時は2回は繰り返すと言っている。
だったら、WaterfallとUnified Processは何が違う?

ユースケース駆動

UPの「ユースケース駆動」、「アーキテクチャ中心」、「インクリメンタルかつイテレーティブ」の3つで残るのは、ユースケース駆動。
あとは、1年を2回とかで反復と言えるか?

日本での大規模開発はRUPがいい

RUPはヘビーという誤解がある。
RUPは成果物を決めているが、成果物は紙ではない。
決めなければいけないことを定義しているだけ。
アジャイル開発でプロジェクトを進めるときは、バラバラの要素を組み合わせる必要がある。
RUPはまとまっている中から省いていく。
そうとらえると、日本の大規模開発では、RUPがあっているように思う。

業務システムでアジャイル開発は難しい?

業務システムは機能も多いし、ある程度まとまらないと評価できないので、アジャイル開発が難しいのでは?
BPRをしたいが、ステークホルダーが多くて、かつ、ITリテラシーが低い人ばかりなので、使わせて確認しながらやりたいというお客様の要望でやってうまくいったことがある。
業務システムという区切りではなく、何をしたいかが重要。
ゴールが不明確でアジャイルと言っているケースが多い。
BPRしたいとか、変えたいという意思がないとアジャイル開発する意味は無い。

大規模ではアジャイル開発は難しい?

なんで大規模だとアジャイル開発は難しい?

意思決定が難しいのでは?

Waterfallでも意思決定しているはず。ものを見せずに意思決定できるのなら、ものを見せたらもっと意思決定がしやすいはずでは?
みせる人数が多くて大変だったり、みせると意見がですぎてまとまらないのでは?
人数については、機能ごとに対象者は絞られるので、そうでもない。
ただし、バラバラにでた意見のまとめ役は必要。
意見はいっぱいでていい。
くだらない意見がいっぱいでて、実際に動くものをみると、くだらないことがわかるようになる。

複数システム、プロジェクトと連携するマルチベンダーの場合は?

アジャイル開発というかイテレーション開発になるが、統合リスクを管理するために、定期的に統合するメリットはある。

感想

アジャイル開発の勉強会で出席者がSIの人ばっかりってのはめずらしい。
貴重な場です。

あと、21cafe。すごくおしゃれで、無料。すばらしい!
いつか自分もここで勉強会を主催したいなぁ。

お礼

藤井さん、21cafeさん、ステッカーありがとうございました!

0 件のコメント:

コメントを投稿