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 アジャイル？
• 何をどうモデリングする？
• アジャイルモデリング
– 導入
– アジャイルモデリングの原則
– アジャイルモデリングのプラクティス
– カオスで秩序なアジャイルモデリング
• モデルでコミュニケーション
• インクリメンタルにモデリング
• やってみよう !
• まとめ
4Agile Japan 2013 Satellite Nagoya

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

アジャイルっていうと
• 人間系
– SCRUM
– 自己組織化されたチーム
– プロジェクトファシリテーション
• 実装に近いところ
– CI (Continuous Integration)
– ビルド、テストの自動化
– TDD (Test Driven Development)
– リファクタリング
こんな話が主に取り上げられている

でも我々は“分析・設計”をする
• 顧客のビジネス価値がゴールなんだから
– 対象のビジネスを理解する
• それを可視化する
– 何を作るかを考える
• どう考えてるのかをわかるようにする
– どう作るかを考える
• どう作ろうとしてるのか（作ったのか）をわかる
ようにする
という事はいつでも必要で、やっている

そこで “モデリング X アジャイル”
• 理解する・思考する
• 表現する・意思疎通する
これらをモデルを使って、
サクっと軽量かつ効果的にやる！
という事にフォーカスしてみました

これは忘れない
• 我々は「モデル開発者」でも「ドキュメント開発者」でもない
• 動くソフトウェアを作る為にモデリングするものなり
アジャイルソフトウェア開発宣言
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分
class 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

ポモドーロテクニック
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

書籍紹介 #2
• エリック・エヴァンスのドメイン駆動設計
– http://amzn.to/14nDOBz
• オブジェクト開発の神髄~UML 2.0を使ったアジャイル
モデル駆動開発のすべて
– http://amzn.to/18YeG7i
• アジャイルモデリング―XPと統一プロセスを補完する
プラクティス
– http://amzn.to/14nFCdA
• アジャイルな時間管理術ポモドーロテクニック入門
– http://amzn.to/165omOD

ありがとうございました

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

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

Ähnlich wie Agile japan 2013 サテライト＜名古屋＞モデリング x アジャイル (20)