Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
スクラムチームの⽴ち上げから
複数フィーチャーチームへのスケーリングに⾄るまで
Sho Kitawaki
KDDI CORPORATION
System Management Department
2020年 9⽉ 26⽇
© 2020 KDDI
1
⾃⼰紹介
名前︓ 北脇 翔(きたわき しょう)
所属︓ KDDI システムマネジメント部
仕事︓ アプリケーション開発
役割︓ Scrum Master / Software Engineer
経験︓ インフラ〜アプ...
© 2020 KDDI
2
サービスのご紹介
au PAY 残⾼へのチャージ au PAY 残⾼による⽀払い
au PAY
残⾼
au ショップ
他 ⼩売店舗
KDDIサービス
キャッシュバック
通信料合算
ポイント
オンライン
クレジットカー...
© 2020 KDDI
3
本⽇お話したいこと
• スクラムを導⼊した話
- なぜ導⼊したのか
- 導⼊にあたってどんなことをしたか
• スクラムチームをスケールした話
- なぜスケールしたのか
- どうやってスケールしたのか
• やってみた気...
© 2020 KDDI
4
当時の開発体制
当時(1年半前)フロントアプリの開発体制は、
企画部⾨と開発チーム(スマホアプリ、サーバ)が3つ
(※サービスの開発体制はもっとたくさん)
企画部⾨ 開発
(サーバ)
開発[社外]
(アプリ)
開発[...
© 2020 KDDI
5
当時の開発体制
そんな体制の中、1つの開発チームと企画チームに
スクラム導⼊しました(これが前半のお話)
開発
(サーバ)
開発[社外]
(アプリ)
企画部⾨
開発[社内]
(アプリ)
スクラム導⼊
© 2020 KDDI
6
なぜ、スクラムを導⼊したのか︖
© 2020 KDDI
7
なぜスクラムを導⼊したか︖
ü 開発の優先順位がチームで共通認識となった状態
ü 2週間程度でアプリをアップデートできる状態
ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する
ü 開発着⼿〜リリースま...
© 2020 KDDI
8
なぜスクラムを導⼊したか︖
ü 開発の優先順位がチームで共通認識となった状態
ü 2週間程度でアプリをアップデートできる状態
ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する
ü 開発着⼿〜リリースま...
© 2020 KDDI
9
なぜスクラムを導⼊したか︖
⼤事(だと思う)なこと
• スクラムを導⼊することが⽬的ではない
• でも、現状の課題に適してそう
- 短い開発サイクルで改善を繰り返す
- 優先順位の明確化
- 実績多数
• あくまで、...
© 2020 KDDI
10
スクラムの導⼊にあたって
ワークショップをやろう
スクラムやろうと決めたが何から始めよう・・・
• 企画も開発もアジャイル、スクラムの理解はばらばら
- 経験者 〜 ⽤語も知らないメンバーまで様々
• 企画と開発の...
© 2020 KDDI
11
2つのワークショップを開催
《アジャイル導⼊ワークショップ》
アジャイル/スクラムの概要・⽬的等の勉強会
《PO実践ワークショップ》
疑似サービスを使ったストーリー作成、バックログの
作成・⾒積もり
企画・開発の各...
© 2020 KDDI
12
イベント・プロセスの設計
PO Devチーム[社内]
(アプリ)
PBL
Excel Redmine
SBL
1 Week
Sprint
ü プロダクトバックログを作った
ü 1週間スプリントでイベント設計
Mon...
© 2020 KDDI
13
やってみてどうだった︖
発⽣
Sprint
課題 アクション 達成
Sprint
SP2 プロダクトバックログが整備されていない
要件の優先順位がわからない
バックログ/更新ルールの整備とリファインメント
の定例化...
© 2020 KDDI
14
やってみてどうだった︖
発⽣
Sprint
課題 アクション 達成
Sprint
SP2 プロダクトバックログが整備されていない
要件の優先順位がわからない
バックログ/更新ルールの整備とリファインメント
の定例化...
© 2020 KDDI
15
やってみてどうだった︖
良かったこと
• 案件の優先順位がわかるようになった
• レビューのフィードバックで認識違いなどを早めにキャッチアップできた
⼀⽅で課題も・・・
• 事業案件が多く1チームではアウトプットに...
© 2020 KDDI
16
やってみてどうだった︖
リリースサイクルの
ボトルネックを探りたい
バリューストリームマップ
を作ってみた
良かったこと
• 案件の優先順位がわかるようになった
• レビューのフィードバックで認識違いなどを早めにキ...
© 2020 KDDI
17
バリューストリームマップ
(1)タスクの洗い出し (2)タスクを順番に並べて全体プロセスを作成
PO / Devの各担当者でリリースまでのタスクを洗い出し
- リリースまでのプロセスを相互理解する
- リリースボト...
© 2020 KDDI
18
バリューストリームマップの気付き
企画
アプリ開発
(社内)
アプリ開発
(社外)
サーバ開発
アプリ
リリース
サーバ
リリース
サーバとアプリの待ち合わせ
リードタイムが⻑い
POが各開発チームに要件説明してい...
© 2020 KDDI
19
バリューストリームマップの気付き
開発
(サーバ)
開発[社外]
(アプリ)
企画部⾨
開発[社内]
(アプリ)
スクラム
確かにスクラムは導⼊したけど・・・
バック
ログ
© 2020 KDDI
20
バリューストリームマップの気付き
開発
(サーバ)
開発[社外]
(アプリ)
企画部⾨
開発[社内]
(アプリ)
スクラム
バック
ログ
プロダクトのバックログは1本ではない。企画部⾨は各開発チームに
それぞれ要件...
© 2020 KDDI
21
• 事業案件 (要求アウトプットが⼤きい)が多く1チームでは
アウトプットに限界がある
(スケールするにしても、緊急対応もあるので柔軟な開発も必要)
• アプリだけ速くなってもリリースできない場合がある
- POが...
© 2020 KDDI
22
スクラムチームのスケーリング
スクラムチームの複数チームへのスケーリングを検討。
複数チームでのスクラムイベント設計はLeSSを参考に。
https://less.works/less/framework/intr...
© 2020 KDDI
23
複数チームでのイベント設計
バックログリファインメント スプリントプランニング デイリースクラ
ム
スプリント
レビュー
振り返り
バックログ①
バックログ②
バックログ③
…
バックログを優先順に並び替える。
(...
© 2020 KDDI
24
• 事業案件 (要求アウトプットが⼤きい)が多く1チームでは
アウトプットに限界がある
(スケールするにしても、緊急対応もあるので柔軟な開発も必要)
• アプリだけ速くなってもリリースできない場合がある
- POが...
© 2020 KDDI
25
コンポーネントチームからフィーチャーチームへ
• これまでは、アプリとサーバが別々のコンポーネントチーム
• アプリとサーバが同⼀チームに属するクロスファンクショナルな
フィーチャーチームに変更
https://l...
© 2020 KDDI
26
アプリ開発チーム(社内)
アプリ開発チーム(社外)
サーバ開発チーム
開発チーム(社内)
アプリ/サーバ
開発チーム(社内)
アプリ/サーバ
開発チーム(社外)
アプリ
PO
1チームスクラム スクラムチームのスケ...
© 2020 KDDI
27
やってみた
© 2020 KDDI
28
どうだった︖
© 2020 KDDI
29
結果から・・・
ü 開発の優先順位がチームで共通認識となった状態
ü 2週間程度でアプリをアップデートできる状態
ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する
ü 開発着⼿〜リリースまでに最低1...
© 2020 KDDI
30
スクラムチームのスケーリングの振り返り
No. 項⽬ 平均 順位
1-1 デイリースクラム 4.5 1
1-2 スプリントプランニング 4.4 3
1-3 スプリントレビュー 4.1 4
1-4 レトロスペクティブ...
© 2020 KDDI
31
スクラムチームのスケーリングの振り返り
No. 項⽬ 平均 順位
2-1 イベントなど、発⾔しにくい雰囲気がある 3.5 7
2-2 やることが不明確な時、⾃分やチームで何をするべきか⾒極め実施することができる 3...
© 2020 KDDI
32
新たな課題への取り組み
改善点
■チーム合同のイベントに改善点が多い
• バックログリファインメントの2h/wの間に、全チームのバックログ
をReadyにすることは困難
• ユーザの利⽤シーンを考えた開発からの提案...
© 2020 KDDI
33
他にもいろいろ取り組んでいますが・・・
本⽇はここまで︕
© 2020 KDDI
34
Thank you
スクラムチームの立ち上げから複数フィーチャーチームへのスケーリングに至るまで(Scrum Fest Mikawa 2020)
Upcoming SlideShare
Loading in …5
×

0

Share

Download to read offline

スクラムチームの立ち上げから複数フィーチャーチームへのスケーリングに至るまで(Scrum Fest Mikawa 2020)

Download to read offline

Scrum Fest Mikawa 2020での発表資料です。

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

スクラムチームの立ち上げから複数フィーチャーチームへのスケーリングに至るまで(Scrum Fest Mikawa 2020)

  1. 1. スクラムチームの⽴ち上げから 複数フィーチャーチームへのスケーリングに⾄るまで Sho Kitawaki KDDI CORPORATION System Management Department 2020年 9⽉ 26⽇
  2. 2. © 2020 KDDI 1 ⾃⼰紹介 名前︓ 北脇 翔(きたわき しょう) 所属︓ KDDI システムマネジメント部 仕事︓ アプリケーション開発 役割︓ Scrum Master / Software Engineer 経験︓ インフラ〜アプリまで広く(浅く)
  3. 3. © 2020 KDDI 2 サービスのご紹介 au PAY 残⾼へのチャージ au PAY 残⾼による⽀払い au PAY 残⾼ au ショップ 他 ⼩売店舗 KDDIサービス キャッシュバック 通信料合算 ポイント オンライン クレジットカード じぶん銀⾏ 現⾦ au PAY プリペイドカード au PAY アプリ QUICPay Apple Pay Android iOS ü 豊富なチャージ⽅法と決済⽅法 ü 会員数が2,300万超
  4. 4. © 2020 KDDI 3 本⽇お話したいこと • スクラムを導⼊した話 - なぜ導⼊したのか - 導⼊にあたってどんなことをしたか • スクラムチームをスケールした話 - なぜスケールしたのか - どうやってスケールしたのか • やってみた気付き - 良かったこと - 苦労した(している)こと
  5. 5. © 2020 KDDI 4 当時の開発体制 当時(1年半前)フロントアプリの開発体制は、 企画部⾨と開発チーム(スマホアプリ、サーバ)が3つ (※サービスの開発体制はもっとたくさん) 企画部⾨ 開発 (サーバ) 開発[社外] (アプリ) 開発[社内] (アプリ)
  6. 6. © 2020 KDDI 5 当時の開発体制 そんな体制の中、1つの開発チームと企画チームに スクラム導⼊しました(これが前半のお話) 開発 (サーバ) 開発[社外] (アプリ) 企画部⾨ 開発[社内] (アプリ) スクラム導⼊
  7. 7. © 2020 KDDI 6 なぜ、スクラムを導⼊したのか︖
  8. 8. © 2020 KDDI 7 なぜスクラムを導⼊したか︖ ü 開発の優先順位がチームで共通認識となった状態 ü 2週間程度でアプリをアップデートできる状態 ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する ü 開発着⼿〜リリースまでに最低1ヶ⽉程度要する ⽬指す開発の姿 現状(当時) これを埋めたい︕ 2019年の⼤型リリース後、企画-開発で⽬指す姿をディスカッション
  9. 9. © 2020 KDDI 8 なぜスクラムを導⼊したか︖ ü 開発の優先順位がチームで共通認識となった状態 ü 2週間程度でアプリをアップデートできる状態 ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する ü 開発着⼿〜リリースまでに最低1ヶ⽉程度要する ⽬指す開発の姿 現状(当時) それ、スクラムで、できるんじゃない︖ 2019年の⼤型リリース後、企画-開発で⽬指す姿をディスカッション
  10. 10. © 2020 KDDI 9 なぜスクラムを導⼊したか︖ ⼤事(だと思う)なこと • スクラムを導⼊することが⽬的ではない • でも、現状の課題に適してそう - 短い開発サイクルで改善を繰り返す - 優先順位の明確化 - 実績多数 • あくまで、⽬指す開発の姿と現状の差を埋めるために、 スクラムが適しているんじゃない︖という発想 • まずはやってみる
  11. 11. © 2020 KDDI 10 スクラムの導⼊にあたって ワークショップをやろう スクラムやろうと決めたが何から始めよう・・・ • 企画も開発もアジャイル、スクラムの理解はばらばら - 経験者 〜 ⽤語も知らないメンバーまで様々 • 企画と開発のメンバーがお互いの業務をちゃんと知らない
  12. 12. © 2020 KDDI 11 2つのワークショップを開催 《アジャイル導⼊ワークショップ》 アジャイル/スクラムの概要・⽬的等の勉強会 《PO実践ワークショップ》 疑似サービスを使ったストーリー作成、バックログの 作成・⾒積もり 企画・開発の各担当者が - スクラムのフレームワークと各⾃の役割を理解する - バックログ作成と優先順位付けの考え⽅を理解する
  13. 13. © 2020 KDDI 12 イベント・プロセスの設計 PO Devチーム[社内] (アプリ) PBL Excel Redmine SBL 1 Week Sprint ü プロダクトバックログを作った ü 1週間スプリントでイベント設計 Mon Tue Wed Thu Fri デイリースクラム BLリファイン メント SPレビュー 振り返り プランニング
  14. 14. © 2020 KDDI 13 やってみてどうだった︖ 発⽣ Sprint 課題 アクション 達成 Sprint SP2 プロダクトバックログが整備されていない 要件の優先順位がわからない バックログ/更新ルールの整備とリファインメント の定例化 SP5 SP2 企画-開発間でのコミュニケーションが⾜りない 連絡⼿段が統⼀されていない PO-Dev全員でSlack利⽤、アカウント整備 SP9 SP6 企画内レビューで仕様変更の⼿戻りが多い 実機レビューを定例化 アプリのレビュー環境を整備 SP5 SP2 優先タスクを⾒落としがち Redmineのスプリントバックログが⾒づらい Redmineのタスクツリーを優先順位で設定、 使い⽅を共有 SP1 SP5 Slackでの問い合わせ⽅法(聞き⽅)を決める、投げっぱなし で回答リードタイムがかかる 質問はClosedQuestion、案を出して確認 をルール化 SP7 SP4 Slackでスピーディーに確認できるようになったが、QAが仕様 書に反映されおらず認識漏れがある QA結果をSlackにPIN留め、朝会後に毎⽇ チーム内共有する SP5 SP3 スプリントレビューの事前準備や周知が⾜りない スプリントレビューの実機準備とレビューコメント メモ作成&Slack通知を毎週持ち回り化 SP5 SP4 実装、PRレビュー以外の作業をした際の適切なタスクがない バッファチケットの共有、⼊⼒⽅法の再周知 SP4 … 0 2 4 6 8 10 12 取組 着⼿ アクションした課題の数 ■課題解決のアクション SP2 SP4 SP6 SP8 SP10
  15. 15. © 2020 KDDI 14 やってみてどうだった︖ 発⽣ Sprint 課題 アクション 達成 Sprint SP2 プロダクトバックログが整備されていない 要件の優先順位がわからない バックログ/更新ルールの整備とリファインメント の定例化 SP5 SP2 企画-開発間でのコミュニケーションが⾜りない 連絡⼿段が統⼀されていない PO-Dev全員でSlack利⽤、アカウント整備 SP9 SP6 企画内レビューで仕様変更の⼿戻りが多い 実機レビューを定例化 アプリのレビュー環境を整備 SP5 SP2 優先タスクを⾒落としがち Redmineのスプリントバックログが⾒づらい Redmineのタスクツリーを優先順位で設定、 使い⽅を共有 SP1 SP5 Slackでの問い合わせ⽅法(聞き⽅)を決める、投げっぱなし で回答リードタイムがかかる 質問はClosedQuestion、案を出して確認 をルール化 SP7 SP4 Slackでスピーディーに確認できるようになったが、QAが仕様 書に反映されおらず認識漏れがある QA結果をSlackにPIN留め、朝会後に毎⽇ チーム内共有する SP5 SP3 スプリントレビューの事前準備や周知が⾜りない スプリントレビューの実機準備とレビューコメント メモ作成&Slack通知を毎週持ち回り化 SP5 SP4 実装、PRレビュー以外の作業をした際の適切なタスクがない バッファチケットの共有、⼊⼒⽅法の再周知 SP4 … 0 2 4 6 8 10 12 取組 着⼿ アクションした課題の数 ■課題解決のアクション SP2 SP4 SP6 SP8 SP10 半年ほどやってみて、徐々に浸透
  16. 16. © 2020 KDDI 15 やってみてどうだった︖ 良かったこと • 案件の優先順位がわかるようになった • レビューのフィードバックで認識違いなどを早めにキャッチアップできた ⼀⽅で課題も・・・ • 事業案件が多く1チームではアウトプットに限界がある • アプリだけ速くなってもリリースできない場合がある
  17. 17. © 2020 KDDI 16 やってみてどうだった︖ リリースサイクルの ボトルネックを探りたい バリューストリームマップ を作ってみた 良かったこと • 案件の優先順位がわかるようになった • レビューのフィードバックで認識違いなどを早めにキャッチアップできた ⼀⽅で課題も・・・ • 事業案件が多く1チームではアウトプットに限界がある • アプリだけ速くなってもリリースできない場合がある
  18. 18. © 2020 KDDI 17 バリューストリームマップ (1)タスクの洗い出し (2)タスクを順番に並べて全体プロセスを作成 PO / Devの各担当者でリリースまでのタスクを洗い出し - リリースまでのプロセスを相互理解する - リリースボトルネックを抽出する
  19. 19. © 2020 KDDI 18 バリューストリームマップの気付き 企画 アプリ開発 (社内) アプリ開発 (社外) サーバ開発 アプリ リリース サーバ リリース サーバとアプリの待ち合わせ リードタイムが⻑い POが各開発チームに要件説明していて 負荷が⼤きくリードタイムを要する
  20. 20. © 2020 KDDI 19 バリューストリームマップの気付き 開発 (サーバ) 開発[社外] (アプリ) 企画部⾨ 開発[社内] (アプリ) スクラム 確かにスクラムは導⼊したけど・・・ バック ログ
  21. 21. © 2020 KDDI 20 バリューストリームマップの気付き 開発 (サーバ) 開発[社外] (アプリ) 企画部⾨ 開発[社内] (アプリ) スクラム バック ログ プロダクトのバックログは1本ではない。企画部⾨は各開発チームに それぞれ要件を提⽰し、サーバとアプリの開発で優先度が不⼀致の状態。 要求 仕様 要求 仕様
  22. 22. © 2020 KDDI 21 • 事業案件 (要求アウトプットが⼤きい)が多く1チームでは アウトプットに限界がある (スケールするにしても、緊急対応もあるので柔軟な開発も必要) • アプリだけ速くなってもリリースできない場合がある - POが各開発チームに要件説明、リードタイムを要する - サーバとアプリの待ち合わせリードタイムが⻑い スクラムチームを複数チームにスケーリング 1チームスクラムの課題(再掲)
  23. 23. © 2020 KDDI 22 スクラムチームのスケーリング スクラムチームの複数チームへのスケーリングを検討。 複数チームでのスクラムイベント設計はLeSSを参考に。 https://less.works/less/framework/introduction?preferred_lang=jp
  24. 24. © 2020 KDDI 23 複数チームでのイベント設計 バックログリファインメント スプリントプランニング デイリースクラ ム スプリント レビュー 振り返り バックログ① バックログ② バックログ③ … バックログを優先順に並び替える。 (直近のスプリント分) どのチームがどのバックログを 実施するかを決める。 各開発 チーム PO 開発チーム 全員 バックログ① タスク① タスク② タスク③ バックログをタスク に分解し各タスク を⾒積もる。 タスクは1⽇以内 のサイズ。 バックログを、開発着⼿できる 状態(Ready)にする。 PO 開発チーム 全員 各開発 チーム チームの進捗、 課題を確認。 スプリントの成果物を 実機でレビュー。 PO 開発チーム 全員 PO 開発チーム 全員 ① ② ① ② 各開発 チーム チーム内 振り返り。 振り返りのPO/チーム 間共有。 2h/w 1h/w 15m/d 0.5h/w2h/w 0.5h/w1h/w • 各チームのイベント • 全チーム合同のイベント をそれぞれ設計 バックログ① バックログ② バックログ③ チームA チームB チームC 1 Week Sprint
  25. 25. © 2020 KDDI 24 • 事業案件 (要求アウトプットが⼤きい)が多く1チームでは アウトプットに限界がある (スケールするにしても、緊急対応もあるので柔軟な開発も必要) • アプリだけ速くなってもリリースできない場合がある - POが各開発チームに要件説明、リードタイムを要する - サーバとアプリの待ち合わせリードタイムが⻑い クロスファンクショナルなフィーチャーチーム 1チームスクラムの課題(再掲) スクラムチームを複数チームにスケーリング
  26. 26. © 2020 KDDI 25 コンポーネントチームからフィーチャーチームへ • これまでは、アプリとサーバが別々のコンポーネントチーム • アプリとサーバが同⼀チームに属するクロスファンクショナルな フィーチャーチームに変更 https://less.works/less/structure/feature-teams?preferred_lang=jp
  27. 27. © 2020 KDDI 26 アプリ開発チーム(社内) アプリ開発チーム(社外) サーバ開発チーム 開発チーム(社内) アプリ/サーバ 開発チーム(社内) アプリ/サーバ 開発チーム(社外) アプリ PO 1チームスクラム スクラムチームのスケーリング後 PO 案件 案件 優先順を 決める バックログA バックログB バックログC バックログD … • POが各チームに要件を個別に説明(負荷⼤) ⼀元的な案件の優先度はなし • アプリとサーバに別れたコンポーネントチーム • アプリとサーバの待ち合わせリードタイムが発⽣ • 全チームイベントで要件共有(PO負荷低減) • バックログの優先順位を⼀元化して明確化 • アプリとサーバが同じチーム(フィーチャーチーム)で 最優先のバックログを実⾏ バックログ JIRA スクラムチームのスケーリング まとめ
  28. 28. © 2020 KDDI 27 やってみた
  29. 29. © 2020 KDDI 28 どうだった︖
  30. 30. © 2020 KDDI 29 結果から・・・ ü 開発の優先順位がチームで共通認識となった状態 ü 2週間程度でアプリをアップデートできる状態 ü 開発の要件毎の優先度が決まっていない、要件変更が急に発⽣する ü 開発着⼿〜リリースまでに最低1ヶ⽉程度要する ⽬指す開発の姿 現状(当時) ■再掲︓ 2019年の⼤型リリース後、企画-開発で⽬指す姿をディスカッション ü バックログの1本化で優先度が明確になった ü 25回以上/年 のリリースが達成
  31. 31. © 2020 KDDI 30 スクラムチームのスケーリングの振り返り No. 項⽬ 平均 順位 1-1 デイリースクラム 4.5 1 1-2 スプリントプランニング 4.4 3 1-3 スプリントレビュー 4.1 4 1-4 レトロスペクティブ 4.4 2 1-5 オーバーオールレトロスペクティブ 3.4 6 1-6 プロダクトバックログリファインメント 3.6 5 ■スクラムイベント チームアンケート結果(5段階) 良かった点 • デイリースクラムでコンポーネントに関わらずタスクのゴール・優先順が把握できる • チーム内振り返りは、チームの課題が解決しやすくなった 改善点 • 全体振り返りは、チームのローカルな改善になりがちで参加意識が薄れてしまう • バックログリファインメントで全チームのバックログを2h/wの間に Readyにすることは困難
  32. 32. © 2020 KDDI 31 スクラムチームのスケーリングの振り返り No. 項⽬ 平均 順位 2-1 イベントなど、発⾔しにくい雰囲気がある 3.5 7 2-2 やることが不明確な時、⾃分やチームで何をするべきか⾒極め実施することができる 3.8 2 2-3 ⾃分の担当分野だけではなく、チームメンバーの担当タスクをサポートすることができる 3.6 3 2-4 チーム間の情報共有はうまくいっている 3.4 9 2-5 社内と社外の拠点間の情報共有は上⼿くいっている 3.3 10 2-6 POとの情報共有がスムーズにできている 3.6 4 2-7 開発するアイテムについてなぜ開発するのか、ユーザにとっての価値がわかる 3.5 6 2-8 ユーザの利⽤シーンを考えてもっとこうしたらいいという提案ができるようになった 3.1 11 2-9 サーバとアプリ間で、いずれかの開発待ちでリードタイムが伸びることがなくなった 3.8 1 2-10 コンポーネントチームからフィーチャーチーム化を進めました。どちらが良いと感じたか 3.5 5 2-11 メンバーの幸福度はアップしている 3.5 7 ■チーム変更 チームアンケート結果(5段階) 良かった点 ・アプリとサーバが同じチームになりリードタイムの短縮を実感 改善点 ・ユーザの利⽤シーンを考えた開発からの提案
  33. 33. © 2020 KDDI 32 新たな課題への取り組み 改善点 ■チーム合同のイベントに改善点が多い • バックログリファインメントの2h/wの間に、全チームのバックログ をReadyにすることは困難 • ユーザの利⽤シーンを考えた開発からの提案 ■アクション • 全体のバックログリファインメントを⾒直し - 全体のバックログリファインメントは要件概要+QAのみ - 各開発チームとPOでリファインメント • POからの仕様を待つのではなく開発チームでも仕様案作成をリード - ConfluenceやCacooを使いチームでモブ設計ワークを実施
  34. 34. © 2020 KDDI 33 他にもいろいろ取り組んでいますが・・・ 本⽇はここまで︕
  35. 35. © 2020 KDDI 34 Thank you

Scrum Fest Mikawa 2020での発表資料です。

Views

Total views

213

On Slideshare

0

From embeds

0

Number of embeds

124

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×