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
アジャイルを始めるための基礎を固める
Search
ham
September 17, 2024
Technology
1
160
アジャイルを始めるための基礎を固める
アジャイルを始めるための基礎を固める方法をスライドにまとめたもの
ham
September 17, 2024
Tweet
Share
More Decks by ham
See All by ham
生成AIによる生産性向上〜テック企業やファインディの活用事例〜
ham0215
1
50
生成AI導入の効果を最大化する データ活用戦略
ham0215
0
330
データ駆動経営の道しるべ:プロダクト開発指標の戦略的活用法
ham0215
2
390
開発組織における意思決定の実例〜開発優先度・組織構成・ツール導入〜
ham0215
0
78
エンジニアリングで組織のアウトカムを最速で最大化する!
ham0215
1
420
アウトカムを最速で最大化できる開発組織にするために
ham0215
1
140
コード品質向上で得られる効果と実践的取り組み
ham0215
2
330
開発者体験を定量的に把握する手法と活用事例
ham0215
2
290
チームトポロジーの4つのチームタイプ
ham0215
2
150
Other Decks in Technology
See All in Technology
Kotlinで型安全にバイテンポラルデータを扱いたい! ReladomoラッパーをAIと実装してみた話
itohiro73
3
260
新米エンジニアをTech Leadに任命する ー 成長を支える挑戦的な人と組織のマネジメント
naopr
1
360
AIの個性を理解し、指揮する
shoota
3
630
Boxを“使われる場”にする統制と自動化の仕組み
demaecan
0
200
Mackerelにおけるインシデント対応とポストモーテム - 現場での工夫と学び
taxin
0
110
GCASアップデート(202508-202510)
techniczna
0
340
Copilotの精度を上げる!カスタムプロンプト入門.pdf
ismk
2
270
20251106 Offers DeepDive 知識を民主化!あらゆる業務のスピードと品質を 改善するためのドキュメント自動更新・活用術
masashiyokota
0
180
今のコンピュータ、AI にも Web にも 向いていないので 作り直そう!!
piacerex
0
630
AIで急増した生産「量」の荒波をCodeRabbitで乗りこなそう
moongift
PRO
0
480
AI時代に必要なデータプラットフォームの要件とは by @Kazaneya_PR / 20251107
kazaneya
PRO
4
670
累計5000万DLサービスの裏側 – LINEマンガのKotlinで挑む大規模 Server-side ETLの最適化
ldf_tech
0
190
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
95
14k
Designing Experiences People Love
moore
142
24k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.5k
Producing Creativity
orderedlist
PRO
348
40k
Embracing the Ebb and Flow
colly
88
4.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
658
61k
Making Projects Easy
brettharned
120
6.4k
Statistics for Hackers
jakevdp
799
220k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Fireside Chat
paigeccino
41
3.7k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Transcript
© Findy Inc. 2024.09.17 1 アジャイルを始めるための 基礎を固める 浜⽥ 直⼈ Naoto
Hamada (ham)
© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React
/ TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
© Findy Inc. 3 Agenda - アジャイルソフトウェア開発宣⾔は⼼構え - アジャイルを始める基礎を作る
© Findy Inc. アジャイルソフトウェア開発宣⾔は ⼼構え 4
© Findy Inc. 5
© Findy Inc. 6 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf
© Findy Inc. 7 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf ⼼構えはわかった!! やっていき!!!
© Findy Inc. 8 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf ⼼構えはわかった!! で、どうすればいいの??
© Findy Inc. 9 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf
© Findy Inc. 10 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf マインドセットを変えるだけでは 実践できないものがあるな...
© Findy Inc. 11 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf 実践するには 基礎を作る必要がある!
© Findy Inc. アジャイルを始める基礎を作る 12
© Findy Inc. 13 いつでも本番反映できる仕組みを作る main feature 細かく本番反映していく 仕組みが必要
© Findy Inc. 14 ⻑く残るブランチとは? - featureブランチで開発を⾏い、すべて開発‧検証した後に マージ main feature
新規機能‧既存機能 すべて検証後にマージ feature N
© Findy Inc. 15 細かくマージするための考え⽅ - 🙅検証して承認されたコードしかmainにマージしない - 🙆既存に影響を与えないコードはガンガンmainにマージ ◦
(体感ですが)追加‧変更したコードの9割は既存に影響を 与えない形でマージできる ◦ 1つ1つの影響範囲が広い場合、結合度を⾒直すと良い main feature
© Findy Inc. 16 細かくマージするための考え⽅ - 🙅検証して承認されたコードしかmainにマージしない - 🙆既存に影響を与えないコードはガンガンmainにマージ ◦
(体感ですが)追加‧変更したコードの9割は既存に影響を 与えない形でマージできる ◦ 1つ1つの影響範囲が広い場合、結合度を⾒直すと良い main feature 既存に影響を与えないことを 検証するのが⼤変じゃん
© Findy Inc. 17 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる
© Findy Inc. 18 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる 例えば以下のようなPRはCI通ればヨシッ! →mainへマージ PR1: 関数名を変更 PR2: Fix typo PR3: 新しいモジュールを追加(未使⽤) PR4: ライブラリアップデート(ものによるが)
© Findy Inc. 19 「既存に影響を与えない」を保証する - ⾃動テストをCIで実⾏して、既存の振る舞いを保証する - 必要に応じてmainマージ前に⼿動テストをする ◦
⾃動テストで広範囲を担保して、どれだけ⼿動テストを 減らせるかがキモとなる!! ◦ リネームやtypoの修正、リファクタリングは⾃動テスト さえ通れば確認OKと⾒なせる 例えば以下のようなPRはCI通ればヨシッ! →mainへマージ PR1: 関数名を変更 PR2: Fix typo PR3: 新しいモジュールを追加(未使⽤) PR4: ライブラリアップデート(ものによるが) PRに1つの観点しか⼊っていなければ ⼿動テストの有無も⼀⽬瞭然! →1つのPRに複数の観点を⼊れないこと も⼤事
© Findy Inc. 20 ⾃動テスト書く時間が もったいなくないですか?
© Findy Inc. 21 テスト⾃動化の損益分岐点は「4回」 - 4回以上変更するなら⾃動テストを書いた⽅がお得!! 質とスピード (@t_wada) https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
© Findy Inc. 22 ⾃動テスト書くのは ハードル⾼いのですが...
© Findy Inc. 23 ⾃動テストは書けるようになりましょう! - ⼀度⾃動テストがある環境に⾜を踏み⼊れると、⾃動テス トがない世界には戻れなくなります! - ⾃動テストのある開発環境は開発者体験が良い!!
© Findy Inc. 24 ⾃動テストで100% 品質担保できるんですか?
© Findy Inc. 25 Four Keys - DORAが調査した開発組織のパフォーマンス指標 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 26 Four Keys - Eliteでも変更障害率は5% 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 27 Four Keys - 障害が起きても1時間以内に復旧 2023 State
of DevOps Report https://cloud.google.com/devops/state-of-devops https://book.impress.co.jp/books/1118101029
© Findy Inc. 28 本番障害は起きるものと認識する - 本番障害が⼀定の割合で発⽣することは許容する ◦ ※プロダクトの性質によって許容する範囲は変える -
⼀⽅で障害が発⽣してもすぐに復旧できるように監視やリ カバリ⼿順を確⽴しておく - Tips: エラーバジェット ◦ 可⽤性: 99.9% → 43分/⽉ までは障害を許容 ◦ 許容範囲を超えるまでは積極的に開発を進める ◦ 許容範囲を超えたら信頼性の回復に注⼒する
© Findy Inc. 29 守りたいものを定義して守る - 本番障害に備えるため、守りたいものを定義して守る ◦ プロダクトの振る舞い ▪
⾃動テスト / E2Eテスト / リリース前の⼿動テスト ◦ レスポンスタイム / ステータスコード ▪ ログ監視 ◦ 復旧⼿順を整備 ▪ ⾃動化‧簡易化‧ドキュメント化 ◦ 障害後のふりかえり ▪ 再発防⽌
© Findy Inc. 30 いつでも本番反映できる仕組みができた! あとはアジャイルを実践するのみ! アジャイルには様々な⼿法があります ⾃分に合った⼿法を⾒つけましょう!