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
TK
October 02, 2021
Technology
0
99
効果的なスプリントプランニングのトライ
Scrum fest Osaka 2021
TK
October 02, 2021
Tweet
Share
More Decks by TK
See All by TK
私のチームが実践しているスプリントに集中するための取り組み
tkredman
0
2k
アジャイルであり続けるために技術スキルと向き合う
tkredman
4
3.4k
覗いてみよう!現場のスクラムチーム
tkredman
0
2.8k
「守破離の守!」スクラムガイドをみんなで読んでみた。
tkredman
0
1.5k
アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
tkredman
0
43
スクラム開発と向き合うことでスクラムを習得する
tkredman
0
98
たった一つの質問でマインドセットの灯をともせ!
tkredman
0
23
Other Decks in Technology
See All in Technology
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
2
6.5k
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
8.5k
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
150
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
370
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
190
モバイル界のMCPを考える
naoto33
0
430
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
180
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
7k
AI専用のリンターを作る #yumemi_patch
bengo4com
5
4.1k
OPENLOGI Company Profile
hr01
0
67k
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
7
2k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
How STYLIGHT went responsive
nonsquared
100
5.6k
Documentation Writing (for coders)
carmenintech
72
4.9k
RailsConf 2023
tenderlove
30
1.1k
Agile that works and the tools we love
rasmusluckow
329
21k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
280
Done Done
chrislema
184
16k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Transcript
効果的なスプリントプランニングのトライ Retty株式会社 今井貴明 Scrum Fest Osaka 2021 2021/06/26
自己紹介 • TK (Imai Takaaki) • エンジニア ◦ 2015~ SIer
◦ 2021~ Retty株式会社 • @t_k_redman
今日のお話
スプリントプランニングについて話します • スプリントプランニングってどんなことするイメージ?
スクラムガイドによると・・・ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する: トピック 1:このスプリントはなぜ価値があるのか? トピック 2:このスプリントで何ができるのか? トピック 3:選択した作業をどのように成し遂げるのか?
スクラムガイドによると・・・ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する: トピック 1:このスプリントはなぜ価値があるのか? トピック 2:このスプリントで何ができるのか? トピック 3:選択した作業をどのように成し遂げるのか? 端的に言えば
「やることを決めてタスク分解」 ・・・かな?
スクラムガイドによると・・・ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する: トピック 1:このスプリントはなぜ価値があるのか? トピック 2:このスプリントで何ができるのか? トピック 3:選択した作業をどのように成し遂げるのか? 今日は特にこの部分について
スプリントプランニングで実現できると思ってること • スプリントゴールまでの道のりをクリアにする • デイリースクラムの効果を上げる • 開発チーム内の文化ができる
きっかけ
スクラム学び始めのスプリントプランニング理解 スクラムマスター 兼 開発者の私 スプリントの計画を立て るんだな〜〜〜 タスク分解な〜 完全理解 ガイド読んだ
トレーニング受けた • スクラムガイドとかの説明を読むと一応理解できる • スクラムイベントの中では比較的イメージしやすいイベントではあると思う
やってみると難しい① • タスクが大きくなりすぎたりふわっとしてしまう ◦ やってみないと、調べてみないとわからないからざっくりタスク化 ◦ タスクボリュームが読めなくてバッファを積んでしまう 調査 確認
やってみると難しい② • タスクが属人化してしまう ◦ 詳しい人しか取れないタスクができる ◦ スキル的に取れるタスクが限られる
やってみると難しい③ • 時間がかかりすぎてしまう ◦ 半日とか1日とかかかってしまってもっと短くしたい ◦ 作業に費やす時間の割合が減ってしまう
昔々あるところのチーム • チームメンバーは自分を含む4人 • 結成3ヶ月くらい • スクラムビギナーズ • 自力でコーディングできるメンバーは半分
チームの抱えるスプリントプランニングの悩み タスクが 大きすぎる タスクによって特定の 人に偏ってしまう スプリントプランニング に時間がかかる
チームの抱えるスプリントプランニングの悩み タスクが 大きすぎる タスクによって特定の 人に偏ってしまう スプリントプランニング に時間がかかる
一番の課題はスキル差 • 一人では取れないタスクも多くありパフォーマンスに影響が出 ていた • コーディング経験が浅いメンバーを常にフォローしながら進め ている状態
自力で書ける・書けないの違いは何? • コーディング経験が浅いメンバーも、基本的な文法理解はある し一緒に処理を追えば読むこともできる • ヒアリングしていくと「何から手をつけたらいいかわからない」と いう課題がありそう
• コーディングって何から始めてどうやって進めてたっけ? 無意識でやっていることを言語化してみる 処理の大枠の流れから••• データ取り回しに必要な処理を 洗い出し••• モデルクラス•••関数•••
それをみんなでやってみれば良いのでは • 普段は頭の中で無意識にやっている手順を会話で確認しなが らスプリントプランニングでみんなでやってみることにした
トライと結果
スプリントプランニングでやったこと① • 処理順を会話で確認しながら実装内容をコメントで書いていく ◦ 最初は「ここでこの配列をループさせてこの変数に値を入 れていく」くらいまで ◦ 基準は「みんなが自力でコーディングできる」こと • コメントをキリのいい範囲で切って一つのタスクにする
スプリントプランニングでやったこと② • わからないことがあった場合は調査 ◦ 細かくタスクを切っていくためには不確実なことをなくして いくことが必然 ◦ APIの仕様、データ構造の検討、既存処理把握など今まで 調査タスクにしていたものは全てスプリントプランニング内 で消化した
細かくタスク分解していった結果 タスクが 大きすぎる タスクによって特定の 人に偏ってしまう スプリントプランニング に時間がかかる • 誰が見てもやることが明白な状態になり誰でもタスクが取れる •
経験が浅いメンバーに対してレクチャーもできた
細かくタスク分解していった結果 • 属人化排除のためのタスク細分化でやることがクリアに • 不確定要素が減ってバッファを積む必要がなくなった • メンバー間での仕様の認識乖離がスプリント序盤で解消した タスクが 大きすぎる タスクによって特定の
人に偏ってしまう スプリントプランニング に時間がかかる
細かいタスク分解でチームの文化ができてきた • スキルの高い人に引っ張られてレベルが底上げされる • レベルが上がると必要なタスク粒度や表現方法も変わる • 思想が揃ってくる ◦ クラスやコンポーネントの設計、関数の切り方、モデル化 などのルールが確立されていく
未解決の課題 • 調査事項も消化しながらタスク細分化までやるので当然さらに 時間はかかる タスクが 大きすぎる タスクによって特定の 人に偏ってしまう スプリントプランニング に時間がかかる
時間かかってもいいんじゃない? • むしろこれくらいやらないとスプリントゴールまでの道なんて見 通せない =タスク粒度が粗いと検査の精度が上がらない • なぜ「調べないと分からない」ことが残ってるのにスプリント ゴールが達成できると思っていたのか・・・
そうは言ってもMTGに時間をかけたくない・・・ • 手を動かしてない時間が増えると不安が募る ◦ 当時スプリントプランニングに1.5日くらいかけてた ◦ 1週間スプリントなので手を動かせるのは60%くらい
そもそもMTGとして捉えない方がいい • WFでいうところの詳細設計をしている • 設計工程をモブワークしているのだと思えばこれも必要な時 間
でもそんなに細かくして大丈夫? • タスク間の依存度上がらない? ◦ 時間にして15分とか30分のタスクになる ◦ きれいに疎結合のタスクにするのは難しい • 結局一連のタスクを同じ人がとることにならない? ◦
それスクラム的にどうなの? ◦ それなら細分化しなくても一緒じゃない?
目的は「透明性を上げる」こと • 全てのタスクを疎結合にすることが目的ではない 半日見込みのタスクに昨日から着手 してます。 多分昼過ぎくらいに終わります。 例えばデイリースクラムで・・・ 30分見込みのタスクが半分くらい仕 掛かってます。 次はこの30分タスク取って、午前中は
3つくらい消化できそうです。 スプリントゴールに向けた検査がしやすいのはどっち?
ブラックボックスこわい • 半日で終わる根拠がわからない • 当人が気付いていない問題が眠っているかも • 「このタスク思ったより時間かかった」というときに振れ幅が大 きい
「依存関係になりにくい設計にする」という考え方も • 「必要な関数は何か」という視点で分解していくなど ◦ 依存関係のあるタスクを少なくできる • タスク細分化のためだけにそうするわけでもない ◦ リファクタリングしながら計画するイメージ •
関数ごとに実装するならついでにテストも書いちゃったり ◦ どこかで聞いたような設計方法論がハマりそう
まとめ
スプリントプランニングで実現できると思ってること • スプリントゴールまでの道のりをクリアにする • デイリースクラムの効果を上げる • 開発チーム内の文化ができる
スプリントプランニングで実現できると思ってること • スプリントゴールまでの道のりをクリアにする • デイリースクラムの効果を上げる • 開発チーム内の文化ができる • 不確実なことはクリアにしてしまってやることを明白にする •
タスク細分化の過程で実現内容(仕様)の認識をすり合わせる
スプリントプランニングで実現できると思ってること • スプリントゴールまでの道のりをクリアにする • デイリースクラムの効果を上げる • 開発チーム内の文化ができる • タスクが細かい方が透明性が高まる(ブラックボックスになりにくい) •
スプリントゴールに向けた進捗の検査精度が高まる • 日々の、もっと言えば毎時のステータスが見える
スプリントプランニングで実現できると思ってること • スプリントゴールまでの道のりをクリアにする • デイリースクラムの効果を上げる • 開発チーム内の文化ができる • スキルが高い人に引っ張られる •
タスク粒度の基準を「誰でも一人でできる」にすることでチームのレベルにあったタ スク粒度になっていく • 設計や実装の思想が揃う
言いたいこと スプリントプランニングでは スプリントゴールを見通せる細かいタスク分解が良さそう!
おまけ • CSMとかCSPOのトレーニングで言われて今になって分かった気がすること ◦ 「設計はスプリントプランニング内で行うんです」 ▪ →そうだね ◦ 「スプリントの成功はプランニングで8割決まります(トレーナー調べ)」 ▪
→そうかも ◦ 「スプリントプランニングで立てる計画は一つでなければいけないとは決まってませ ん」 ▪ →どうしてもプランニング内でクリアにしきれない不明事項は条件分岐後の計 画もしっかり立ててスプリントゴールを見通せってことかな?
ご清聴ありがとうございました!