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 and casual astah models

アジャイル時代のモデリングと astah* のサクサク活用

  • Be the first to comment

Modeling in the Agile Age and casual astah models

  1. 1. 平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 福井で受託開発を続けながら、アジ ャイル開発を推進し、国内外で、モ チベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフ トウェアづくりの現場をより⽣産的 に、協調的に、創造的に、そしてな により、楽しく変えたいと考えてい る。アジャイルジャパン初代実⾏委 員⻑。
  2. 2. Agile と Design
  3. 3. INPUT OUTPUT Where is Design?
  4. 4. “While code is the truth, it is not the whole truth.” -Grady Booch コードは真実である。しかし、真実のすべてではない。
  5. 5. 成長しつづけるが、 一貫した美がある。
  6. 6. Design Upfront ? 設計なし NDUF 重厚な設計 BDUF ⼗分な設計 ENUF! ENough Design Upfront Big Design UpfrontNo Design Upfront http://www.business2community.com/strategy/is-your-shipping-documentation-all-at-sea-0388206
  7. 7. アーキテクチャのスイートスポット 開発時間 アーキテクチャ設計とリスク解決の時間 修正時間(⽋陥の修正、書き直し、間違い) 全体のプロジェクト時間 備考: アーキテクチャ設計に使った時間は開 発を加速し修正作業の時間を減らす Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨)
  8. 8. sweet spot アーキテクチャ設計とリスク解決のための時間 全体に追加された時間 アーキテクチャと アジャイルのバランス Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨) アーキテクチャ設計 修正作業
  9. 9. Barry Boehm et. al : Architected Agile Solutions for Software-Reliant Systems
  10. 10. アジャイル適正 メンバ 要求変化 企業⽂化メンバ数 クリティカルさ 3 5 3 0 2 5 2 0 1 5 0 1 0 2 0 3 0 4 0 (1B%) (L2,3 %) (変更/⽉(%))1 5 1 0 3 0 5 0 9 0 7 0 5 0 3 0 1 0 3 1 0 3 0 10 0 30 0 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル メンバ 要求変化 企業⽂化メンバ数 クリティカルさ 3 5 3 0 2 5 2 0 1 5 0 1 0 2 0 3 0 4 0 (1B%) (L2,3 %) (変更/⽉(%))1 5 1 0 3 0 5 0 9 0 7 0 5 0 3 0 1 0 3 1 0 3 0 10 0 30 0 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル Project A Project B “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001)
  11. 11. Agile Modeling • By Scott Ambler
  12. 12. “Letʼs keep the modeling baby but throw out the bureaucracy bathwater” – Scott Ambler お湯を抜いても、⾚ちゃんまで流さないように。
  13. 13. なぜモデルを使うのか ? • ⼈間はイメージの⽅が概要をうまく 掴むことができる。 –A picture is worth 1,000 words. –右脳と左脳
  14. 14. Elephant http://byuevaluation.wordpress.com/anneke/ Rope? Wall? Tree? Snake?
  15. 15. どんなモデルが コードの次に必要か
  16. 16. 問題 「ビッグピクチャ」の共通理解をつくる ために、⼀番シンプルな、モデルのセッ トとは何か?
  17. 17. KEEPS 残すもの TEMPS 捨てるもの
  18. 18. “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
  19. 19. “Temps” • Casual Modeling • Ex. As Class+Sequence Diagrams, and others • “Keeps”の上に乗せる (ツールを使ったり、印刷の上に書いたり) • ホワイトボード! Picture from: Craig Larman
  20. 20. “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
  21. 21. Architecture • システム全体の構造的な表現 • ⼤域的な層(Tier)が表現されることが多く、 クラス図やパッケージ図がよく使われる。 • よく知られたパターンが存在する。 – MVC, Blackboard, Pipes-Filters, Layers • 「フレームワーク」を使うのもアーキテク チャ選択の1つ。
  22. 22. Pattern-Oriented Software Architecture (Vol.1-5) • By Frank Buschmann et. al
  23. 23. ドメインモデル • 問題領域(ドメイン)の概念とそれらの繋がり • ⼈間のコミュニケーション・レベル – 全ステークホルダーが話す語彙。 – ユーザー、ドメインの専⾨家、ビジネス分析、開発者 • プログラミング・レベル – コードを構成する要素(クラス、データ、変数、操作、 ファイル、、、、)の「名前づけ」 – それらの多くが永続データ(entity)や値(value object)に マッピングされる。
  24. 24. Domain-Driven Design • By Eric Evans • Ubiquitous Language
  25. 25. 「寿司」のドメインモデル
  26. 26. Key UseCases 1. ユーザーから⾒たシステムの代表的な使い⽅ • 誰がユーザーで、何がうれしいか。 2. そのゴールを得るまでのアーキテクチャを貫 通するメカニズム • シーケンス図やコミュニケーション図によって 描かれる、制御の流れ。 • 開発者には教育的な例⽰となる。
  27. 27. ここまでで質問どうでしょう︖
  28. 28. astah* を例に
  29. 29. 35 (イアフォンを外す)
  30. 30. “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
  31. 31. “Architecture”の例 Package とその責務のコメント 依存関係
  32. 32. “Domain Model”の例 クラス アクター ユースケース
  33. 33. “Key UseCases”の例 ユーザー(役割) 典型的な使い方 この例だけ メカニズムがある
  34. 34. “Key UseCases”の例(メカニズム)
  35. 35. “Keeps”上に“Temps”を重ねる Drag&Drop
  36. 36. Scaling and Knowledge
  37. 37. “Rather than divide and conquer, an XP team conquers then divides” –Kent Beck XPチームは、「分割→統治」でなく「統治→分割」する。
  38. 38. “Model to have a conversation.” –Craig Larman and Bas Vodde 会話のために、モデリングしよう。
  39. 39. 他に Keepすべきもの ⼤事なこと…
  40. 40. Others to Keep • 設計の理由 (WHYʼs) = ADR(Architecture Decision Record) – 意思決定の理由リスト – なぜこのフレームワークを選んだか。 – なぜこのテクノロジを選んだか。 – なぜこの設計、アーキテクチャなのか。 – 考慮した別の設計案とメリデメ。 • テスト戦略 – API as Acceptance Test Interface
  41. 41. Tips • プロジェクタ – ツールとホワイトボードを組み合わせて • ふりかえり – ⾃分たちのベスト “Keeps” セットをさがせ。 • リバースエンジニアリング – 現在のコードベースを可視化。 • マインドマップ
  42. 42. ⼤事なこと • 「ふりかえり」を使ってチームによって ベストな “KEEP” セットを探せ。 • いらないモデルはないか︖ • 何か有⽤な情報がもれていないか?
  43. 43. Mind Map モデリング
  44. 44. User Interview Mindmap Modeling
  45. 45. Impact Mapping
  46. 46. 55
  47. 47. サクサク astah*
  48. 48. まとめ • 設計はソフトウェア開発においてこれまでもっと も⼤事な部分であるし、アジャイル開発でも、 もっとも⼤事な部分であり続けている。 • もっともシンプルなモデルセットを選び、それら をメンテナンスする。そして他のものはコードと テストにしてしまう。 • ふりかえり、で⾃分たちに合った KEEPSを選ぶ。 • 会話のためにモデルを利⽤ • “Divide and Conquer” でなく “Conquer THEN Divide” • 形式化しにくいアイディアには、マインドマップ を利⽤。
  49. 49. InfoQ Kenji modeling
  50. 50. 最後に
  51. 51. “A lot of design information lives in tribal memory.” –Grady Booch
  52. 52. 式年遷宮(Shikinen-Sengu) http://savingjapan.net/2011/06/23/jft-press-release-shikinen-sengu-ceremonial-rebuilding-for-over-1300-years/ http://4travel.jp/travelogue/10135766 http://blogs.yahoo.co.jp/internationalestory/64231621.html Move the Shrine Every After 20 years
  53. 53. astah system safety 安全論証 ⾮故障・性能限 界安全分析 UML の MBSE拡張対応 ⾃動運転テスト シナリオ 26262レビュー
  54. 54. 99 astah この後、本⽇のかんたんなアンケートをお送ります。 お答えいただいた⽅には、本⽇の資料と追加情報URL等をお送りします。

    Be the first to comment

  • m-fuji

    Jun. 4, 2020
  • stani384

    Jun. 9, 2020

アジャイル時代のモデリングと astah* のサクサク活用

Views

Total views

1,081

On Slideshare

0

From embeds

0

Number of embeds

243

Actions

Downloads

8

Shares

0

Comments

0

Likes

2

×