Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

小さく始める大規模スクラム

25.019 visualizaciones

Publicado el

エンタープライズアジャイル勉強会でお話しさせて頂く内容です。
http://www.ogis-ri.co.jp/event/1247455_6738.html

Publicado en: Tecnología
  • Sé el primero en comentar

小さく始める大規模スクラム

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

×