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

2023/04/18
社内発表資料

Transcript

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

2. はじめに
 1. アジャイル開発でも設計は必要
 
 2. 設計のやり方はどこにも書かれていない
 2
3. 設計の目的
 1. 記録する
 2. 承認する
 3. 共有する
 3
4. 設計のステップ
 1. 調査する
 2. 発見する
 
 3. 理解する
 4. 共有する
 4
5. 設計のステップ
 1. 調査する
 2. 発見する
 
 3. 理解する
 4. 共有する
 5 ステップ１
 ステップ２

6. ステップ１：調査と発見
 • 調べる
 • 決める
 • 一番詳しい人がやる
 
 • 他の人はまだ理解できない
 6
7. ここでやめるとこうなる
 7 工程
 工程
 工程
 工程
 工程を設計書でつなぐ

8. ステップ２：理解と共有
 • 分かったことを書き出す
 • 他の人に説明する
 • 見直す
 
 • チーム全員が理解している
 8
9. 作るもの
 1. ユースケース
 2. ドメインモデル
 3. アーキテクチャ
 KEEPS
 しっかり書いて、できればメンテナンスする
 9
10. ユースケース
 • 主要なケースだけ書く
 • 場面（ユース）を書く
 ※機能を書かない
 • ユーザを意識する
 10
11. ドメインモデル
 11 • 利用者の言葉で書く
 • 開発物の抽象を書く
 • 書くもの
 ◦ 仕事する箱
 ◦ 箱の責務
 ◦ 最小限のデータ
 

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

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

14. なぜモデルを使うのか？
 14
15. なぜUMLを使うのか？
 • 特に強い理由はない
 
 • オレオレ記法よりは混乱が少ない
 ◦ 書くための目的と記法に一定のルールがある
 ◦ それらの知見は世の中にあるので学習可能
 ◦ 細かいルールは無視してOK
 15
16. ポイント
 • 全てを設計しない
 • 変わりにくい部分にフォーカスする
 • 作成には時間をかけない
 • 説明には時間をかける
 16
17. 設計の目的
 1. 記録する
 2. 承認する
 3. 共有する
 4. 会話を誘発する
 17
18. 参考
 • 【アジャイル時代のモデリング①】システムの「全体像」の理解共有がなぜ必須なのか 
 • 【アジャイル時代のモデリング②】共通理解を作るための、最もシンプルなモデルセット
 • アジャイル開発の中の設計
 
 18
19. おしまい
 19