koredake modeling accelerates agile
TRANSCRIPT
アジャイルとモデリング
• アジャイルではモデリングは不要なのか?? – アジャイルはドキュメントを書かない、だからモデリングはしない?
– モデリングは開発を遅くする?
• エンタープライズ開発では・・ – 複数のシステムが複雑系を成して絡み合っている – データの移行やらなんやら – 複雑な業務を対象とする
2
スプリントに入る前にやるべきことがたくさんある モデリングなしでは効率的に行えない
スプリント以前のモデリング
• 要求モデル
• 業務をとらえる3種のモデル – サービスモデル、概念モデル、業務フロー
• アーキテクチャモデリング – 主要なパターン(設計クラス図とシーケンス図)とサンプルコーディング
• ユースケース一覧 – プロダクトバックログへの展開
4
スプリント中のモデリング
• 詳細設計のモデルは省略する – 設計者と実装者が同じ – 詳細レベルはコードの方が表現できる
• コミュニケーションのためのメモとしてモデルを多用する – 使い捨て前提
5
言葉より素早いコミュニケーションでアジャイルを加速
リリース後、運用準備のモデリング
• ポリシーによる(紙の形式か情報として残ればいいか) • 主要クラスと主要動作のシーケンス図、特殊なアルゴリズム
• ユーザーストーリーの集約 • ビジネスルールの整理だけは怠りなく
6
要求獲得のためのダイヤグラム
• ビジネスユースケース図(ユースケース図) • 業務フロー図(アクティビティ図) • 概念クラス図(クラス図)
ビジネスユースケース図
概念クラス図 業務フロー図
システムユースケース図
設計クラス図
要求開発(BA)
システム開発
サービスモデル
静的モデル 動的モデル
何をするか
何がどうあるか どう動くか
データ設計図
引出しと共通理解のための概念モデル
• 業務理解の概念モデルでアナリシスパターンを描かない – 抽象化しすぎるとかえって特徴がわからない
• 概念モデルを引きずりすぎない – 使い捨ててもいい – プロセスが重要(引出しのツール) – 無理なトレーサビリティを求めない
• 設計では別の概念が入ってきて折衷できないことが多い • 共通に認識している&残像がある でOK
共通の残像が醸成できれば十分な効果が望める
ビジネスモデリングの効用(よくある感想)
• モデルを描く過程で不足情報を効率よく引き出せた • 個々人がそれぞれに持っていた業務のイメージの違いがよく認識できた。共通認識としてまとめることができた。
• 話し合いだけでは詰め切れなかった曖昧なところを明確にできた
• 何となく色々に使っていた言葉をきっちり定義できた • 関係する業務を広めに議論したことで、システム化スコープの輪郭をはっきりとつかむことができた
• システムイメージが浮かび上がってきた • データ構造がおおまかに見えてきた