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
Mitsui
May 22, 2023
Programming
0
120
チームのアジャイルな活動
チーム内でやってきたいろいろなアジャイルな活動を書き出してみました
Mitsui
May 22, 2023
Tweet
Share
More Decks by Mitsui
See All by Mitsui
チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた
maroon8021
0
1.9k
Valueを使ったふりかえりをやってみた
maroon8021
0
130
TypeScript でつくるフルスタック環境の紹介
maroon8021
2
1k
Other Decks in Programming
See All in Programming
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
300
ニーリーにおけるプロダクトエンジニア
nealle
0
490
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
320
生成AIで日々のエラー調査を進めたい
yuyaabo
0
650
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
120
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
110
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
580
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
160
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
190
Elixir で IoT 開発、 Nerves なら簡単にできる!?
pojiro
1
150
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.4k
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
130
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Optimizing for Happiness
mojombo
379
70k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Invisible Side of Design
smashingmag
299
51k
Into the Great Unknown - MozCon
thekraken
39
1.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
We Have a Design System, Now What?
morganepeng
53
7.7k
Building Applications with DynamoDB
mza
95
6.5k
Music & Morning Musume
bryan
46
6.6k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Transcript
チームのアジャイル Tatsuhiko Mitsui
今日話すこと 今のチームでやってるアジャイルなことをいろいろご紹介します how的な話を中心にしてますが、チームとしてどういうモチベーションで取り組んでいる かを理解してもらえるとありがたいです → ぜひ何か持ち帰ってもらえれば🐇
開発手法と基本的なところの ご紹介
どうやってるの? スクラムでやってます! ❏ ちゃんと全部のイベントやってるよ! ❏ 1週間スプリント ❏ 各種イベントは以下のようは配置 (詳細は次のページから )
プランニング ❏ 事前にやっておくこと ❏ エンジニア: 各PBIの受け入れ条件を明確にして、 SPをつけておく ❏ PO: 順番を並び替え、次スプリントでやりたいことを明確にしておく
❏ プランニング時にやること ❏ POからその時点で検討しているスプリントゴールを共有してもらう ❏ 次スプリントに入れたい PBIを上から確認&サブタスクを切っていく ❏ 一通りPBIの確認が終わったら「作業計画表」に落とし込んで見る ❏ どこまでこのスプリントに積むか見定め、決定する ❏ 必要に応じてスプリントゴールを調整し、最終決定 ❏ スプリント開始!
作業計画表: テンプレ
作業計画表
作業計画表 ❏ PBIがこのあたりで終わりそうかな〜というのを配置してみる ❏ 各種イベント(スプリントレビューや誰かのおやすみ等々)も配置する ❏ ※これは計画なのでスプリント中には動かしません ❏ これをやりはじめてよかったこと ❏
SP的にいけそう、と思っても実際に可視化してみるとしんどそうとか気付ける ❏ デイリースクラムやレトロスペクティブのタイミングで「よかったこと」や「わるかったこと」を把握しや すい -> 仮説検証がよりよくできる!
バックログリファインメント ❏ 厳密にはスクラムイベントではないですが、時間とってやるようにしてます ❏ POとエンジニアでsyncするのが目的 ❏ 次のプランニングまでにチケットをReadyにできるように話し合う ❏ リファインメントの場で Readyにすることもある
❏ できないものとかはプランニングまでに各自やっておく ❏ (あんまり特別なことをやってはいないつもり)
チーム内での「チケットがReadyな状態」とは ❏ 端的にいうと以下 ❏ ストーリーであればストーリーポイントがついている ❏ 調査系チケットであれば TimeBoxを設定している ❏ ストーリーポイントもしくはTimeBoxでの見積もりができている状態とは?
❏ 上記は開発者側で見積もりができていることを指す ❏ 見積もりをするためには PBI上で「どういう目的」で「何をする必要があるか」が把握できるようになっ ている必要がある ❏ そのため必然的にWhat (提供したい価値 / 解決すべき課題) と 完了条件 / 受け入れ基準 がPBI に整っていなければいけない ❏ -> プランニングのタイミングでは「なにをやるか」の話ではなく、「どれをどこまでどう やるか」の話にフォーカスできる
スプリントレビュー ❏ 事前にやっておくこと ❏ エンジニア: レビュー対象のものをコンフルに列挙しておく ❏ スプリントレビュー時にやること ❏ レビュー対象のものを順に見ていく
❏ 今後のスプリントに影響しそうなことがあれば「スプリント中の状況の変化などの共有」として相談す る(参考: https://www.ryuzee.com/contents/blog/7133 ) ❏ 気をつけてること ❏ リリース可否を判断する場ではない ❏ 「作ったものが仕様通りか」というのはスプリントレビュー外で事前に話しておく ❏ -> あくまでこのスプリントレビューでは「実際意図した通り作ってみたけどどうだろ」というところの仮 説検証をする場にする
レトロスペクティブ ❏ Jiraのスプリント閉じます ❏ 現状可視化されているデータとしてはJiraのスプリントレポートくらいしかみてないで す ❏ 本当はもうちょいいろんな指標とか見れたらいいんだろうけど整備中 ❏ スプリント閉じたらすぐふりかえりそのものに移ります
レトロスペクティブ ❏ ファシリテーターはローテーションしてます ❏ ふりかえり手法もそのタイミングごとでファシリテーターが「このふりかえりでやれた らよさそう」というのをピックアップして実施してます ❏ アイスブレイクにはすごく雑多なことを共有してもらってます ❏ ※本当は日頃から気軽にそういう話ができたらいいんだろうなと思いつつ
デイリースクラム ❏ 現状2つ存在してます ❏ 朝: エンジニアだけのデイリー ❏ 夕方: チーム全体のデイリー ❏
エンジニアのデイリー ❏ シンプルに当日の作業計画を考えます ❏ なにかネタがあればデイリーの + / ⊿ をやるようにしています
デイリースクラム ❏ チーム全体のデイリー ❏ スプリント内の状況確認 ❏ その他チーム全体として共有事項があればシェアや相談
その他独自イベント
モブ会 ❏ 開催日時: 毎日16:30~17:00 ❏ チーム全員が集合して、なにか相談事があれば相談するし、とくになければみんな で各々の作業をする時間です ❏ (当初のうちは)意図して集まる場を作っておいたほうがハッピーかなと思い設置 ❏
※夕方にあるチームのデイリーと微妙に役割かぶってたりするから実はちょっと調 整したいと思ってる😇
エンジニアふりかえり ❏ 開催日時: 水曜11:00~12:00 ❏ 最近のレトロスペクティブの場だと「課題としてはわかるものの、具体的なtryに落と し込みにくい。もっと個別で話したほうがよさそう」みたいなネタがぼちぼち多くなっ てきた ❏ とくにエンジニアだけで本当は解決できたり、もしくはエンジニア側である程度固め
てからチームにエスカレーションしたほうがよいものとかもある ❏ それらの話をする場 ❏ 普通のレトロスペクティブより「tryにつなげる」ことを少し意識している
ふりかえりの全体感
雑感 ❏ 多分そのうち慣れてきたり、チームのフェーズが変わってきたタイミングで各種イベ ントの再整理をする必要があると思う ❏ -> イベントを増やしまくって結果として作業時間が減ってベロシティが下がったりあ がらなかったりしたら意味がない ❏ 引き続きうまく良い変化を取り入れていきたい
アジャイルな取り組み
どーやって開発進めてる? ❏ ほぼモブプロでやってます! ❏ 11:00 ~ 18:50くらいまで原則モブプロでやってます ❏ ※みんなだいたい10:00頃出社してます ❏
19:00ギリギリまでやると19:00ちょうどにあがれなくなることが多いため ..(なお現実) ❏ あるPBIやるぞ〜となったらみんなでやります ❏ 誰かがドライバー ❏ 他の人がナビゲーター ❏ さらにもうひとりが俯瞰してみてるマン (or たまに必要に応じて細かな作業をやったり ) ❏ → チームとしてはあくまでそのタイミングで一つの PBIだけに集中するようにしている
ほぼモブプロバナ ❏ ドライバーに関してはちゃんとうまく定期的にまわしたり、そこまで強くない分野のと ころをドライバーが担当する、といった形になってたりします ❏ PRのレビューとかないです。PR作ったらほぼそのまま混ぜます ❏ その場で指摘できるので「うわーこんな細かいところ指摘してごめんな」みたいな感情がなくなりま す ❏
各種IDEの共有機能でみんなで同じコード触りながら進めれます
続: ほぼモブプロバナ ❏ Q. つかれない? ❏ A. 最初は結構疲れた気がする。今は慣れた (多分) ❏
Q. それって効率的なの? ❏ 長期的に見たら効率的なんじゃないかと思ってます。原則チーム内の全員が全部のコードの内容 を知ってます(ちょっと盛ってるけど ) ❏ 良し悪しは置いといて、例えば手が開いてる人がその PBIのテストケースを考えたりとか、ホントに 細かいところの作業をしたり、とかで「その PBI単位」でのフロー効率の最適化は目指せます
❏ Q. ほんとにいいことしかないの? ❏ そんなことはない() ❏ 例えばCopilotくんはIDEのシェア機能に参加してる側には効かなかったりする ❏ モブでやってるとチームとして「終わらせるぞ」みたいな意識が向きすぎると斜に構えた見方をしにく かったりする(そういう意味ではPRレビューはフラットな視点で見れるので価値はありますよね
) ❏ あんまりにもやること、方向性とかが見えてないものには向かない ❏ あたりがついてるタイプの調査とかはみんなでやるとよい ❏ そもそも「なにからはじめたらいいんだ?」みたいなやつとかは個人作業にして、ある程度お 互い見えはじめたタイミングで合流してモブモブとかのほうがよい 続々: ほぼモブプロバナ
意思決定の話 -> チームの誰が意思決定してもいいようにした い ❏ 能力/技術力 ❏ チームとか特定の組織体としての目標 ❏ 周辺情報
これらが揃っていれば誰が意思決定と遂行をしても同じような結果になるのでは? -> そうなるようにチームとして各要素をあわせていく
スタンス的なところ ❏ 誰が何をやってもいい ❏ みんなでできるようになる/みんなでつくる(このビアバッシュの発表もそう) ❏ 適宜仮説検証をしていい方向に変化していこう ❏ →アジャイルソフトウェア開発宣言ぽいことしてる!()
おしまい