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
N.Okamoto
February 26, 2019
Technology
0
1.3k
開発チームクエスト
【大阪】RAKUS Meetup Osaka #2 アジャイル Night
N.Okamoto
February 26, 2019
Tweet
Share
More Decks by N.Okamoto
See All by N.Okamoto
meetup_20210608_roum
ygno
0
1.3k
Other Decks in Technology
See All in Technology
Evolving Architecture
rainerhahnekamp
3
220
MasterMemory v3 最速確認会
yucchiy
0
310
20241220_S3 tablesの使い方を検証してみた
handy
4
870
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
1
5k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
54k
Accessibility Inspectorを活用した アプリのアクセシビリティ向上方法
hinakko
0
110
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
6
1.5k
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
1
16k
知っててうれしい HTTP Cookie を使ったセッション管理について
greendrop
1
110
三菱電機で社内コミュニティを立ち上げた話
kurebayashi
1
250
20241218_マルチアカウント環境におけるIAM_Access_Analyzerによる権限管理.pdf
nrinetcom
PRO
3
150
OPENLOGI Company Profile for engineer
hr01
1
17k
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
5
190
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
340
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
112
50k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Transcript
開発チームクエスト RAKUS Meetup Osaka #2 アジャイルNight 2019.2.26
• 岡本 直樹 • 2016年入社 • 担当商材 自己紹介 ちから: 10
すばやさ: 15 こうげきりょく: 28 しゅびりょく: 30 ---------------------- ぶき: Swiftのつるぎ よろい: Javaのよろい たて: Gradleのたて つよさ うぉーきんぐ ぱそこんいじり あにめ げーむ えいが しゅみ
楽楽精算開発チームがスクラムを開始して1年 1年の間にチームに起こった出来事とその対処について 振り返ってみようと思います。 今日のテーマ
iPhoneアプリ開発のため スクラムチーム発足
~チームの状況~ • 課題 ー ベテラン勢と若手の Lv差が顕著であり、若手 がタスクをこなすにはベテランのフォローが 不可欠。 ー チームメンバー全員が
iPhoneアプリの開発経 験なし。 Lv68:ベテラン Lv67:ベテラン Lv61:ベテラン Lv60:派遣 Lv20:若手 Lv17:若手 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取入れた作戦~ • ベテランによるタスクの詳細化 ー ベテラン勢と若手の間で、 遂行できるタスクの難易度にバラツキがあった ため、 スプリント開始前に ベテランがタスクを検討 し、能力に応じて各メンバーに割り当てるようにした。
▶こうげき じゅもん ぼうぎょ どうぐ ▶ろぐいんしょり がめんせんい ゆにっとてすと きーにゅうりょく APIりくえすと
~取入れた作戦~ • 役割分担による各個撃破 ー メンバーの役割をサーバサイド/アプリサイドで分け、担当者が 各領域のタスクに専念 できるように した。 AppSide ServerSide
~取入れた作戦~ • スプリントの2週間サイクル ー iPhoneアプリの作成は未経験分野であり、 1週間毎にアウトプットを出せるイメージを持てなかった ので、まずは2週間サイクルでスプリントを開始した。 HP: 50000/50000 ちから:
16 すばやさ: 20 こうげきりょく: 75 しゅびりょく: 80 ---------------------- ぶき: Javaのつるぎ よろい: DDDのよろい たて: スクラムのたて つよさ 挑む敵が強大で1週間程度ではダメージを与えられるイメージがなかった
ベテランの離脱と新規メンバーの加入
~チームの状況~ • 課題 ー ベテランの離脱と新規メンバーの加入により フォローする側とされる側の比率が 1:1 と なりフォロー体制に若干の不安が出てきた。 ー
iPhoneアプリの2次開発で、既存サービスとの機 能統合が決まり、1次開発と比べ考慮すべき仕様 が増えた。 Lv78:ベテラン Lv71:ベテラン Lv70:派遣 Lv21:若手 Lv18:若手 Lv40:派遣 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取止めた作戦~ • 役割分担による各個撃破 ー 以下2点の問題が発生し継続は不要と判断。 ・iPhoneアプリの2次開発で、既存 Webサービスとの統合を行うことになり、仕様のすり合わせを密に 行う必要が出てきたため、アプリサイドとサーバサイドで 役割を分ける意味合いが薄くなった 。
・ベテラン1名がチームから離脱してしまったため、 役割分担をするためのリソースが不足 してしまっ た。
~取入れた作戦~ • 開発内リファインメント会議 ー 2次開発で 複雑さを増した仕様に対応 するため実施。 ベテラン勢が仕様検討に時間を割けるように、スプリント毎に1回 MTG形式で行う。 ▶さくせん
こうげき じゅもん ぼうぎょ どうぐ ▶めいれいさせろ いのちをだいじに みんながんばれ じゅもんをつかうな がんがんいこうぜ 稼働に無駄が発生しないように、まずはベテラン勢で仕様を決定する。 Complex specification
さらなるメンバーの増員
~チームの状況~ • 課題 ー 新規メンバーの加入により、フォローする側 とされる側の比率が 3:5で不均衡な状態。 ー 恒常的にベテランがフォローに時間を取られ ることにより、タスクの消化速度の悪化がし
てしまった。 Lv83:ベテラン Lv76:ベテラン Lv75:派遣 Lv22:若手 Lv19:若手 Lv45:派遣 Lv45:派遣 Lv45:中堅 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取止めた作戦~ • スプリントの2週間サイクル ー メンバーの増加によって、スプリント計画時に洗い出さなければならない タスク量が飛躍的に増加 これにより、主にタスクの洗い出しを担当していたベテラン勢が疲弊してしまった。 スプリントの サイクルを1週間に縮めて相対的に計画タスクを少なく することで解決。
~変更した作戦~ • ベテランによるタスクの詳細化 ー これまではベテランがタスクを詳細化してから下位メンバーに割り当てるという手法をとっていた が、メンバーが増え、 情報伝達のオーバーヘッドが無視できないほど大きくなった ため、タスクの詳 細化自体をペアワークで実施 するようにした。
Sprint Backlog Item ベテランと わかて の ペアワークれんけい!
~取入れた作戦~ • モブプロの実践 ー メンバー間の 知識格差が目立ってきたた め、これを 埋める手法 として試験的に導入。 まずは、小粒なタスクを切り出して、効果を見極めることにした。
1つのタスクに全員で取り掛かる Small Tasks
ベテランの離脱と新卒加入
~チームの状況~ • 課題 ー フォローする側とされる側の比率が 2:5でか なり不均衡な状態になってしまた。 ー ベテラン勢の人数が下位メンバーに対して不 足しているため、フォローが行き届かず、タ
スクをこなすこと自体が困難になってしまっ た。 Lv80:ベテラン Lv79:派遣 Lv23:若手 Lv20:若手 Lv47:派遣 Lv48:中堅 Lv15:新卒 【Lvの目安】 Lv60以上:「下位メンバーのフォローが可能」 Lv50以上:「通常タスクが実施可能」 Lv30以上:「フォローありで通常タスクが実施可能」 Lv30未満:「フォローありで低難易度タスクが実施可能」
~取入れた作戦~ • チームの分割 ー 下位メンバーをフォロー可能な人員が減ってしまったため、 全メンバー一律のフォローは一旦諦め 、 ベテラン/中堅のチームと若手 /新卒のチームにメンバーを分け、それぞれのチームの上位メンバーが 下位メンバーのフォローを担当するようにした。
Training Mission Main Mission
~変更した作戦~ • 開発内リファインメント会議 ー 当初は、無駄な稼働をかけないため ベテラン勢のみで行っていた仕様検討会議だったが、 不要に知識の分断を招いた だけだったので、原則全員参加に変更。 ▶さくせん こうげき
じゅもん ぼうぎょ どうぐ めいれいさせろ いのちをだいじに ▶みんながんばれ じゅもんをつかうな がんがんいこうぜ
~変更した作戦~ • モブプロの実施 ー 試験的に導入していたモブプロを以下の要領で、本格的にプロジェクトに組込む。 ・スプリントの最終日の午後に実施。 ・題材は基本的にリファクタリング。 ・モブプロの時間を使って当該スプリントで発生した各プルリクの共有を実施。
~取止めた作戦~ • ベテランによるタスクの詳細化 ー ベテランの人数が減ってしまったため、 メンバー毎にタスクを詳細化することが難しくなった 。 そこで、タスクの詳細化をモブワークで実施 、全員でタスクの詳細化に取り組み、フォロー稼働削減 を目指した。
Sprint Backlog Item ベテランチーム の モブワークれんけい!
1年を振り返って
最も悪かった作戦 • ベテランによるタスクの詳細化 ー ベテランの稼働圧迫、知識伝達のオーバーヘッド、知識格差の拡大と、百害あって一利もなかった。 そもそも、この作戦は「 ベテランが仕様を決める →下位メンバーが実行する 」の流れのほうが 稼働が
有効に使えるというウォーターフォール的発想 により決められていた節があり、スクラムの思想に合 致していなかった。
最も良かった作戦 • モブプロ/モブワークの実践 ー 知識の共有化 、プログラミング思想の統一 、タスク内容の全体周知 と色々な面で活用することがで きた。また、結果として「ベテランによるタスクの詳細」により起こっていた、フォローされる側/ する側というチームの分断が解消でき、
お互いをフォローし合えるチーム を目指せるようになった。 LvXX:ベテラン LvXX:派遣 LvXX:派遣 LvXX:中堅 LvXX:若手 LvXX:若手 LvXX:新卒 DifficultTasks
Our battle is about to come.
素材 • RPGドット(http://www.geocities.co.jp/Milano-Cat/3319/)