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
It dependsから脱却するスクラム #scrumsapporo / Scrum to b...
Search
TAKAKING22
November 07, 2020
Technology
1
8.2k
It dependsから脱却するスクラム #scrumsapporo / Scrum to break away from It depends
2020年11月5〜7日に開催された「SCRUM FEST SAPPORO 2020 」にて。
TAKAKING22
November 07, 2020
Tweet
Share
More Decks by TAKAKING22
See All by TAKAKING22
我々はなぜテストを書くのか / Why we write test codes
takaking22
7
870
AI時代のアジャイル開発 / Agile Development in the AI Era
takaking22
2
580
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
takaking22
19
7k
よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること / What you can do to scale a good team into a good organization
takaking22
12
5.3k
Open Space Technology Introducion (EN)
takaking22
2
150
オープンプロポーザルの文化をよいものにしたい / improve the culture of open proposals
takaking22
1
920
いきいきした受託開発をするためにアジャイルチームができること / What Agile Teams Can Do for Lively Contract Development
takaking22
2
2.6k
家族を犠牲にしない!子育てエンジニアのコミュニティとの関わり方 / How to Engage with the Community for Parenting Engineers
takaking22
9
3k
リーダー&マネージャーのためのモブプログラミング / Mobprogramming for managers and leaders
takaking22
7
2.6k
Other Decks in Technology
See All in Technology
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
230
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
390
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
120
QAに対する超個人的な解釈 / Personal Take on QA
toma_sm
1
100
o1のAPIで実験してみたが 制限きつすぎて辛かった話
pharma_x_tech
0
190
PdMはどのように全てのスピードを上げられるか ~ 非連続進化のための具体的な取り組み ~
sansantech
PRO
4
1.3k
Mocking in Rust Applications
taiki45
1
410
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
1
130
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
310
リアルお遍路+SORACOM IoT
ozk009
1
140
社内の学びの場・コミュニティ形成とエンジニア同士のリレーションシップ構築/devreljapan2024
nishiuma
3
290
テスト”ケース”駆動開発 で手戻りをなくそう
ryohma0510
0
320
Featured
See All Featured
The Invisible Customer
myddelton
119
13k
The Cost Of JavaScript in 2023
addyosmani
42
5.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
Creatively Recalculating Your Daily Design Routine
revolveconf
215
12k
The Cult of Friendly URLs
andyhume
76
6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
How to Ace a Technical Interview
jacobian
274
23k
A Tale of Four Properties
chriscoyier
155
22k
Visualization
eitanlees
142
15k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
230
17k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
Unsuck your backbone
ammeep
667
57k
Transcript
It depends から脱却するスクラム 及部敬雄 (@TAKAKING22) Photo by Pablo Heimplatz on
Unsplash
スクラムが難しいと感じるのは どんなところですか?
スクラムガイドから 複雑で変化の激しい問題に対応するためのフレームワーク スクラムフレームワークは、スクラムチームとその役割・ イベント・作成物・ルールで構成されている。 それぞれに目的があり、スクラムの成功や利用に欠かせない。 スクラムフレームワークを使用する具体的な方法にはさまざまな ものがあり、それらについては本稿では触れない。
スクラムを難しいと感じる理由を聞いてみた わかるようでわからない 具体的なのか抽象的なのかわからない どこからはじめればよいのかわからない どうやって自分たちの状況にあてはめればよいのかわからない
再びスクラムガイドから スクラムとは、以下のようなものである。 ・軽量 ・理解が容易 ・習得は困難 マジ!?
いざ詳しい人に聞いてみると… It depends 状況に依るね
は!?
It depends から脱却するスクラム 及部敬雄 (@TAKAKING22) Photo by Pablo Heimplatz on
Unsplash
!5",",*/( גࣜձࣾσϯιʔσδλϧΠϊϕʔγϣϯࣨ "(*-&.0/45&3$0.ʢݸਓࣄۀओʣ 4*-7&3#6--&5$-6#ʢνʔϜෳۀʣ ٴ෦ܟ༤ ੍ޚෆೳͳΞδϟΠϧϞϯελʔ
It depends マインドセット 心理的安全性
それっぽい言葉 どんなことでもだいたい It depends どんなときでも心理的安全性もマインドセットは大切 確かにそのとおり でも一切情報量が増えていない
で、どうしたらいいの?
ここからのお話 実際の現場で自分がどうしているのか 大事にしていること 特に気をつけていること なぜそれをやっているのか It depends で片付けずに実装の話をする
仕事をとりまく状況 どうなるのかわからないビジネス どうすればよいのかわからないプロダクト 何を考えているのかわからない人たち なぜそうなっているのかわからない組織やルール
わかる うまくいく わからない うまくいかない
わかる うまくいく わからない うまくいかない 未知のわからない
わからないなんてふつうだ! わからないことだらけ わからないことが多いと不安なので解消したくなる なにかがわかるとまた新しいわからないことが見つかる 常にわからないはそこにある
こうやって考えてる わからないことをどうやって解消するか わからないこととどうやって付き合っていくか
プロジェクト序盤 プロジェクト中盤 プロジェクト終盤
プロジェクト プロジェクト 人生 チーム プロダクト システム
プロジェクト プロジェクトは終わらせるために行う プロジェクトは続いていくなにかのための活動 内製開発でも受託開発でも同じ
プロジェクト中盤 プロジェクト序盤 プロジェクト終盤
プロジェクト序盤 一番情報を持っていない(=わからないことが多い) 最初からすべてを計画することをあきらめる 目指す先がないとスタートできないので必要な計画はする 全体の方向性と直近の見通しが立つ適度な計画 どうすれば最速でスタートすることができるか
None
インセプションデッキ プロジェクトを始める前に明らかにしておくべき 大切なことを知るための活動 10個の質問に答えていく形式 チーム全員で話し合って合意したものをアウトプットする
大事にしているスライド チーム名・ロゴ(オリジナル) 我々はなぜここにいるのか エレベーターピッチ やらないことリスト・あとで決めることリスト 夜も眠れなくなるような問題 トレードオフスライダー OKR(オリジナル) 個人としての目標(オリジナル)
None
好きなインセプションデッキの進め方 1. 個人ワークでそれぞれ書く 2. お互いに共有し合う 3. チームで1つにまとめてアウトプットする https://takaking22.com/2019/how-to-use-inceptiondeck/
インセプションデッキのポイント 成果物よりもつくる過程を大切にする 完成させることに固執せずにできる範囲でつくる チームやプロダクトのことを自分で考えて自分で話す練習をする ズレていることを見つける チームで合意して1つのアウトプットにまとめる体験をする
共通の言葉がチームのコンパスになる Photo by Jordan Madrid on Unsplash
仕事のリズムを設計する εϓϦϯτ εϓϦϯτ εϓϦϯτ εϓϦϯτ
εϓϦϯτ εϓϦϯτ εϓϦϯτ εϓϦϯτ εϓϦϯτ εϓϦϯτ プロジェクト 1週間スプリント 1週間スプリント
タイムボックス 時間の箱をつくって繰り返していく 定期的にフィードバックを得る機会をつくる 比較して計測できるように箱の大きさは基本変えない コンテキストに合わせて階層構造をとってもよい
チームの構造 プロダクトオーナー 開発チーム スクラムマスター プロジェクトマネージャー 顧客
チームは階層構造であることが多い 密 疎 理想は目指しつつも現実を受け入れる(ex. 兼務、雇用形態…) 心地よいリズムや距離感が人によって違う 型にはめようとせずに柔軟に設計をする スムーズ・シンプルであることを目指す
誰をプロダクトオーナーにするのか 顧客、発注者、事業部 自社、部署、チーム 開発チーム 自分
誰をプロダクトオーナーにするのか 顧客、発注者、事業部 自社、部署、チーム 開発チーム 自分 ほんとは プロダクトオーナーに なってほしい やりづらいので 近くに
仮プロダクオーナーを置く
役割と責任を人に当てはめてもうまくいかないことが多い はやく走れる人たちが走り回ればよい 誰かに依存していること(最終決定)を明確にして、 それ以外は全体として役割を包含できればよい プロダクトオーナーやスクラムに限った話ではない 誰をプロダクトオーナーにするのか
自分だったらこうするかなー 顧客、発注者、事業部 自社、部署、チーム 開発チーム 自分 最終決定や そのために必要な準備は お願いする 判断するために必要な情報を集めたり、 優先順位をおすすめしたり、
こまめにプロダクトを見せて確認してもらう 仮プロダクトオーナーをおいて コミュニケーションを 階層構造にしない
全体像を一枚絵にする
余白をつくる 最初に決めて終わりではなくここから始まる 決め過ぎずに余白をもたせておく プロダクトやチームと一緒にみんなで育てていく
未完成をつくる Photo by Sung Shin on Unsplash
プロジェクト序盤 プロジェクト中盤 プロジェクト終盤
プロジェクト中盤 それまでに決めたこと=過去に縛られない 目の前で起きていることにフォーカスする 経験を積み重ねて解像度を上げていく 取り返しのつかない失敗だけはしないようにする どうやって変わらないようにするかではなく どうやって変えていくか
起こった事象(Fact) 動いているプロダクト フィードバック 計画 プロダクトバックログ 開発プロセス 左よりも右をより大切にする
動いているプロダクト 実際につくること、動いているプロダクトをさわることで はじめてわかることが多い 最初に計画したものにこだわらずどんどん変える
プロダクトバックログ ˌ ϓϩμΫτόοΫϩάΞΠςϜ ͷఆٛ ݟੵΓ
ཉ͍͠ॱ൪ʹฒΜͰ͍Δ ͜ͷॱ൪ʹ͍ͭͬͯ͘͘ ॱ൪ఆظతʹݟ͢ ༧ଌ౸ୡʢϕϩγςΟʣ աڈͷ࣮͔Β༧ଌ ༧Ͱͳ͘༧ଌ શ෦Βͳ͍ͷͰ ඞཁҎ্ʹઌ·Ͱ ৄࡉʹܭը͠ͳ͍
活き活きしたプロダクトバックログ やることのリストアップではなくて仮説のリストアップ 最初は解像度が荒くて質も低いが、 プロジェクトが進むにつれてどんどん育っていく プロダクトバックログへのCRUD処理が多い
見積もり 優先順位をつけるときの判断基準としてのボリュームや、 ビジネス判断をする際に見通しを知りたいことはある 上記が満たされていれば、 数字どころか見積もりそのものもいらないかもしれない 数字当てゲームに時間を使い過ぎない
障害リスト リスクだと思っていることを貯めておく箱を作る 書き溜めたら忘れる 定期的にチェックするタイミングをつくる(スプリント毎など)
決定を遅延する 適切なタイミングで決定ができるようにする 今決めなくていいことは先送りにする 今やるべきことにフォーカスする
フィードバック 適切なフィードバックをどうやってもらうか 「それユーザーではなくてあなたの意見ですよね?」問題 ユーザーの声をただ鵜呑みにするのではなく、 自分たちの仮説を検証するためにフィードバックを活用する
肩越しの視線 実ユーザーがプロダクトを使っているところを見せてもらう こちらの想定通りに問題解決までたどりつけるか 問題解決までがスムーズだったか
書いたコードを捨てる 捨てることを厭わない 捨てる=ムダになったのではなくより洗練されたと考える Be Simple
モブプログラミング チーム全員で同じ時間に同じ画面を見ながら同じ仕事をする リソース効率ではなくフロー効率を重視する リモートワークにおいても有効である https://speakerdeck.com/takaking22/remote-mobprogramming-stay-home-with-team
None
私たちのモブプログラミング ϞϒʹνʔϜ
一緒に作業をする 会議に向けてそれぞれ準備や作業をして、 集まった時に報告・議論・判断をすることが効率がよいのか 集まった時に一緒に作業を進めた方が、 スムーズに進むことは自分たちが考えている以上に多い 作業の結果だけでなく過程もチームの合意となる
ボトルネックは移動する ボトルネックは移動していく ボトルネックを停滞させない ボトルネックを素早く発見して移動させる
Photo by Grillot edouard on Unsplash
螺旋を登っていくイメージ 似たような問題が再発しているように感じるときがある 前回よりも経験を積んでいる分、解像度は上がっている 解像度が上がると問題の見え方や見える範囲も変わる 経験から学習してうまくなっていく
プロジェクト序盤 プロジェクト中盤 プロジェクト終盤
プロジェクト終盤 終盤だからという理由で頑張らない 特別にやることはない 終わらせるのではなく次につなげる
最後に頑張るのをやめる 終盤戦になって一気にやることが増えてしまいがち 開発チームはペースを変えずに冷静に判断をする プロジェクト内でやる必要があれば計画を変える プロジェクト内でやる必要がなければ先送りをする 質を下げることだけは絶対にしてはいけない
次への準備に時間を割く プロダクトバックログを精査する 障害リストを精査する ドキュメントや環境を整える 勉強をする
まとめ 必要なことを必要なときに必要な分だけ実施する 変わらないようにするのではなく、積極的に変えていく 失敗しても受け身で魅せる 終わらせるではなく、次につなげる
わからないことをどうやって解消するか わからないこととどうやって付き合っていくか 経験主義 計画駆動
こういうことを言うと… それはスクラムではない
フィードバックありがとうございます 実装するとはこういうこと いまの自分たちの頭で考えて一番よいと思うものを実装する 他人にとってスクラムかどうかはあまり気にしていない これがベストだとは思っていないので、 建設的なフィードバックはありがたく受け取る
で、どうしたらいいの?
A. 知らんわ!
It depends の正体 抽象 具体 スクラム 事例A 事例B 事例C
抽象 具体 スクラム 事例A 事例B 事例C 自分 It depends の正体
自分たちへ適応させて 実装する
抽象 具体 スクラム 事例A 事例B 事例C 自分 It depends の正体
他者の事例を抽象化して理解し、 そこから自分たちへ適応させて 実装する
スクラムはフレームワーク よいフレームワークを使ったからといって、 よいプロダクトにはなるとは限らない よいプロダクトと同じフレームワークの使い方をしたとして、 よいプロダクトになるとは限らない フレームワークを使ってどう実装するのかは 実装者の腕の見せどころ
It depends の正体 実装力が問われている システムを実装するときに、 他人のコードをそのままコピペして動かそうとはしないはず 実装に必要な情報を一番多く持っているのは自分自身 It depends を脱却して先へ行くのは自分自身
自問自答してみよう 行動せずに難しいかどうかを批評してしまっていないか 答えクレクレ君、事例クレクレ君になっていないか
実装力 Photo by Thao Le Hoang on Unsplash
どうやって実装力を上げるか 知識をインプットする 人に聞きやすい部分 書籍、論文、勉強会、研修 経験を積み重ねる
どうやって経験を積み重ねるか 現場で実験をする 思考実験をする
思考実験 現場の制約に関係なく、実験し放題である 一人ではなくて誰かとやるとよい 相手や自分の具体的な事象について話す 自分の頭で考えてフィードバックをもらう Open Space Technology やオンラインの場を使う
自分のことが話せるオンラインの場 分散アジャイルチームについて考える会 製造業アジャイル勉強会 アジャイル・ディスカッション Scrum Masters Night! スクラム道関西 …
自分の頭で考える なるほど! 勉強になりました 刺激を受けました なぜそうしたんだろう 自分だったらこうする
論理 感覚 実装力
スクラムは難しいのか スクラムが難しいかどうかを気にしたことがない なぜならプロダクト開発が難しいことを知っている わからないことだらけだって知っている わからないことをどうやって解消するかだけではなくて、 わからないこととどうやって付き合っていくかを考える スクラムの習得も スクラムと同じ経験主義
It depends から実装の世界へ Photo by Grant Ritchie on Unsplash