Download - Agile japan 2013 サテライト＜名古屋＞モデリング x アジャイル

モデリング X アジャイル

2013/5/24 Yasushi Hagai

名古屋アジャイル勉強会

Agile Japan 2013 サテライト＜名古屋＞

自己紹介

羽飼康（ハガイヤスシ）

フリーランスのITエンジニア

名古屋アジャイル勉強会スタッフ

認定スクラムマスター

@onestepbeyond_y

Agile Japan 2013 Satellite Nagoya 2

ATTENTION

本資料は後日公開致します

資料の内容について全ての

メモを取る必要はありません


AGENDA

• なぜモデリング X アジャイル？

• 何をどうモデリングする？

• アジャイルモデリング – 導入

– アジャイルモデリングの原則

– アジャイルモデリングのプラクティス

– カオスで秩序なアジャイルモデリング

• モデルでコミュニケーション

• インクリメンタルにモデリング

• やってみよう !

• まとめ

4 Agile Japan 2013 Satellite Nagoya

なぜモデリング X アジャイル？


アジャイルっていうと

• 人間系

– SCRUM

– 自己組織化されたチーム

– プロジェクトファシリテーション

• 実装に近いところ

– CI (Continuous Integration)

– ビルド、テストの自動化

– TDD (Test Driven Development)

– リファクタリング


こんな話が主に取り上げられている

でも我々は“分析・設計”をする

• 顧客のビジネス価値がゴールなんだから –対象のビジネスを理解する

• それを可視化する

–何を作るかを考える • どう考えてるのかをわかるようにする

–どう作るかを考える • どう作ろうとしてるのか（作ったのか）をわかるようにする

という事はいつでも必要で、やっている


そこで “モデリング X アジャイル”

• 理解する・思考する

• 表現する・意思疎通する

これらをモデルを使って、

サクっと軽量かつ効果的にやる！

という事にフォーカスしてみました


これは忘れない

• 我々は「モデル開発者」でも「ドキュメント開発者」でもない

• 動くソフトウェアを作る為にモデリングするものなり


アジャイルソフトウェア開発宣言

http://agilemanifesto.org/iso/ja/

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする

http://agilemanifesto.org/iso/ja/

何をどうモデリングする？


モデルとは何か？

「ある人にとっての、ある状況、あるいはある状況についての概念

の、明示的な解釈」


『システム仕様の分析学』著者、ブライアン・ウィルソン曰く

これを、“図”などを使って表現している

もうちょっとわかりやすく

• 仕組みや原理を理解したり説明したりするために、それに関わる最小の要素と、それらがお互いにどう関わるかを記述する - UMLモデリングの本質第2版 –


モデリングの目的

• 開発する内容を理解するため

–自分が何を作るかという事を考える

• 開発チーム内と利害関係者の意思疎通のため

–チーム内外との“コミュニケーション”


モデリングの手法

• 同じ切り口、同じ目的のモデルが書く人によって表現がバラバラなのはとても不便

• そこでUML(Unified Modeling Language)等の手法を使う


切り口・目的に合わせたモデル・ダイアグラム

• 業務分析だったら

– アクティビティ図

– ビジネスユースケース図

• 要求分析だったら

– SysMLの要求図

– ユースケース図

– ペルソナ

– ユーザーストーリー

• プログラム設計だったら

– クラス図

– シーケンス図

– CRCカード (Class-Responsibility-Collaborator)


手法・仕様というのはいつもfat

• UMLには13種類のダイアグラム

• SysMLなんてのも出てきたり


必要な物を限定的に使えばいい

たとえばこんな感じ

1. ドメインモデル + ユースケース

–登場する要素をドメインモデルとして書く

–ドメインモデルの言葉を使ってユースケースシナリオを書く

2. 設計クラス + シーケンス

–ユースケースシナリオの実現をモデリング

–設計クラスとシーケンスは同時進行


今日はモデリング x アジャイル

• インクリメンタルにモデリングする

• そして実装する

• モデルによるコミュニケーション


というのを体感してみましょう！

チーム分けと自己紹介


• チーム内で自己紹介をしてください

• 自分の”ある側面”をクラス図として表現してみましょう

• そしてそのモデル使って自分自身をチームのメンバーに説明してください

自己紹介クラスはこんな感じ

• モデルを書く – 5分

• チームメンバーに説明 – 5分


clas s Package1

ダメなおっさん

- カメラさんたち- レコードさんたち

+ 山に登る() :void+ 自転車に乗る() :void+ 音楽を聴く() :void+ 写真を撮る() :void

アジャイルモデリング - 導入 -


アジャイルモデリングとは

• アジャイルモデリング(AM)は、ソフトウェアシステムの効果的なモデリングとドキュメントのための、

カオス秩序的(chaordic)な

プラクティスに基づく方法論

• AMは、感覚的なものでなく、また、ガチガチの規則でもない

• AMは、科学ではなく技能

• Scott W. Ambler 2003


AMの3つの目的

1. 軽量で効果的なモデリングを行うためのプラクティスを定義し、それらを裏付ける原則や価値を定義し、示す。

2. eXtreme Programming, SCRUMのようなアジャイルなアプローチを適用したプロジェクトでモデリング手法をどのように使うかを探求する。

3. ラショナル統一プロセス(RUP)やエンタープライズ統一プロセス(EUP)のようにきっちりと定められたプロセスでモデリングをよりよく行う方法を探究する。


アジャイルなモデルとは

1. 目的を満たしている

2. 理解できる

3. そこそこ正確である

4. そこそこ一貫性がある

5. そこそこ詳しい

6. 労力を上回るプラスの価値をもたらす

7. 出来るだけ簡潔になっている


アジャイルなモデルは、

アジャイルなモデルとは

“かろうじて役に立つモデル”


アジャイルモデリングとは何であり何でないか

1. 姿勢であり、きっちりと定められたプロセスにあらず。

2. 既存の方法論を補うものであり、完全な方法論にあらず。

3. 利害関係者の要望を満たすために効果的にチームワークを行う方法なり。

4. 効果的であり、効果的になる道なり。

5. 実務に使えるものであり、学術的な理論にあらず。

6. 銀の弾丸にあらず。

7. 平均的な開発者のものなれど、有能な開発者を代替するものにあらず。

8. 説明資料の否定にあらず。価値あるドキュメントを作ることを推奨するものなり。

9. CASEツールの否定にあらず。

10.万人に対するものにあらず。


AMは、

アジャイルモデリングの価値


アジャイルモデリングの価値とは

1.コミュニケーション

2.簡潔さ

3.フィードバック

4.勇気

5.謙虚さ


eXtreme Programmingの価値に“謙虚さ”を加えたもの

• この頃(2003)はXPの5つ目、”尊敬“はまだない

• AMでは“謙虚さ (Humility) ”を加えた

• その後XPでは”尊敬(Respect)”が加わった


アジャイルモデリングの原則


基本原則 #1

1.ソフトウェアが第1のゴール

2.次への備えが第2のゴール

3.身軽な旅

4.簡潔さを心がけよう

5.変化を受け入れよう

6.少しずつ変更する


基本原則 #2

7.目的を持ってモデリングしよう

8.複数のモデル

9.質の高い仕事をしよう

10.素早いフィードバック

11.利害関係者の投資を最大限に生かそう


追加原則

1. 見栄えより中身

2. 誰しも他人から学べる

3. モデルを知ろう

4. 実情に合わせよう

5. オープンで正直なコミュニケーション

6. 直感に従って開発しよう

7. 道具を知ろう


AMは“姿勢”

• これらの原則からわかるように、プロセス・成果物の定義につながる物はない

• モデリング手法そのものではなく、アジャイルにモデリングするための原則


アジャイルモデリングのプラクティス


基本プラクティス #1 • 反復的でインクリメンタルなモデリングの為のプラクティス

1.適切な成果物を使おう

2.複数のモデルを平行して使おう

3.他の成果物に移ろう

4.少しずつモデリングしよう

• 効果的なチームワークの為のプラクティス

5.他の人と一緒にモデリングしよう

6.利害関係者の積極的な参加

7.共同所有

8.モデルを公開しよう


基本プラクティス #2

• 簡潔さを可能にするプラクティス

9.中身はシンプルに作ろう

10.モデルはシンプルに書こう

11.最も簡単な道具を使おう

• モデルを検証するためのプラクティス

12.テストできるか考えよう

13.コードで確かめよう


追加プラクティス

• 生産性を向上させるプラクティス

1. モデリング標準を適用しよう

2. パターンを控えめに使おう

3. 既存の資源を再利用しよう

• アジャイルなドキュメントに関するプラクティス

4. 一時的なモデルは捨てよう

5. 取り決めモデルはきちんと定義しよう

6. 困ったときだけ更新しよう

• 動機に関するプラクティス

7. 理解するためにモデリングしよう

8. 話すためにモデリングしよう


軽量であること・コミュニケーション重視のプラクティス

• モデルが重荷になってはいけない

–必要な物を必要な分だけ

• 生産的なコミュニケーション

–いつでも見られる・誰でも触れる

–共同作業によって共通理解が得られる

–そこに利害関係者も巻き込めば合意形成も

• 実装して確認

–そのモデルは絵に描いたモチかもしれない


カオスで秩序なアジャイルモデリング


AMの価値・原則・プラクティス

• 価値は理念

• 原則は指針

• プラクティスは価値・原則から導き出されたAMの核心となる手法


AMはカオス秩序的なプラクティスベースの方法論

• AMは一見カオスのように無秩序

• しかし、 AMは共通の価値・原則を指針として協調する人々が、指図ではなく舵取りをする為のものであり、効

果的で有効な作業習慣を重視するというものである →

秩序

• 決めごととしては緩い、が「なにやってるかわかんない」にはならない（そうなってたらAMではない）


モデルでコミュニケーション


どうやってコミュニケーション？

1. 複数人でモデリングする

– 話し合いながら決めてゆく

– 1人でモデリングしたとしても、すぐに（溜めこまずに）他の人の意見を求める

2. 利害関係者の（モデリングへの）参加

– 業務知識・見解の共有

3. 共同所有

– チームの誰でも変更可能

4. モデルを公開

– 壁などに掲示していつでも見られるように


円滑なコミュニケーションの為に

• UML等の標準の採用

– 素早い共通の理解の為の共通の記法

• 粒度・抽象度の決めごと

– ユースケース、ユーザーストーリーなどは、形を合わせても中身の粒度・抽象度は定まらない

• 生きた言葉で

– 関係者間で、同じ意味で理解される言葉（ユビキタス言語）

• 道具を選ぶ

– 意見を出し合うのには、ホワイトボードどペン、壁と付箋紙などが大活躍する


インクリメンタルにモデリング


広い世界は今見なくていい

• モデリングの対象を不必要に広げない

–例えば「書籍を検索」がモデリングする対象なのであれば、ひとまずそれだけ考える

• 「書籍」という存在を考えたらどんどん世界は広がってしまうかもしれない

• 後に別の要求から「書籍」を拡張する必要があればその時すればよい


動くソフトウェアを作るためのモデル

• モデル開発じゃない

–モデルは実装するためにある

–実装されない（できない）モデルに価値なし

–『モデリング→ 実装』を繰り返すべし


やってみよう


実際にやってみましょう

• いくつかのお題を実際にモデリングして実装してみましょう

–モデリングは手書きで行います

–実装はScratchを使います

–ポモドーロテクニックを使って集中してやってみましょう


実際にやってみましょう #1

• モデルを使ってコミュニケーション

• インクリメンタルに、モデリング → 実装

この2点を意識してやってみましょう！


Scratch

• ScratchはMITで開発された小学生にも使える教育用のプログラミング環境です。

– スプライトと呼ばれる絵に動きを与えることができます。

– クラスの継承はできません。

– スプライトはインスタンスなので、同じ型の別のインスタンスは作れません。

– コピーは出来ます。

– ブラウザ上で動きます。

– http://scratch.mit.edu


http://scratch.mit.edu/

ポモドーロテクニック

25分集中したら5分休む


本日のお題

•飲料の自動販売機をモデリング、実装します

• 簡単な仕様からだんだん複雑な仕様になっていきます


モデリング＋実装 #1

• ペットボトルの飲料を1種類扱う自動販売機

– 飲料のお値段は100円

– 100円玉しか受け付けません

– 100円を入れてボタンを押したら飲料が出てきます

– 上記以外を考慮しなくていいです（在庫管理とかは考えなくていい）


モデリング＋実装 #2

• ペットボトルの飲料を2種類扱う自動販売機

– 飲料Aのお値段は100円

– 飲料Bのお値段は120円

– 100円玉と500円玉を受け付けます

– もちろんおつりが出てきます

– 連続購入はありません


モデリング＋実装 #３

• カップのコーヒーを2種類扱う自動販売機

– コーヒーAのお値段は100円

– コーヒーBのお値段は120円

– 100円玉と500円玉を受け付けます

– おつりが出てきます

– 砂糖の量が選べます（多め・普通・少なめ・なし）

– ミルクの量も選べます（多め・普通・少なめ・なし）

– 注文を受け付けたら、豆を挽いて抽出します

– 待ってる間に音楽が鳴るといいですね

– カップを取り出さないと次の購入はできません


まとめ


本日やってみたのはこんな事

• 少しずつ・インクリメンタルに

• 簡単な道具を使って

• シンプルに

• 身軽に

• モデルを使ったコミュニケーション

共同作業による共通理解


書籍紹介 #1

• UMLモデリング入門本質をとらえるシステム思考とモデリング心理学

– http://amzn.to/12Gud8k

• UMLモデリングの本質第2版良いモデルを作るための知識と実践

– http://amzn.to/14nDbrC

• ユースケース実践ガイド―効果的なユースケースの書き方

– http://amzn.to/10PHF6K

• ユースケース駆動開発実践ガイド

– http://amzn.to/19UKKqd


http://amzn.to/12Gud8k

http://amzn.to/14nDbrC

http://amzn.to/10PHF6K

http://amzn.to/19UKKqd

書籍紹介 #2

• エリック・エヴァンスのドメイン駆動設計

– http://amzn.to/14nDOBz

• オブジェクト開発の神髄~UML 2.0を使ったアジャイルモデル駆動開発のすべて

– http://amzn.to/18YeG7i

• アジャイルモデリング―XPと統一プロセスを補完するプラクティス

– http://amzn.to/14nFCdA

• アジャイルな時間管理術ポモドーロテクニック入門

– http://amzn.to/165omOD


http://amzn.to/14nDOBz

http://amzn.to/18YeG7i

http://amzn.to/14nFCdA

http://amzn.to/165omOD

ありがとうございました


Download - Agile japan 2013 サテライト＜名古屋＞ モデリング x アジャイル

Top Related

Download - Agile japan 2013 サテライト＜名古屋＞モデリング x アジャイル