Soumettre la recherche
Mettre en ligne
大規模スクラムの失敗から学んだこと #AgileJapan2015
•
191 j'aime
•
70,099 vues
I
Itsuki Sakitsu
Suivre
AgileJapan 2015講演資料
Lire moins
Lire la suite
Ingénierie
Signaler
Partager
Signaler
Partager
1 sur 102
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
Itsuki Kuroda
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
Itsuki Kuroda
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
211101_DXの基礎
211101_DXの基礎
Masanori Saito
Lean coffee
Lean coffee
Takeshi Arai
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
Recommandé
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
Itsuki Kuroda
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
Itsuki Kuroda
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
211101_DXの基礎
211101_DXの基礎
Masanori Saito
Lean coffee
Lean coffee
Takeshi Arai
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
Recruit Technologies
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
Arata Fujimura
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
Junji Nishihara
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
【Ltech#6 】LIFULLでのQAのあり方
【Ltech#6 】LIFULLでのQAのあり方
LIFULL Co., Ltd.
実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)
Masanori Kado
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
Shigeki Morizane
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
Itsuki Kuroda
スタートアップの 3 分ピッチテンプレート
スタートアップの 3 分ピッチテンプレート
Takaaki Umada
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
Itsuki Kuroda
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
Takaaki Umada
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
Itsuki Kuroda
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
圭 進藤
シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態
atsushi nagata
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
コミュニケーション戦略を前提にしたOutlookやTeams活用
コミュニケーション戦略を前提にしたOutlookやTeams活用
Daiyu Hatakeyama
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
To be sn agile enterprise
To be sn agile enterprise
Rakuten Group, Inc.
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
智治 長沢
Contenu connexe
Tendances
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
Recruit Technologies
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
Arata Fujimura
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
Junji Nishihara
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
【Ltech#6 】LIFULLでのQAのあり方
【Ltech#6 】LIFULLでのQAのあり方
LIFULL Co., Ltd.
実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)
Masanori Kado
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
Shigeki Morizane
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
Itsuki Kuroda
スタートアップの 3 分ピッチテンプレート
スタートアップの 3 分ピッチテンプレート
Takaaki Umada
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
Itsuki Kuroda
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
Takaaki Umada
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
Itsuki Kuroda
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
圭 進藤
シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態
atsushi nagata
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
コミュニケーション戦略を前提にしたOutlookやTeams活用
コミュニケーション戦略を前提にしたOutlookやTeams活用
Daiyu Hatakeyama
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
Tendances
(20)
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
"Kong Summit, Japan 2022" カスタマーセッション:持続可能な店舗運営を支えるリテールテックとKongの利活用について
はじめてのアジャイル
はじめてのアジャイル
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
【Ltech#6 】LIFULLでのQAのあり方
【Ltech#6 】LIFULLでのQAのあり方
実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
スタートアップの 3 分ピッチテンプレート
スタートアップの 3 分ピッチテンプレート
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
とあるスタートアップの評価指標(メトリクス)
とあるスタートアップの評価指標(メトリクス)
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態
ユーザーストーリーの分割
ユーザーストーリーの分割
コミュニケーション戦略を前提にしたOutlookやTeams活用
コミュニケーション戦略を前提にしたOutlookやTeams活用
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Similaire à 大規模スクラムの失敗から学んだこと #AgileJapan2015
To be sn agile enterprise
To be sn agile enterprise
Rakuten Group, Inc.
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
智治 長沢
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
満徳 関
スクラムのご紹介セミナー_アジェンダ
スクラムのご紹介セミナー_アジェンダ
YUJI NISHIMURA
スクラムのご紹介セミナー_アジェンダ
スクラムのご紹介セミナー_アジェンダ
YUJI NISHIMURA
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Takao Kimura
Scrum"再"入門
Scrum"再"入門
You&I
スケジュール遅延が当たり前な状況を少し良くしたいチームがその未来のためにScrumに”再”挑戦した話
スケジュール遅延が当たり前な状況を少し良くしたいチームがその未来のためにScrumに”再”挑戦した話
Rakuten Commerce Tech (Rakuten Group, Inc.)
価値ある製品を生み出すためのアジャイル実践ポイント
価値ある製品を生み出すためのアジャイル実践ポイント
Naoya Maekawa
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
Takenori Takaki
6製品1サービスの開発にPortfolio for JIRAを使ってみた
6製品1サービスの開発にPortfolio for JIRAを使ってみた
Hiroshi Ohnuki
アジャイル開発&TFS導入
アジャイル開発&TFS導入
You&I
セールスフォース的開発メソッドのススメ 須山洋輔
セールスフォース的開発メソッドのススメ 須山洋輔
TerraSky
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
Yuichiro Yamamoto
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
Kazutaka Sankai
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
智治 長沢
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
axsh co., LTD.
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Takao Kimura
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
Yusuke Suzuki
Similaire à 大規模スクラムの失敗から学んだこと #AgileJapan2015
(20)
To be sn agile enterprise
To be sn agile enterprise
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
スクラムのご紹介セミナー_アジェンダ
スクラムのご紹介セミナー_アジェンダ
スクラムのご紹介セミナー_アジェンダ
スクラムのご紹介セミナー_アジェンダ
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Scrum"再"入門
Scrum"再"入門
スケジュール遅延が当たり前な状況を少し良くしたいチームがその未来のためにScrumに”再”挑戦した話
スケジュール遅延が当たり前な状況を少し良くしたいチームがその未来のためにScrumに”再”挑戦した話
価値ある製品を生み出すためのアジャイル実践ポイント
価値ある製品を生み出すためのアジャイル実践ポイント
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
6製品1サービスの開発にPortfolio for JIRAを使ってみた
6製品1サービスの開発にPortfolio for JIRAを使ってみた
アジャイル開発&TFS導入
アジャイル開発&TFS導入
セールスフォース的開発メソッドのススメ 須山洋輔
セールスフォース的開発メソッドのススメ 須山洋輔
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
【#osh2014】これからのつながる開発環境とその秘訣 (仮)
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
大規模スクラムの失敗から学んだこと #AgileJapan2015
1.
大規模スクラムの失敗から学んだこと ∼急成長をとげるAirレジの組織拡大の取り組み∼ ㈱リクルートライフスタイル 塚越 啓介・佐橘
一旗
2.
自己紹介 • Itsuki Sakitsu
- エンジニア • 初期からのスクラム導入推進役 • Keisuke Tsukagoshi - エンジニア • スクラム支援、コーチング
3.
大規模スクラムって?
4.
普通のスクラム Product Owner Scrum Master Team Product
5.
大規模スクラム? Product Owner Scrum Master Team Product
6.
大規模スクラム? Product Owner Scrum Master Team Product
7.
大規模スクラム PO Lead Company Board
UX Specialist Portofolio Architect PO Lead Architect Releaser Architect Releaser Product Product Scrum Support
8.
本日お伝えしたいこと スケールアップしても スクラムの原理原則はかわらない スクラムの導入に最も重要なのは 「Why」「検証と適応と透明性」
9.
アジェンダ 1. Airレジとは? 2. なぜスクラムに取り組んだのか? 3.
大規模アジャイル開発、検証と適応からの学び 4. 今後、挑戦したい課題 5. まとめ
10.
1. Airレジとは? About AirREGI
11.
無料で簡単に使えるPOSレジアプリ
12.
13.
Aサービ ス Bサービ ス
14.
15.
2.なぜスクラムに取り組んだ のか? Why SCRUM?
16.
我々は何故、 • スクラムを行うのか? • 未経験の事業領域、試行錯誤の必要性 •
スケールする必要があったのか? • 相互に連携する複数のサービスを、全体整合性を 保ちつつも並行して立ち上げたい
17.
ぶっちゃけた話
18.
当たり前を当たり前に やりたいから
19.
当時の状況 要件決まってないから 開発できない
20.
当時の状況 要件決まってないから 開発できない これ、全然イケテナイ 言われたから作るか
21.
当時の状況 そんな話きいてないけど
22.
当時の状況 こんなスケジュール無理 にきまってるじゃん
23.
当時の状況 こんなスケジュール無理 にきまってるじゃん
24.
目指したもの • 率直な意見を言い合える文化 • チームが協力してものづくりを行える文化 •
常に成長を続けられる文化
25.
なぜスクラムをはじめたのか 当たり前を当たり前に やりたいから
26.
3. 大規模アジャイル開発、検 証と適応からの学び How we
learned, tried and adopted
27.
組織拡大の歴史 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大
28.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase1.
Scrum試験導入
29.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase2.
Scrum全面適応
30.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase3.
組織の拡大
31.
2.1. WFからスクラムへ How we
started SCRUM
32.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase1.
Scrum試験導入
33.
はじまり • 「今のプロセスを改善したい」 • Scrum
Boot Campを購入 • まずはカタチから
34.
WF開発 Product
35.
WF開発 + スクラムチーム ProductProduct
36.
当初導入できたこと • アーティファクト • プロダクトバックログ、スプリントバック ログ(KANBAN) •
セレモニー • 計画ミーティング、朝会、振り返り、スプ リントレビュー
37.
やってみた結果 • 開発タスクが漏れなくなった • 他メンバーが何をしているか見えるようになった •
案件や進め方に対して意見が出せるように
38.
スクラムよかった! • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はでる
39.
スゲーうまくいった
40.
スクラムうまくいったから 他のチームも 全部スクラムでやろう!
41.
2.2. スクラムの全面適応 How we
adapted
42.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase2.
Scrum全面適応
43.
スクラム+WFチーム Product
44.
全面スクラム化 Product Product
45.
何が起こったか
46.
SMってタスクの管理す る人でしょ! スクラムだから納期は コミットしないでしょ? ユーザーストーリー作っ たからあとよろしく!
47.
あれ?
48.
なんか違う
49.
スクラムよかった! • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はある
50.
正しくは
51.
スクラムよかった • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はある ただし、チームメンバーの多く が能動的かつ課題感を共有して いる場合に限る
52.
落とし穴 • トップダウン導入による、やらされスクラム • 形だけの導入によるスクラムの誤解の顕在化 •
不安感からくる手段の目的化
53.
Whyの有無で 効果は全然ちがう
54.
形だけの導入による成果と障害 • 成果 • プロセス自体の定期的改 善
(振り返り) • コミュニケーションの改 善 (チーム、KANBAN) • スコープをきることでリ リースサイクルを向上 (プロダクトバックログ) • 障害物 • スクラムのバズワード化 • POのコミット力低下 • メンバーの自発性がなか なか育たない
55.
事例1.スクラムのバズワード化 • 「スクラム」だから○○やらないとダメ • 「スクラム」をやることが目的になってしまう 原因 Whyの欠如 不安からプロセスに縛られる 対策 Whyを考えるワークショップの実施 相互に聞ける環境づくり /やってみせる 成果 プロセスではなくゴールを 意識できるようになった
56.
事例2.POのコミット力低下 • 案件の投げっぱなし、情報共有不足 • POとチームの関係性悪化 原因 お互いの状況が見えていない わからないことをすぐに聞けない 対策
先ずは物理的な距離を近づける 成果 すぐに聞ける状況と、不満を口にしにくい環境
57.
事例3.メンバーの自発性がなかな か育たない • SMがタスクを作成、アサイン • 振り返りがお通夜 原因
SMが自分で仕切ってしまう 対策 自己評価/他者評価のフィードバック実施 成果 自分が無意識でやっていたことへの気づき
58.
取り組みまとめ • 組織的にスクラムに対する理解を深める • ワークショップ、コーチング、相互相談 •
席替え実施 • POと開発チームを近くに • 自己評価/他者評価 • SMチェックシート実施
59.
2.2. スクラムから大規模ア ジャイル開発へ How we
scaled
60.
大規模アジャイル開発
61.
全面スクラム化 Product
62.
POの意思を統一する人 PO Lead Product
63.
アーキテクト整合性 PO Lead Product Architect
64.
リリース案件、リリース前QA PO Lead Architect Releaser Product
65.
プロダクトが増える PO Lead PO
Lead Architect Releaser Architect Releaser Product Product
66.
全体の意思を統一する人 PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product
67.
全体のUI/UXを統一する人 PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist
68.
全体のアーキテクト PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect
69.
全体のスクラム支援 PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
70.
PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
71.
Portfolio Backlog Release Train SysQA
RTE Release Train SysQA RTE PB PB PB Company Board Architects UX Specialist Scrum Support
72.
スクラムの儀式 Sprint 計画MTG リファインメント スプリント レビュー 朝会 DemoDay SM,
PO ナレッジ共有会 開発アーキ別 共有会 Scrum of Scrum 振り返り
73.
組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入 既存体制 Product / Component 機能組織 全面 適用 WF体制 2013/11 組織拡大 Phase3.
組織の拡大
74.
我々は何故、 • スクラムを行うのか? • 未経験の事業領域、イテレーション開発の必要性 •
スケールを志すのか? • 相互に連携する複数のサービスを、全体整合性を 保ちつつも並行して立ち上げたい
75.
スクラムから大規模スクラムへ • 成果 • 開発できる案件が増えた •
ナレッジ蓄積スピードの加 速 • 障害 • 組織的課題が見えづらい • リーダーTに対する依存 • 組織にアーキテクチャが おいつかない
76.
事例1. 組織的課題が見えづらい • 全体の可視化が忘れられやすい •
各チームだけでなく、全体最適はとれてる? 原因 チームのことにフォーカスしてしまう 対策 全体像の可視化、各立場での情報共有 成果 大規模アジャイル開発体制自体の改善
77.
PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
78.
PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
79.
PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
80.
事例1. 組織的課題が見えづらい • 全体の可視化が忘れられやすい •
各チームだけでなく、全体最適はとれてる? 原因 チームのことにフォーカスしてしまう 対策 全体像の可視化、各立場での情報共有 成果 大規模アジャイル開発体制自体の改善
81.
事例2.リーダーTに対する依存 • リーダーチームの意思決定待ち • チーム間でのコミュニケーション不足 原因
PM : メンバー = リーダーT : チーム 対策 リーダーTの解散 ※サポート型のリーダーチーム 成果 各チーム間連携の向上
82.
事例3. 組織とアーキテクチャ • 技術的負債の顕在化 •
人が増えてもなかなか開発速度があがらない 原因 コンウェイの法則 組織の大きさとアークテクチャの乖離 対策 アーキテクチャの見直し プラクティス(TDD, CI/CD)の導入 成果 挑戦中 バグ発生率は低下中
83.
スケールアップにより発生した 問題 • チームで発生したことは抽象度があがって再 発する • 急成長するプロダクトにあわせて、組織だけ でなくアーキテクチャもスケールする
84.
4. 今後挑戦したい課題 Our current
impediment list
85.
事例1. 組織的課題が見えづらい • 全体の可視化が忘れられやすい •
各チームだけでなく、全体最適はとれてる? 原因 チームのことにフォーカスしてしまう 対策 全体像の可視化、各立場での情報共有 成果 大規模アジャイル開発体制自体の改善
86.
改めて、 検証と適応と透明性
87.
組織拡大と可視化の重要性 • 組織拡大 =
意思を持つ人の増加 • 可視化は「事実」を顕在化させる • 意見は受け入れづらいが、事実は受け入れ やすい • 目的が共有できていれば、課題を解決する 意思を共有できる
88.
改めて、検証と適応と透明性 プロセス、スループットの 更なる可視化
89.
プロセス、スループットの 更なる可視化 • 大規模化に伴って登場人物が増えたが、アジャ イルさの阻害要因になっていないか? • 個別のレビューも塵が積もれば山となる
90.
PO Lead Company Board PO
Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support
91.
大規模のプロセスを どう可視化するのか? 案 件 リ リ ー ス プロセス プロセスプロセスプロセス ・どれだけのプロセスを実践している? ・各プロセスにどれだけコストがかかっているのか? ・そのプロセスの意味と目的は?権限移譲出来ない? ・全体のスループットを明らかにし、更なるROI改善を
92.
5. まとめ Summary
93.
スクラムから学んだこと • Whyを理解/共有をすること • 物理的な距離を近づけること •
PMをそのままSMにしないこと (SMは我慢す ること)
94.
大規模化から学んだこと • 全体の可視化を改めて行うこと • リーダーチームもサポート型に •
組織構造にあわせたアーキテクトを作ること
95.
まとめ スケールアップしても スクラムの原理原則はかわらない スクラムの導入に最も重要なのは 「Why」「検証と適応と透明性」
96.
失敗から学んだことを お伝えしてきましたが
97.
結局やってよかった?
98.
YES!
99.
Scale Upしてよかったこと • 仲間が増える •
できることが増える • 学ぶことが増える
100.
出来る、大規模アジャイル開発 失敗から学ぶことが出来れば大丈夫! そのためのWhyと透明性
101.
出来る、大規模アジャイル開発 失敗から学ぶことが出来れば大丈夫! そのためのWhyと透明性 一つでも皆様のお役に立てるものがあれば 幸いです
102.
課題を解決する仲間 絶賛募集中! • http://www.career.recruit-lifestyle.co.jp/
Télécharger maintenant