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
8.2k
スクラムで作る頼もしく生き生きとしたチーム / 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
0
200
EM、会計を学ぶ
yigarashi
0
340
自己組織化の真価を引き出す EM of EMsのしごと
yigarashi
2
730
プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
yigarashi
0
1.7k
はてなEMキャリアパス 最速攻略RTA 新卒部門
yigarashi
3
2.6k
30分でわかるFour Keysの基礎と重要性
yigarashi
34
26k
Hatena Engineer Seminar #14 GraphQL編
yigarashi
1
1.9k
GraphQL API を悪意あるクエリから守る手法
yigarashi
0
240
Other Decks in Programming
See All in Programming
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
150
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
530
Team operations that are not burdened by SRE
kazatohiei
1
310
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
10k
AIともっと楽するE2Eテスト
myohei
6
2.6k
XP, Testing and ninja testing
m_seki
3
250
A2A プロトコルを試してみる
azukiazusa1
2
1.4k
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
Goで作る、開発・CI環境
sin392
0
230
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
260
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Adopting Sorbet at Scale
ufuk
77
9.5k
YesSQL, Process and Tooling at Scale
rocio
173
14k
GitHub's CSS Performance
jonrohan
1031
460k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Agile that works and the tools we love
rasmusluckow
329
21k
Into the Great Unknown - MozCon
thekraken
40
1.9k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Site-Speed That Sticks
csswizardry
10
690
Six Lessons from altMBA
skipperchong
28
3.9k
Unsuck your backbone
ammeep
671
58k
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%程度しか時間を使えていません」 ▪ 透明化のバリエーション
生き生きとしたチームへと進化 • 短期のゴールがチームをモチベートする ◦ 毎日バーンダウンチャートを見て一喜一憂 ◦ ゴール達成でお互いを讃えあう ◦ 未達でも検査と適応で再チャレンジする •
共通のゴールがチームワークを育てる ◦ 自分のタスクが終わっても、チームでゴールを達成しなければ意味がない ▪ レビュー依頼がきたら積極的に見る ▪ 困っている人がいたらペアプロしにいく ◦ 議論が活発になり信頼関係が深まる
まとめ • スクラムの大きな特徴として透明性、検査、適応がある • チームの課題 ◦ 検査と適応が機能せず、形式的な実践に止まっていた ◦ ハードルがあった見積もりとスプリントゴールこそが欠けていた鍵だった •
スクラム勉強会で変化のハードルを乗り越えた • ゴール達成のために透明化、検査、適応をすればよいとわかった ◦ スクラムイベントを意味のあるものに作り変える方法がわかった ◦ それを積み重ねて、頼もしく生き生きとしたチームに