アジャイルと設計 / Design in Agile Development

  アジャイルと設計  1 2023年04月18日  株式会社永和システムマネジメント Agile Studio  岡本卓也 

はじめに  1. アジャイル開発でも設計は必要    2. 設計のやり方はどこにも書かれていない  2

設計の目的  1. 記録する  2. 承認する  3. 共有する  3

設計のステップ  1. 調査する  2. 発見する    3. 理解する  4. 共有する 
4

設計のステップ  1. 調査する  2. 発見する    3. 理解する  4. 共有する 
5 ステップ１  ステップ２ 

ステップ１：調査と発見  • 調べる  • 決める  • 一番詳しい人がやる    • 他の人はまだ理解できない 
6

ここでやめるとこうなる  7 工程  工程  工程  工程  工程を設計書でつなぐ 

ステップ２：理解と共有  • 分かったことを書き出す  • 他の人に説明する  • 見直す    • チーム全員が理解している 
8

作るもの  1. ユースケース  2. ドメインモデル  3. アーキテクチャ  KEEPS  しっかり書いて、できればメンテナンスする  9

ユースケース  • 主要なケースだけ書く  • 場面（ユース）を書く  ※機能を書かない  • ユーザを意識する  10

ドメインモデル  11 • 利用者の言葉で書く  • 開発物の抽象を書く  • 書くもの  ◦ 仕事する箱 
◦ 箱の責務  ◦ 最小限のデータ   

アーキテクチャ  12 • 開発者の言葉で書く  • 開発物の具象を書く  • 書くもの  ◦ 利用するサービス 
◦ フレームワーク  ◦ それらの連携   

オススメの順番  13 ユーザーストーリーマッピング（または要件定義書）   ユースケース  ドメインモデル  アーキテクチャ 

なぜモデルを使うのか？  14

なぜUMLを使うのか？  • 特に強い理由はない    • オレオレ記法よりは混乱が少ない  ◦ 書くための目的と記法に一定のルールがある  ◦ それらの知見は世の中にあるので学習可能 
◦ 細かいルールは無視してOK  15

ポイント  • 全てを設計しない  • 変わりにくい部分にフォーカスする  • 作成には時間をかけない  • 説明には時間をかける  16

設計の目的  1. 記録する  2. 承認する  3. 共有する  4. 会話を誘発する  17

参考  • 【アジャイル時代のモデリング①】システムの「全体像」の理解共有がなぜ必須なのか   • 【アジャイル時代のモデリング②】共通理解を作るための、最もシンプルなモデルセット  • アジャイル開発の中の設計    18

おしまい  19

岡本卓也