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
85
アジャイルを始めるための基礎を固める
アジャイルを始めるための基礎を固める方法をスライドにまとめたもの
ham
September 17, 2024
Tweet
Share
More Decks by ham
See All by ham
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.5k
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
5
1.8k
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
890
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
920
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.6k
今こそ思い出すGraphQLの特徴
ham0215
0
170
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
530
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
1
4k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.6k
Other Decks in Technology
See All in Technology
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
530
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
日本版とグローバル版のモバイルアプリ統合の開発の裏側と今後の展望
miichan
1
130
非機能品質を作り込むための実践アーキテクチャ
knih
5
1.3k
Wvlet: A New Flow-Style Query Language For Functional Data Modeling and Interactive Data Analysis - Trino Summit 2024
xerial
1
120
Oracle Cloud Infrastructure:2024年12月度サービス・アップデート
oracle4engineer
PRO
0
180
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
530
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1.1k
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
410
2024年にチャレンジしたことを振り返るぞ
mitchan
0
140
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
450
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Code Review Best Practice
trishagee
65
17k
Docker and Python
trallard
42
3.1k
Optimizing for Happiness
mojombo
376
70k
Code Reviewing Like a Champion
maltzj
520
39k
Documentation Writing (for coders)
carmenintech
66
4.5k
Embracing the Ebb and Flow
colly
84
4.5k
Adopting Sorbet at Scale
ufuk
73
9.1k
The Pragmatic Product Professional
lauravandoore
32
6.3k
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 いつでも本番反映できる仕組みができた! あとはアジャイルを実践するのみ! アジャイルには様々な⼿法があります ⾃分に合った⼿法を⾒つけましょう!