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
スクラムで作る頼もしく生き生きとしたチーム / The lively trustworthy ...
Search
Yuu Igarashi
March 05, 2022
Programming
4
7.7k
スクラムで作る頼もしく生き生きとしたチーム / The lively trustworthy team by scrum
Yuu Igarashi
March 05, 2022
Tweet
Share
More Decks by Yuu Igarashi
See All by Yuu Igarashi
自己組織化の真価を引き出す EM of EMsのしごと
yigarashi
2
330
プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
yigarashi
0
1.1k
はてなEMキャリアパス 最速攻略RTA 新卒部門
yigarashi
2
2.1k
30分でわかるFour Keysの基礎と重要性
yigarashi
33
21k
Hatena Engineer Seminar #14 GraphQL編
yigarashi
1
1.6k
GraphQL API を悪意あるクエリから守る手法
yigarashi
0
160
Other Decks in Programming
See All in Programming
REXML改善のその後
naitoh
0
150
Kotlin 2.0 and Beyond
antonarhipov
2
130
iOSの隠されたAPIを解明し、開発効率を向上させる方法/iOSDC24
noppefoxwolf
2
120
Polars を Kaggle コンペで使ってみた(LMSYS Chatbot Arena)
kohecchi
1
360
Rustではじめる負荷試験
skanehira
5
1.1k
開発を加速する共有Swift Package実践
elmetal
PRO
0
300
マイグレーションコード自作して File-Based Routing に自動移行!! ~250 ページの歴史的経緯を添えて~
cut0
1
240
Go Code Generation at newmo / 2024-08-27 #newmo_layerx_go
genkey6
0
510
The Sequel to a Dream of Ruby Parser's Grammar
ydah
1
180
2024 컴포즈 정원사
jisungbin
0
140
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
1
930
楽しく簡単に!QRコードの読み取り機能を実装しよう
penguinsan_pg
1
190
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
GraphQLとの向き合い方2022年版
quramy
43
13k
The Illustrated Children's Guide to Kubernetes
chrisshort
46
48k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
KATA
mclloyd
27
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
27
1.6k
Agile that works and the tools we love
rasmusluckow
327
20k
Designing the Hi-DPI Web
ddemaree
278
34k
How to Ace a Technical Interview
jacobian
275
23k
Scaling GitHub
holman
458
140k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Done Done
chrislema
180
16k
Transcript
スクラムで作る頼もしく 生き生きとしたチーム YAPC::Japan::Online 2022 DAY2
自己紹介 • 名前 ◦ 五十嵐 雄(いがらし ゆう)id:yigarashi ◦ https://twitter.com/yigarashi_9 •
所属 ◦ 株式会社はてな はてなブックマークチーム Webアプリケーションエンジニア ▪ テックリード ▪ デリバリーリードエンジニア ▪ シニアエンジニア • ソフトウェア、プロセス、ヒトの観点でプロダクト開発をリード • Perlはほぼ毎日読み書きしています
今日のトーク 見積もりとスプリントゴールでスクラムを学び直した話 • スクラム高速ハイライト • チームの課題と変革 • 急加速する改善とスクラムのパワー
スクラム 高速ハイライト
スクラムとは • スクラムガイドで定義されたアジャイル開発の代表的なフレームワーク • 反復的な開発で不確実性に対処する • 経験主義で経験から学び素早く変化するための3つの特徴を持つ ◦ 「透明性」問題を常に可視化する ◦
「検査」 プロセスや成果物が適切か検査する ◦ 「適応」 発見した問題に対処する
スクラムが目指す開発 こんな感じですがど うですか? 適応 透明性、検査 なるほど! ちょっと方向性を 修正します 反復的な開発 効率の良いやり方を思い
ついたので試そう! プロセスも常に進化
スクラムの概念 - スクラムイベント • スプリント ◦ あらゆる作業と他のイベントを含む固定の期間 • スプリント計画 ◦
スプリントのゴールを設定し達成するための作業を計画する • デイリースクラム ◦ 毎日スプリントのゴール達成のために検査と適応を行う • スプリントレトロスペクティブ(ふりかえり) ◦ 組織やプロセスに対する検査と適応を行う • スプリントレビュー ◦ 成果物の検査を行う
スクラムの概念 - 成果物 • プロダクトバックログ ◦ プロダクトを改善するためにやることが優先度順に並んだリスト • スプリントバックログ ◦
スプリントゴール ▪ 例: ユーザー機能を作る ◦ ゴール達成に必要なプロダクトバックログアイテム ▪ 例: 登録機能、ログイン機能、プロフィール機能 ◦ 作業計画 ▪ 例: 登録APIの実装、登録ページの実装 …… • インクリメント
チームの課題と変革
チームの課題 • 大半を実践しているが形式的で効果が低い ◦ デイリースクラムが大人数( 15人ほど)でステータスミーティングになっている ◦ ふりかえりで何を議論したら良いかわからない ……etc. •
欠けているピースがあった ◦ 見積もり ▪ チームに日常的な見積もり経験がなかった ▪ チームにとって全てのタスクを見積もるのは大袈裟で高い障壁があった ◦ スプリントゴール ▪ 見積もりをしていないので何が完了するか設定のしようがない
見積もりとスプリントゴールこそが鍵だった • 透明性、検査、適応がスクラムの特徴 • 見積もりは透明性の土台 ◦ 自分達のパフォーマンスや進捗を定量化できる • スプリントゴールは検査と適応の主題 ◦
ゴールに対して自分達がどれくらい進んでいるか ◦ ゴールを達成できているか ◦ ゴールは適切だったか、もっと上手く達成する方法はないのか • これら無くしてスクラムが形式的になるのは必然だった ◦ どうにか理解してもらって変化しないといけない
スクラム実践リブート 知識を入れ直すことで実のあるスクラムを目指す • チーム全員で勉強会を開催 ◦ 毎週1時間 ◦ 集まって決めた範囲を読む • 読んだ範囲とチームの差分を議論する
◦ チームの欠けている部分を共通認識とする ◦ 理想の姿を再確認する
勉強会の成果 • およそ3ヶ月で教科書を完走 • 全てのタスクをチームで見積もるようになった ◦ 全員でやってみようと合意することができた • スプリントゴールを設定するようになった ◦
見積もりに基づいて完了できる量を予測できるようになった ◦ まずはプロダクトバックログアイテムの束をゴールとした • 鍵となるピースが埋まり劇的な改善が起こり始める
急加速する改善と スクラムのパワー
急加速するチームの改善 • 見積もりとスプリントゴールというピースが埋まった ◦ これらがチームのスクラムの鍵だった ◦ 透明性、検査、適応のための基礎 • ゴール達成のために透明化、検査、適応をすればよいとわかった ◦
スクラムイベントを意味のあるものに作り替える方法がわかった ◦ それを積み重ねて、頼もしく生き生きとしたチームに
スプリント計画 適切なゴールを設定しゴール達成の確度を高めるための場になった • ベロシティに基づいて適切なゴールを設定する • 達成の確度を高めるための工夫 ◦ PBIをさらに細かい作業に分解・見積もりする ▪ 不確実性を下げ、透明性を高める
▪ 分担しやすくする ◦ 取り組む順序を細かく計画する ▪ 不確実性やブロッカーを先に排除する ◦ 達成の自信度をポーカーする( 0%、25%、50%、75%、100%) ▪ 平均が75%を下回ったら不安な要因を話して排除する
デイリースクラム ゴール達成のために検査と適応を行う場になった • ゴール達成に責任を持つ開発メンバーのみで実施するようにした ◦ ゴールの具体的な障害物を排除しやすくなった • 徹底した透明化を実施 ◦ バーンダウンを引いてゴールに近づいているか可視化
◦ カンバンで以下をわかるようにする ▪ PBIの達成状況 ▪ タスクの未着手、着手、待ち、完了 ◦ 毎日異常を発見して適応できるようになった ▪ 例: 「チャートは下がってないけど、待ちがやたら多くないですか?」
スプリントレトロスペクティブ(ふりかえり) ゴール達成の過程を検査し改善する場になった • ゴール達成に責任を持つ開発メンバーのみで実施するようにした ◦ 話題のズレなど気にせず深い分析ができるようになった ◦ スプリントゴールを中心に密度の濃い会話ができるようになった ▪ 「ゴール達成に役立ったことは?」
▪ 「ゴール達成の障害になったことは?」 • Findy Teamsを用いた活動の透明化でふりかえりを強化 ◦ GitHub上のアクティビティの量や各種リードタイム ◦ レビューの件数や偏り
頼もしいチームへと進化 • ゴールの達成に全力を尽くし、実際に確度高く達成する ◦ ベロシティやバーンダウンチャートといった透明化 ◦ 綿密なスプリント計画 ◦ デイリースクラムやふりかえりによる不断の検査と適応 •
先の計画についても指針を提供できる ◦ 「この施策は全体で80ポイント、単純計算では 4スプリントほどで終わります」 ▪ 確度の高いスプリントを繰り返すことで安定した中長期計画を提供する ◦ 「ここ3ヶ月、技術基盤に10%程度しか時間を使えていません」 ▪ 透明化のバリエーション
生き生きとしたチームへと進化 • 短期のゴールがチームをモチベートする ◦ 毎日バーンダウンチャートを見て一喜一憂 ◦ ゴール達成でお互いを讃えあう ◦ 未達でも検査と適応で再チャレンジする •
共通のゴールがチームワークを育てる ◦ 自分のタスクが終わっても、チームでゴールを達成しなければ意味がない ▪ レビュー依頼がきたら積極的に見る ▪ 困っている人がいたらペアプロしにいく ◦ 議論が活発になり信頼関係が深まる
まとめ • スクラムの大きな特徴として透明性、検査、適応がある • チームの課題 ◦ 検査と適応が機能せず、形式的な実践に止まっていた ◦ ハードルがあった見積もりとスプリントゴールこそが欠けていた鍵だった •
スクラム勉強会で変化のハードルを乗り越えた • ゴール達成のために透明化、検査、適応をすればよいとわかった ◦ スクラムイベントを意味のあるものに作り変える方法がわかった ◦ それを積み重ねて、頼もしく生き生きとしたチームに