Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modeling in the Agile Age - JP

16,945 views

Published on

アジャイル時代のモデリング

Published in: Technology
  • Be the first to comment

Modeling in the Agile Age - JP

  1. 1. アジャイル時代の アジャイル時代の モデリング モデリング 平鍋健児 チェンジビジョン 平鍋健児 チェンジビジョン
  2. 2. 自己紹介
  3. 3. 自己紹介 • ㈱永和システムマネジメント – 福井市(本社)、上野東京(支社) – Ruby と Agileを使ったシステム開発 • 株式会社チェンジビジョン – 福井市(開発部)、上野東京(本社) – astah* (旧:JUDE) の開発 • 平鍋健児 – UML+マインドマップエディタ astah*の開発 – 要求開発アライアンス、 事 – 翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に つマインドマップ』
  4. 4. Agile と Design
  5. 5. “While code is the truth, it is not the whole truth.” -Grady Booch
  6. 6. 成長しつづけるが、 一貫した美がある。
  7. 7. Design Upfront ? NDUF BDUF
  8. 8. Agile Modeling • By Scott Ambler
  9. 9. “Let’s keep the modeling baby but throw out the bureaucracy bathwater” – Scott Ambler
  10. 10. なぜモデルを使うのか ? • 人間はイメージの方が概要をうまく 掴むことができる。 –A picture is worth 1,000 words. –右脳と左脳
  11. 11. Elephant
  12. 12. どんなモデルが コードの次に必要か
  13. 13. 問題 • 「ビッグピクチャ」の 通 解をつくるために、一番シン プルな、モデルのセットとは 何か?
  14. 14. “Keeps” • Architecture • As Class/Package Diagrams • Domain Model • As Class Diagram/ER Diagrams • Key Use Cases • 1. As Use Case Diagrams • 2. As Sequence/Communication Diagrams
  15. 15. “Temps” • Casual Modeling • Ex. As Class+Sequence Diagrams, and others • “Keeps”の上に乗せる (ツールを使ったり、印刷の上に書いたり) • ホワイトボード!
  16. 16. “Keeps” (again) • Architecture • As Class/Package Diagrams • Domain Model • As Class Diagram/ER Diagrams • Key Use Cases • 1. As Use Case Diagrams • 2. As Sequence/Communication Diagrams
  17. 17. Architecture • システム全体の構造的な表現 • 大域的な層やTierが表現されることが多く、 クラス図やパッケージ図がよく使われる。 • よく知られたパターンが存在する。 – MVC, Blackboard, Pipes-Filters, Layers • 「フレームワーク」を使うのもアーキテク チャ選択の1つ。
  18. 18. Pattern-Oriented Software Architecture (Vol.1-5) • By Frank Buschmann et. al
  19. 19. “Architecture”の 責務 依存関係
  20. 20. ドメインモデル • 問題 域(ドメイン)の概 とそれらの がり • 人間のコミュニケーション・レベル – 全ステークホルダーが話す語彙。 – ユーザー、ドメインの専門家、ビジネス分析、開発者 • プログラミング・レベル – コードを構成する要素(クラス、データ、操作、ファイ ル、、、、)の「名前づけ」 – それらの多くが永続データ(entity)にマッピングされる。
  21. 21. Domain-Driven Design • By Eric Evans • Ubiquitous Language
  22. 22. “Domain Model”の
  23. 23. 「寿司」のドメインモデル
  24. 24. Key UseCases 1. ユーザーから たシステムの代表的な使い方 • 誰がユーザーで、何がうれしいか。 2. そのゴールを得るまでのアーキテクチャを貫 通するメカニズム • シーケンス図やコミュニケーション図によって かれる、 の れ。 • 開発者には 的な となる。
  25. 25. “Key UseCases”の ユーザー(役割) 典型的な使い方 この例だけ メカニズムがある
  26. 26. “Key UseCases”の (メカニズム)
  27. 27. “Keeps”上に“Temps”を重ねる
  28. 28. Scaling
  29. 29. Scaling • By Craig Larman + Bas Vodde
  30. 30. “Rather than divide and conquer, an XP team conquers and divides” –Kent Beck
  31. 31. “Model to have a conversation.” –Craig Larman and Bas Vodde
  32. 32. 他に Keepすべきもの
  33. 33. Others to Keep • 設計の (WHY’s) –意 の リスト – なぜこのフレームワークを選んだか。 – なぜこのテクノロジを選んだか。 – なぜこの設計、アーキテクチャなのか。 • テスト – API as Acceptance Test Interface • しかし、… 「人」“People” なのだ…
  34. 34. “A lot of design information lives in tribal memory.” –Grady Booch
  35. 35. 式 (Shikinen-Sengu)
  36. 36. Tips
  37. 37. Tips • プロジェクタ – ツールとホワイトボードを組み合わせて • ふりかえり – 自分たちのベスト “Keeps” セットをさがせ。 • リバースエンジニアリング – 現在のコードベースを可視化。 • マインドマップ
  38. 38. ふりかえり • Keepするモデルは文脈依存する • やってみてチームで合意。 やってみて うまく行った Keep Try 定着 Problem うまく行かない 新しい問題! 解決法 新しいアイディア! ふりかえりがカイゼンを導く
  39. 39. Mindmap Modeling
  40. 40. Impact Mapping
  41. 41. まとめ • 設計はソフトウェア開発においてこれまでもっとも大事な 部分であるし、アジャイル開発でも、もっとも大事な部分 であり続けている。 • もっともシンプルなモデルセットを選び、それらをメンテ ナンスする。そして他のものはコードとテストにしてしま う。 • 自分たちのKeepをさがせ。 • 会話のためにモデルを • “Divide and Conquer” でなく “Conquer THEN Divide” • 式化しにくいアイディアには、マインドマップを 。
  42. 42. Search: InfoQ Kenji

×