Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイルと設計 / Design in Agile Development
Search
岡本卓也
April 18, 2023
Technology
0
32
アジャイルと設計 / Design in Agile Development
2023/04/18
社内発表資料
岡本卓也
April 18, 2023
Tweet
Share
More Decks by 岡本卓也
See All by 岡本卓也
スクラムチームだけどエクセルで要件定義書を書くことにしました / Requirements-Specification-Document-in-Scrum
okamototakuyasr2
0
570
合宿はいいぞ / Training camp is so good.
okamototakuyasr2
0
460
幸運を科学する ~アジャイルチームの成功を再現する方法~ / How to reproduce nice team at ESM webiner.
okamototakuyasr2
0
36
幸運を科学する ~アジャイルチームの成功を再現する方法~
okamototakuyasr2
0
1.1k
なぜアジャイルをやるのですか
okamototakuyasr2
0
110
コミュニティと人の縁〜まずは楽しんで、そしてその先にあるもの〜
okamototakuyasr2
0
390
アジャイル開発の中の設計
okamototakuyasr2
0
740
地方でエンジニアをやる
okamototakuyasr2
0
370
年長者の視点 ~ Another side of ふりかえり ~
okamototakuyasr2
0
10
Other Decks in Technology
See All in Technology
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
13
3.6k
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
160
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.2k
セキュリティ研修 Day1【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
160
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
120
サービスの持続的な成長と技術負債について
siva_official
PRO
10
4.4k
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
280
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
190
フルリモートワークはエンジニアの夢を叶えたか? #cm_odyssey
mamohacy
2
600
RAGのサービスをリリースして1年3ヶ月が経ちました
segavvy
4
950
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.8k
Automating Front-end Workflow
addyosmani
1362
200k
Six Lessons from altMBA
skipperchong
24
3.2k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Practical Orchestrator
shlominoach
185
10k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Mobile First: as difficult as doing things right
swwweet
219
8.8k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Adopting Sorbet at Scale
ufuk
71
8.8k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Clear Off the Table
cherdarchuk
89
320k
The World Runs on Bad Software
bkeepers
PRO
63
11k
Transcript
アジャイルと設計 1 2023年04月18日 株式会社永和システムマネジメント Agile Studio 岡本 卓也
はじめに 1. アジャイル開発でも設計は必要 2. 設計のやり方はどこにも書かれていない 2
設計の目的 1. 記録する 2. 承認する 3. 共有する 3
設計のステップ 1. 調査する 2. 発見する 3. 理解する 4. 共有する
4
設計のステップ 1. 調査する 2. 発見する 3. 理解する 4. 共有する
5 ステップ1 ステップ2
ステップ1:調査と発見 • 調べる • 決める • 一番詳しい人がやる • 他の人はまだ理解できない
6
ここでやめるとこうなる 7 工程 工程 工程 工程 工程を設計書でつなぐ
ステップ2:理解と共有 • 分かったことを書き出す • 他の人に説明する • 見直す • チーム全員が理解している
8
作るもの 1. ユースケース 2. ドメインモデル 3. アーキテクチャ KEEPS しっかり書いて、できればメンテナンスする 9
ユースケース • 主要なケースだけ書く • 場面(ユース)を書く ※機能を書かない • ユーザを意識する 10
ドメインモデル 11 • 利用者の言葉で書く • 開発物の抽象を書く • 書くもの ◦ 仕事する箱
◦ 箱の責務 ◦ 最小限のデータ
アーキテクチャ 12 • 開発者の言葉で書く • 開発物の具象を書く • 書くもの ◦ 利用するサービス
◦ フレームワーク ◦ それらの連携
オススメの順番 13 ユーザーストーリーマッピング(または要件定義書) ユースケース ドメインモデル アーキテクチャ
なぜモデルを使うのか? 14
なぜUMLを使うのか? • 特に強い理由はない • オレオレ記法よりは混乱が少ない ◦ 書くための目的と記法に一定のルールがある ◦ それらの知見は世の中にあるので学習可能
◦ 細かいルールは無視してOK 15
ポイント • 全てを設計しない • 変わりにくい部分にフォーカスする • 作成には時間をかけない • 説明には時間をかける 16
設計の目的 1. 記録する 2. 承認する 3. 共有する 4. 会話を誘発する 17
参考 • 【アジャイル時代のモデリング①】システムの「全体像」の理解共有がなぜ必須なのか • 【アジャイル時代のモデリング②】共通理解を作るための、最もシンプルなモデルセット • アジャイル開発の中の設計 18
おしまい 19