Submit Search
小さく始める大規模スクラム
•
103 likes
•
35,483 views
Keisuke Tsukagoshi
Follow
エンタープライズアジャイル勉強会でお話しさせて頂く内容です。 http://www.ogis-ri.co.jp/event/1247455_6738.html
Read less
Read more
1 of 78
Download now
Downloaded 113 times
More Related Content
小さく始める大規模スクラム
1.
株式会社リクルートライフスタイル 塚越啓介・今井恵⼦ ⼩さく始める⼤規模スクラム
2.
⼤規模スクラムってどういうこと? PO Team SM #000 はじめに
3.
PO Team SM Team SM Team SM Team SM ⼤規模スクラムってこういうこと! #000 はじめに
4.
⾃⼰紹介 #001 Airレジについて AirREGI海外版 CSM /
Engineer Recruit LifeStyle 啓介 k t s u k a g o 塚越 AirREGI海外版 CSPO Recruit LifeStyle 今井i k e k o 恵⼦
5.
本⽇のAgenda Air REGIについて なぜチャレンジしたのか? ⼤規模スクラムはじめました 運営ハードモード チームと歩んだ半年 まとめ #000 はじめに #
001 # 006 # 002 # 003 # 004 # 005
6.
チームの歩み #000 はじめに 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ
7.
AIR REGIについて Agenda #001
8.
AirREGIってどんなサービス? 飲⾷店、⼩売店の会計業務を⽀える シンプルでカンタンな⾼性能POSレジアプリ #001 Airレジについて
9.
↑ 今回はこっちの話 今回のお話 Recruit LifeStyle ↑ 前回こっちの話をしました Air REGI Air PAYMENT Air RESERVE Air WAIT 国内版 Air REGI 海外版 #001 Airレジについて
10.
開発チームを取り巻く環境 Scrum Team PO SM Team Design Group Marketing Group Development Group Business Team PRODUCER Sales Design
Team UX UI GM GM GM #001 Airレジについて
11.
なぜチャレンジしたのか Agenda #002
12.
スクラムって少⼈数のイメージ スクラムって少⼈数のイメージ ⼤規模なスクラムってあまり聞かない #002 なぜチャレンジしたのか
13.
プロダクトもチームも、作って終わりではない ◯ プロダクト✕ プロジェクト 継続的な改善が⾏える組織にしたい #002
なぜチャレンジしたのか スカイツリー
14.
What(何を作るか)を継続的に改善する プロダクト ユーザーが 求める物 Release FB Release FB Release FB Release FB #002 なぜチャレンジしたのか → マーケットニーズが⾒えづらい 海外という未知の領域でのプロダクト開発
15.
How(どうやって作るか)を継続的に改善する 定期的に改善することで開発速度を⾼めていく ●コード量 ●複雑度 ●コード量 ●複雑度 ソフトウェアは放っておくと⾃然と複雑になっていく #002 なぜチャレンジしたのか
16.
⼤規模スクラムはじめました Agenda #003
17.
⼤規模スクラムはじめました 導⼊ 構築 理解 #003
⼤規模スクラムはじめました
18.
⼤規模スクラムはじめました 導⼊ 構築 理解 #003
⼤規模スクラムはじめました
19.
垂直⽴ち上げもできますが PO Team SM Team SM Team SM Team SM 失敗した時の影響範囲が⼤きい #003 ⼤規模スクラムはじめました
20.
1チームずつの導⼊がおすすめです! PO Team SM Team SM Team SM Team SM 開発と同じく⼩さな成功体験の積み重ねが重要 #003 ⼤規模スクラムはじめました
21.
⼤規模スクラムはじめました 導⼊ 構築 理解 #003
⼤規模スクラムはじめました
22.
複数スクラムチームで構成もできますが PO Team SM iOS Team PO Team SM Infra Team PO Team SM Android
Team PO Team SM WEB Team #003 ⼤規模スクラムはじめました
23.
複数開発チームでの構成がおすすめです! PO Team SM Dev Team Team SM Dev Team Team SM Dev
Team Team SM Dev Team #003 ⼤規模スクラムはじめました
24.
決定スピードアップに繋がる 横断組織がない → ボトルネックがなくなる POが1⼈
→ ⼿戻りや持ち帰りの調整がなくなる #003 ⼤規模スクラムはじめました
25.
職能別チームにもできますが iOS iOS iOS Team iOS iOS WEB WEB Web Team WEB WEB Infra Infra Infra
Team Infra Infra Android Android Android Team Android Android #003 ⼤規模スクラムはじめました
26.
職能横断チームがおすすめです! Infra Android WEB iOS A Team Infra Android WEB iOS D Team Infra Android WEB iOS B
Team Infra Android WEB iOS C Team #003 ⼤規模スクラムはじめました
27.
Task Task Task
Task Task Task And roid iOS Task Task 他の職能を⾃然と習得していく #003 ⼤規模スクラムはじめました
28.
増員するとVelocityが安定しなくなる ちなみに、増員する時は注意が必要 ↓ リリース予測ができず、中⻑期計画が⽴てられない #003 ⼤規模スクラムはじめました
29.
各チームに追加していくと全チームが不安定に Team SM Dev Team Team SM Dev Team Team SM Dev
Team Team SM Dev Team #003 ⼤規模スクラムはじめました
30.
新規メンバー受け⼊れ専⽤チームを作る Team SM Dev Team Team SM Dev Team SM Dev
Team SM Dev Team Mentor #003 ⼤規模スクラムはじめました
31.
⼤規模スクラムはじめました 導⼊ 構築 理解 #003
⼤規模スクラムはじめました
32.
1番やっちゃダメなのは全⾯導⼊! 各所でハレーションが起こりやすい 全員が初⼼者なので、問題があった時混乱が⽣じる 失敗した時の影響範囲が⼤きい #003 ⼤規模スクラムはじめました
33.
周囲の協⼒が必要です #003 ⼤規模スクラムはじめました
34.
周囲を巻き込む時気をつけるべきこと #003 ⼤規模スクラムはじめました 今までのやり⽅を否定しない ⼀⼈で推し進めてはいけない 協⼒者が⼀⼈もいない状態でやるべきではない
35.
運営ハードモード Agenda #004
36.
運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
37.
運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
38.
1チームの時と同じやり⽅では上⼿くいかない! ひとりひとりの当事者意識が⽋如する ⼤⼈数だとディスカッションにならない #004 運営ハードモード
39.
⼤⼈数に適したアレンジ⽅法を⾒つけていく セレモニー⾃体を振り返ろう PO/SMでセレモニーのやり⽅を振り返り、 継続的に改善していく #004 運営ハードモード
40.
振り返りから⽣まれたTRYの例 ⼤⼈数だとディスカッションにならない → 振り返りなどで代表者制を導⼊ スプリントレビューが⼤量&無意味なものに → スプリント中に都度PO確認 チーム間の連携が上⼿くいかない →
デイリースクラムを偵察に⾏く #004 運営ハードモード
41.
運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
42.
組織の中で何かと⽬⽴ってしまう なんか 変わったこと やってる 本当に成果 でてるの? 今までのやり⽅で いいんじゃない? #004 運営ハードモード
43.
共通⾔語で話そう レトロスペクティブ ベロシティ ストーリーポイント セレモニー スプリント スクラム アクセプタンスクライテリア デイリースクラム プロダクトバックログ リファインメント スクラムマスター プロダクトオーナー スプリントレビュー ワーキングアグリーメント Done/Undone #004 運営ハードモード
44.
透明性を上げよう Scrum Team PO SM Team Business Team PRODUCER Sales GM Marketing Group GM Development Group PO
SM PM #004 運営ハードモード
45.
運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
46.
POの負荷が膨⼤になる /ステークホルダー調整/etc… 1週間100を超えるチケット /膨⼤な要件定義 /チームメンバーからの質疑応答 /様々な決め事 #004
運営ハードモード
47.
チームの成⻑が求められる 具体例は次のセクションで チームへの権限委譲、当事者意識の醸成が重要 #004 運営ハードモード
48.
チームと歩んだ半年 Agenda #005
49.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
50.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
51.
過保護なPO、受け⾝なチーム #005 チームと歩んだ半年 https://www.flickr.com/photos/dirigentens/4592361218/ POがチームにチケットを割り当てる POがチーム間、部署間の調整を⾏う POが仕様を細かく決めないと開発できない
52.
効率の良い作業分担をチームで決める ⼦離れ、親離れ #005 チームと歩んだ半年 https://www.flickr.com/photos/tambako/8601484790/ 仕様の細かい部分はチームが考える チーム間や他部署間調整をチーム⾃⾝で⾏う
53.
リーダーが欲しい #005 チームと歩んだ半年 リーダーが欲しいです Team スクラムではメンバーひとりひとりが⾃律的であり 全員が圧倒的当事者意識をもっていてつまり… PO そうだ、リーダーじゃなくメンターを置こう PO とはいえ困ったときに相談したり、 開発の⼤⽅針を決める⼈が必要です Team
54.
コンポーネントメンター制度 #005 チームと歩んだ半年 ✕ 責任者/管理者
◯ 先⽣/相談役 承認者になってはいけない コンポーネント毎にボランティアで構成 教育したり、相談に乗ったりする
55.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
56.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
57.
誰のために何を作っているのかわからない #005 チームと歩んだ半年 ターゲットが海外、かつtoBなので⾝近ではなく 誰にどう使われるのかピンとこない ↓ 要件通りに作ればいいんでしょ
58.
ユーザーに会いに⾏こう #005 チームと歩んだ半年 現地調査で業務を観察&インタビュー 業務フローを整理し ユーザーストーリーマッピングで⾒える化
59.
ユーザーになりきることで使いにくさや 改善ポイントが⾒えてくる ロールプレイでユーザーの気持ちを体感 #005 チームと歩んだ半年 Sprint Reviewの時間でお店屋さんごっこ
60.
チームが顧客視点を持つということ #005 チームと歩んだ半年 決定/合意プロセスが早くなる 業界の「当たり前」を知る POやビジネスサイドと⽬線が揃う
61.
技術知識とドメイン知識のバランス #005 チームと歩んだ半年 ドメイン知識 技 術 的 専 ⾨ 知 識 このあた りを⽬指 そう こっちを ⽬指しが ちですが
62.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
63.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
64.
クロスファンクショナルなチームへ #005 チームと歩んだ半年 上のチケットはアプリの⼈しかできないんで、 下の⽅のチケットからやります Team 優先順位の⾼いチケットから開発してね PO 誰がどのチケットでもとれればもっと早く ユーザーに価値を提供できるのに… PO
65.
クロスファンクショナルなチームへ #005 チームと歩んだ半年 なんとかして!スクラムマスター! PO ⾊々必要なんだな… PO SM まず、まとまった期間が必要ですね 教えてあげる先⽣も必要です そんなにカンタンにできないっすよ
66.
メンバーのスキルを⾒える化する #005 チームと歩んだ半年 誰が何を得意としているかがわかる 誰がメンターになり得るかわかる Name iOS
Android WEB インフラ Design ⾚⽊ ◯ ✕ ◎ ◯ ◯ ⽮代 ◯ ✕ ◎ ◯ △ 張 ◎ ◯ △ ◯ △ 島村 ◎ ✕ △ △ △
67.
五⼗六式に教える #005 チームと歩んだ半年
68.
それ以外のチケットを作らない #005 チームと歩んだ半年 APP キャッシャーとして注⽂をとりたい APP
キャッシャーとして現⾦会計したい APP キャッシャーとしてクレジット会計したい APP キャッシャーとしてレシートを印字したい ユーザーにとって開発チームのスキルは関係ない 優先順位を強烈に意識づける
69.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
70.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
71.
無駄をなくそう #005 チームと歩んだ半年 事前に調査しないと開発できません Team じゃあ調査してください PO 開発以外のところに無駄な時間が かかっている気がする… PO こちら調査結果です Team 1週間後
72.
無駄を⾒える化する #005 チームと歩んだ半年 無駄は悪いものだと認識させる 無駄を⽇常的に削る意識をつける 結果、開発にかけられる時間が増える
73.
要件定義から開発完了までを早く #005 チームと歩んだ半年 要件定義 PO ワイヤー作成 UX Designer デザイン作成 UI
Designer input input 開発 Team input 要件定義 ワイヤー作成 PO UX Designer UI Designer 開発 Team Team
74.
リファインメントで⼀気にやる #005 チームと歩んだ半年 Engineer/Designer/PO間で共通認識が作りやすい コスト安/ユーザビリティのバランスが取りやすい cost cost デザイナーだけで 考えたUIUX チームで考えた UIUX
75.
チームの歩み 受け⾝ ⾃発 顧客 視点 多能⼯ スピード アップ #005 チームと歩んだ半年
76.
まとめ Agenda #006
77.
スプリント計画 1週間の流れ ⽉ ⽕⽔ ⽊
⾦ ⽔ リファインメント ロールプレイ SHへエスカレ チーム毎振り返り 全体振り返り デイリースクラム 開発 #006 まとめ セレモニー振返り
78.
まとめ #006 まとめ 導⼊ 運営 成⻑ ⼩さく始めて横展する 細かく振り返り、継続的に改善する チームの⾃律性を育てていく 関係者対して透明性を上げる
Download