Submit Search
Upload
認定スクラムマスター研修に行ってきました
•
30 likes
•
38,605 views
Hajime Yanagawa
Follow
認定スクラムマスター研修(CSM)参加した結果として、社内発表した資料
Read less
Read more
Software
Report
Share
Report
Share
1 of 99
Download now
Download to read offline
Recommended
CSPO、CSM研修に参加して
CSPO、CSM研修に参加して
Arata Fujimura
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
増田 亨
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
NTT DATA Technology & Innovation
ワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキル
Tsuyoshi Ushio
Recommended
CSPO、CSM研修に参加して
CSPO、CSM研修に参加して
Arata Fujimura
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
増田 亨
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
NTT DATA Technology & Innovation
ワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキル
Tsuyoshi Ushio
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性
Shigeru Tatsuta
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
私にとってのテスト
私にとってのテスト
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Masashi Umezawa
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
智治 長沢
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
skipping classes
More Related Content
What's hot
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性
Shigeru Tatsuta
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
私にとってのテスト
私にとってのテスト
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Masashi Umezawa
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
What's hot
(20)
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
私にとってのテスト
私にとってのテスト
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Viewers also liked
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
智治 長沢
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
skipping classes
てーげーで学ぶScrum
てーげーで学ぶScrum
Takaesu Makoto
スクラムやったらこうなった #AgileJapanOsaka
スクラムやったらこうなった #AgileJapanOsaka
真一 牛島
MyInceptionDeck
MyInceptionDeck
Yoh Nakamura
Fearless Journey
Fearless Journey
Masanori Kado
Agile Samurai インセプションデッキ
Agile Samurai インセプションデッキ
Masahiro Nishimi
[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望 #postudy
[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望 #postudy
満徳 関
Agile Software Development for Newbies
Agile Software Development for Newbies
Naoto Nishimura
カンバンゲーム カード(全種類)
カンバンゲーム カード(全種類)
Yasui Tsutomu
ざんねんスクラム座談会
ざんねんスクラム座談会
Takaesu Makoto
異文化コミュニケーション体感ゲーム「バーンガ」
異文化コミュニケーション体感ゲーム「バーンガ」
Jun Chiba
個人と組織からもう一度考えるプロダクトマネジャー - [ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの...
個人と組織からもう一度考えるプロダクトマネジャー - [ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの...
POStudy
Head First Inception Deck
Head First Inception Deck
Naoto Nishimura
カンバンゲーム ルール説明
カンバンゲーム ルール説明
Yasui Tsutomu
【Unity道場スペシャル 2017幕張】続 あそびのデザイン講座
【Unity道場スペシャル 2017幕張】続 あそびのデザイン講座
Unity Technologies Japan K.K.
Summary of Scrum Guide
Summary of Scrum Guide
Naoto Nishimura
ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例
ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例
Ken Nishimura
「正しいアジャイル」でなくてもいい
「正しいアジャイル」でなくてもいい
Hiroshi Ogino
第17回すくすくスクラム 振り返りの基礎はこれだ!
第17回すくすくスクラム 振り返りの基礎はこれだ!
Eiichi Hayashi
Viewers also liked
(20)
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
てーげーで学ぶScrum
てーげーで学ぶScrum
スクラムやったらこうなった #AgileJapanOsaka
スクラムやったらこうなった #AgileJapanOsaka
MyInceptionDeck
MyInceptionDeck
Fearless Journey
Fearless Journey
Agile Samurai インセプションデッキ
Agile Samurai インセプションデッキ
[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望 #postudy
[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望 #postudy
Agile Software Development for Newbies
Agile Software Development for Newbies
カンバンゲーム カード(全種類)
カンバンゲーム カード(全種類)
ざんねんスクラム座談会
ざんねんスクラム座談会
異文化コミュニケーション体感ゲーム「バーンガ」
異文化コミュニケーション体感ゲーム「バーンガ」
個人と組織からもう一度考えるプロダクトマネジャー - [ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの...
個人と組織からもう一度考えるプロダクトマネジャー - [ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの...
Head First Inception Deck
Head First Inception Deck
カンバンゲーム ルール説明
カンバンゲーム ルール説明
【Unity道場スペシャル 2017幕張】続 あそびのデザイン講座
【Unity道場スペシャル 2017幕張】続 あそびのデザイン講座
Summary of Scrum Guide
Summary of Scrum Guide
ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例
ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例
「正しいアジャイル」でなくてもいい
「正しいアジャイル」でなくてもいい
第17回すくすくスクラム 振り返りの基礎はこれだ!
第17回すくすくスクラム 振り返りの基礎はこれだ!
Similar to 認定スクラムマスター研修に行ってきました
Scrum"再"入門
Scrum"再"入門
You&I
[Agile Japan 2017 NRIサテライト]SCRUMをベースにしたNRIでの適用事例
[Agile Japan 2017 NRIサテライト]SCRUMをベースにしたNRIでの適用事例
Shigeki Morizane
スクラム再入門(仮) Developer Summit 関西 2013
スクラム再入門(仮) Developer Summit 関西 2013
Kiro Harada
20121017_アプリ制作勉強会@GMO Yours
20121017_アプリ制作勉強会@GMO Yours
Yozo SATO
Scrum
Scrum
Kakigi Katuyuki
Scrumワークショップ
Scrumワークショップ
You&I
Fearless Change RSG Japan English.pdf
Fearless Change RSG Japan English.pdf
Daniel Teng
大規模スクラムの失敗から学んだこと #AgileJapan2015
大規模スクラムの失敗から学んだこと #AgileJapan2015
Itsuki Sakitsu
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
Yusuke Suzuki
ユーザーストーリーワークショップ実践編
ユーザーストーリーワークショップ実践編
You&I
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
Scrum始めました
Scrum始めました
minamo
やさしいScrum #1
やさしいScrum #1
ito_ma
[RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~
[RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~
Shigeki Morizane
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Takao Kimura
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
You&I
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
Arata Fujimura
Scrum:適用領域の広がりとscrum for hw概説
Scrum:適用領域の広がりとscrum for hw概説
Kazutaka Sankai
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
Takenori Takaki
Similar to 認定スクラムマスター研修に行ってきました
(20)
Scrum"再"入門
Scrum"再"入門
[Agile Japan 2017 NRIサテライト]SCRUMをベースにしたNRIでの適用事例
[Agile Japan 2017 NRIサテライト]SCRUMをベースにしたNRIでの適用事例
スクラム再入門(仮) Developer Summit 関西 2013
スクラム再入門(仮) Developer Summit 関西 2013
20121017_アプリ制作勉強会@GMO Yours
20121017_アプリ制作勉強会@GMO Yours
Scrum
Scrum
Scrumワークショップ
Scrumワークショップ
Fearless Change RSG Japan English.pdf
Fearless Change RSG Japan English.pdf
大規模スクラムの失敗から学んだこと #AgileJapan2015
大規模スクラムの失敗から学んだこと #AgileJapan2015
クラウドを超えた先の企業システム像 20091008 JJUG CCC
クラウドを超えた先の企業システム像 20091008 JJUG CCC
ユーザーストーリーワークショップ実践編
ユーザーストーリーワークショップ実践編
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Scrum始めました
Scrum始めました
やさしいScrum #1
やさしいScrum #1
[RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~
[RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
Scrum:適用領域の広がりとscrum for hw概説
Scrum:適用領域の広がりとscrum for hw概説
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
認定スクラムマスター研修に行ってきました
1.
認定スクラムマスター研修 京都 に行ってきました
1 / 99
2.
認定スクラムマスター研修 (CSM研修)
に参加してきました。 2 / 99
3.
個人的に、印象深かった トピックをお話します。
3 / 99
4.
本日の、私の目標 スクラムに
興味を持ってもらえること です 細かい説明はしませんので、 Scrum自体の概要 をしっかり知りたいという方は、あとで資料をご紹介します。 4 / 99
5.
研修はどんな感じだったか 5 /
99
6.
研修はどんな感じだったか 簡単にご紹介 6
/ 99
7.
日時 : 2014年
8月 7日 (木) - 8月 8日 (金) 場所 : 京都烏丸コンベンションホール 京都烏丸コンベンションホール Webページ 名前からの先入観で、すごく大きいところを想像していたのですが、 以外にコンパクトでした。 (駅員さんに訊いても知りませんでした) 先入観で決めつけるのはいけないという教訓になりました。 参加者 半分が関東の方、半分が関西の方 7 / 99
8.
トレーナー : 江端
一将 さん 日本人で唯一のアジャイルトレーナー かつて大規模プロジェクトのプロダクトオーナーを 経験された プロダクトオーナー ・・・ Scrumの役割の一つ ROI最大化するために、プロダクト方向性を決める人 チーム ・・・ Scrumの役割の一つ 開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい る スクラムマスター ・・・ Scrumの役割の一つ 開発が Scrum と呼べる状態にする人。 8 / 99
9.
「体験する」「考える」ことを重視してい る内容でした 内容の例
本日の参加者で Scrum をどのぐらい知っているかについて、順番を付けてください 研修中のルールを皆さんで決めてください ゲームやロールプレイ 現場で起こそうな雰囲気 色々『気づき』があり、刺激的でした (私個人の感想です) 9 / 99
10.
Scrum をやる機会がなかったとしても 新鮮な考え方が
得られて有意義な研修だったと感じました。 10 / 99
11.
研修はどんな感じだったか 11 /
99
12.
おわり 12 /
99
13.
本題に移ります 13 /
99
14.
印象深かったポイント 14 /
99
15.
Scrum は何を解決するためのフレ ームワークか?
15 / 99
16.
Scrum は何を解決するためのフレ ームワークか?
失敗を減らしたり、 開発の効率を上げたり、 素早く開発できたり、 簡単に開発できたり、 品質を向上が期待できたり、 16 / 99
17.
そういうことを 解決する フレームワークでは
ありません 誤解していました。。。 17 / 99
18.
Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 18 / 99
19.
Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) 19 / 99
20.
Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) * 透明性 -- Transparency * 検証 -- Inspect * 適合 (検証に基づいた適合) -- Adapt 20 / 99
21.
Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) * 透明性 -- Transparency * 検証 -- Inspect * 適合 (検証に基づいた適合) -- Adapt * Scrum Roles -- 役割 * Product Owner -- プロダクトオーナー * ScrumMaster -- スクラムマスター * The Team -- チーム * Artifact アーチファクト (参考:日本語訳)人工物、工芸品^、芸術品 * Product Backlog -- プロダクトバックログ * Sprint Backlog -- スプリントバックログ * Impediment List -- インピディメントリスト * Ceremonies -- セレモニー * Sprint Planning -- スプリントプランニング * Daily Scrum -- デイリースクラム * Product Backlog Refinement -- プロダクトバックログリファインメント * Sprint Review -- スプリントレビュー * Sprint retrospective -- スプリントレトロスペクション * Sprint -- スプリント * Stop -- 製品開発と途中でやめる * Acceptance Criteria -- 受け入れ基準 * Done -- 製品が完了する * Potentially shippable product increment -- 出荷可能な製品をリリースする 21 / 99
22.
「透明性 -- Transparency」
22 / 99
23.
三本柱の中の「透明性 -- Transparency」
を 最も重要視しています 「say "It's done."」 を撲滅する 「もう、ほとんどできてます。」 「90%できた (?) 」 っていうのはなくす ガントチャートに、こういう状況、よく出てきませんか? 23 / 99
24.
Ken Schwaber氏が Scrum
について象徴的な説明をして いる動画を見せてもらいました。 24 / 99
25.
Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて くれる 25 / 99
26.
Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か 26 / 99
27.
Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か Scrum の特徴は 「軽量」、 「理解が容易」、、、 27 / 99
28.
Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か Scrum の特徴は 「軽量」、 「理解が容易」、、、 「 習得は非常に困難」 28 / 99
29.
Scrum は何を解決するためのフレ ームワークか?
29 / 99
30.
Scrum は何を解決するためのフレ ームワークか?
現状をあぶりだすフレームワーク 問題をあぶりだすフレームワーク 30 / 99
31.
Scrum は何を解決するためのフレ ームワークか?
素晴らしいチームはより素晴らしく、 そうでないチームはそれなりに、 (Fフイルム風。 知っている人は、かなりご年配。 文責:柳川。) 31 / 99
32.
Scrum は何を解決するためのフレ ームワークか?
良いところも、悪いところも、明らかにし て 状況に適応していくことで チームの力を、発揮させようとします 32 / 99
33.
>> 33 /
99
34.
自律的なチーム 34 /
99
35.
自律的なチーム チームがチームを管理する スクラムマスターは管理者ではない
チーム ・・・ Scrumの役割の一つ 開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい る スクラムマスター ・・・ Scrumの役割の一つ 開発が Scrum と呼べる状態にする人。 プロダクトオーナー ・・・ Scrumの役割の一つ ROI最大化するために、プロダクト方向性を決める人 35 / 99
36.
自律的なチーム チームで方針を相談する チームの進捗は、チームが管理する
チームの方針に沿い、 個人が判断して作業する。 (0.1秒以内で判断して) 個人は、チームに結果をフィードバックする 36 / 99
37.
自律的なチーム スクラムマスターは 管理したり、直接手伝ったりしてはいけない
チームが困っているときに助言する チームの邪魔をしそうな「人」「もの」「イベント」「人と人とのトラブル」などの あらゆる障害を取り除く 37 / 99
38.
自律的なチーム チームがチームを管理することにより チームは成長していきます。
チームのメンバーも成長していきます。 38 / 99
39.
自律的なチーム チームがチームを管理することにより チームは成長していきます。
チームのメンバーも成長していきます。 なんか、いいと思いませんか? 39 / 99
40.
>> 40 /
99
41.
ソフトウエア開発に抽象的な解 決方法はない 41
/ 99
42.
ソフトウエア開発に抽象的な解 決方法はない 実際の経験
と 既知に基づく判断によって知識が 獲得できる 経験的プロセス制御の理論(経験主義) (注: 哲学、心理学の文脈ででてくる「経験主義」とは異なる模様) 42 / 99
43.
具体的な例 (既知に基づく判断) 人間は将来を予測するのが下手
人間は絶対値の見積もりが下手 . では、上から順に。。。 43 / 99
44.
人間は将来を予測するのが下手 より未来になればなるほど、予測があたらない 大事だとことも、大事でなくなる
44 / 99
45.
人間は将来を予測するのが下手 こんな感じです。たぶん。。 ↑予測はずれ率
│ | │ / │ | │ / │ / │ _/ │ __/ │ ___/ │ _____/ │ ______/ │ _______/ │ ________/ │ _________/ │ __________/ │/ 未来 +----------------------------------------------------------> 45 / 99
46.
人間は将来を予測するのが下手 このため、 ==>
次のスプリントしか詳細に見積もりしない 反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う スプリント Scrumでは、1週間、や、2週間、など、期間を区切って開発する。 スプリントはその、1つの期間のこと。 46 / 99
47.
人間は絶対値の見積もりが下手 47 /
99
48.
人間は絶対値の見積もりが下手 どちらが当てやすいか? (誤差が小さいか?)
このペットボトルの 黒い部分は何セン チですか このペットボトルの黒い 部分は白い部分の何 倍ですか この紙は、何平方 センチですか この紙は、あの紙の何 倍(何分の何)ですか 48 / 99
49.
人間は絶対値の見積もりが下手 このため、 ==>
相対的に見積る 相対的に見積もったほうが、誤差が小さい 見積もりの基準になる、項目を決めて、 「何倍か?」という風に見積もる。 「プランニングポーカー」という手法が研修で紹介されました (研修でカードももらいました。) 紹介しているサイトの一例(検索するといっぱい引っかかります) プランニングポーカー簡単ガイド作りました -- http://d.hatena.ne.jp/wayaguchi/20120218/1329524230 49 / 99
50.
>> 50 /
99
51.
Scrumに適するプロジェクトは 51 /
99
52.
Scrumに適するプロジェクトは 要件が不明確 ↑
└+ │ | カオス │ └+ │ | │ └---+ │--┐ | │ +---┐ └+----------------+ │ │ | │ 複雑 +┐ └--------- │ +┐ │ │ 複合的に複雑 │ ┐ │ │ │ │ │--┐ │ │ +---┐ │ │ +--┐----------------┐ │ +-┐ ┐ │ 単純 │ 複雑 │ │ +┐ +┐ │ │ │ +----------------------------------------------------------> 技術が難しい・新しい52 / 99
53.
Scrumに適するプロジェクトは 適するのは、単純なプロジェクト以外 単純なプロジェクトは不得意
実現する内容が単純明快 やりたいこと(要件)が明らか やりたいこと(要件)が変更されない 実現方法が分かっている。もしくは、決まっていて、失敗する可能性が小さい。 単純なプロジェクトであればあるほとは、「ウォータフォール」&「一括契約」 がおすすめです。(なぜなら、変更されないことが「ウォータフォールの前提」だから) 53 / 99
54.
Scrumに適するプロジェクトは 採用例 ユーザー企業の内製プロジェクトに、採用例が多
い模様。 内製プロダクトの場合、公表するメリットがなく公表されないことが多いとのこと。 メディアには露出しにくい模様。 54 / 99
55.
Scrumに適するプロジェクトは 内製以外では工数精算 一括請負契約は不得意
55 / 99
56.
感想 56 /
99
57.
感想 ルールに厳格だけど、自由にルールを決められる 役割ごとの責任に厳しい
57 / 99
58.
ルールに厳格だけど、自由にル ールを決められる Scrum自体のルールは、全部守る必要あり
Scrum のキーワード 19個 ... (2014年8月現在) 一部だけ適用することは可能だが、それは、Scrum ではない別の何か Scrumの要素を一部だけ適用して「Scrumうまくいかない」というのは的外れ 一方、チームが独自で決めるルールは。。。 制約少ない。柔軟 開発コストを下げるためなら、あらゆる発送を駆使して、何を試みてもよい 「チームが決めた」ことは守らないといけない 58 / 99
59.
役割ごとの責任に厳しい 59 /
99
60.
役割ごとの責任に厳しい 責任を果たしていない場合は追及する 60
/ 99
61.
役割ごとの責任に厳しい 責任を果たしていない場合は追及する 責任を奪ってはならない
では、順に。。。 61 / 99
62.
役割ごとの責任に厳しい プロダクトオーナーも、スクラムマスターも、管理者では ない。
チームとは 対等。 責任範囲を越境してはいけない チームは「コストを最小にする」代案 があれば、プロ ダクトマスターが選択できるようにしなくてはならない。 プロダクトオーナーはビジョンを示さなければいけない。 スクラムマスターは、チームが開発に専念できるようにし なければいけない。 プロダクトオーナーは 優先順位 を決定しなければいけ ない。(優先度ではない) 「チーム」に指示したり、命令したり、 高圧的に選択を強 いたりして、委縮させるのはもっともダメ など。。。 62 / 99
63.
役割ごとの責任に厳しい ゴチャゴチャし過ぎました。 すいません
63 / 99
64.
>> 64 /
99
65.
最後に 65 /
99
66.
私が考える SIer の
Agile や Scrumに対するお奨め戦 略は 66 / 99
67.
私が考える SIer の
Agile や Scrumに対するお奨め戦 略は 『Scrum なんて知らない』ふりをする 67 / 99
68.
私が考える SIer の
Agile や Scrumに対するお奨め戦 略は 『Scrum なんて知らない』ふりをする 『Scrum が優秀』と思った顧客は内製開発してしまう 一括契約で Scrum を採用すのはイバラの道 68 / 99
69.
でも、 Agile とか
Scrum とか言うキーワードで仕事の お話がある場合は 69 / 99
70.
でも、 Agile とか
Scrum とか言うキーワードで仕事の お話がある場合は せっかくですから 開発しましょう (あるいは、する方向で前向きに) 70 / 99
71.
注意点 契約形態は、工数型で お客様いう
Agile と Scrum の意味を確認しておく 本来の意味かもしれないし ユニークな発想によるものかもしれません。 どんな意図であったとしても、少なくとも、心構えができます。 71 / 99
72.
社内開発に ぜひ一度、 72
/ 99
73.
社内開発に ぜひ一度、 採用おねがいします
73 / 99
74.
社内開発に 自律的なチーム
『人、と、組織、を成長させる』 魅力的じゃないですか? 74 / 99
75.
社内開発に Scrum を使いこなすのは、容易ではないかもしれませんが、
有効なフレームワークだと思います。 75 / 99
76.
社内開発に Scrum を使いこなすのは、容易ではないかもしれませんが、
有効なフレームワークだと思います。 76 / 99
77.
おわり 77 /
99
78.
もっとスクラムについて知りたい かたは スクラムガイド
http://www.scrumguides.org/download.html Scrum Primer(日本語版) http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf 78 / 99
79.
おまけ 79 /
99
80.
へー、って思ったこと 80 /
99
81.
その1 81 /
99
82.
Scrum のほうが Agile
より歴史が古 い Scrumは、 1993年 アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development) 2001年 17名の共通認識を宣言として発表。 82 / 99
83.
その2 83 /
99
84.
Agile アジャイルは状態 84
/ 99
85.
Agile アジャイルは状態 アジャイルは状態を表す言葉
Be Agile. Not Do Agile. 85 / 99
86.
Agile という単語を、間違って使っ た会話の例
開発 Aさん このプロジェクトは 「アジャイルプロジェクトマネジメン ト」します。 顧客担当 Bさん そうですね。 「アジャイル開発」のほうがリスクが低そうですしね。 顧客課長 Cさん A さん、しっかり チームを管理お願いしますね 86 / 99
87.
Agile アジャイルは状態 アジャイルプロジェクトマネジメント
87 / 99
88.
Agile アジャイルは状態 アジャイルプロジェクトマネジメント
というものはありません。 『出版時に、キャッチコピーとして、使っちゃったんですが、。。。 失敗でした 』 ほんとは、「 Bussiness Fucilitation 」って呼ぼうと思ったんですが Agile のほうが、「キ ャッチ―でしょう。」って出版社がいうので。。。 とのこと 88 / 99
89.
なので 89 /
99
90.
Agile アジャイルは状態 アジャイル開発する
90 / 99
91.
Agile アジャイルは状態 アジャイル開発する
できません。 Be Agile. Not Do Agile. Agile は状態なので「する」ことはできません 「Scrumで開発したら、アジャイルな状態になれた。」 という感じが、意図する意味合い 91 / 99
92.
Agile アジャイルは状態 『Agile
という単語は、「青春」という単語 と同じような使い方をするとイメージす るとよい』 (トレーナーの江端さん 談) 92 / 99
93.
「Agile」 と 「青春」の用例
あの時は、 Agile だったなー あの時は、青春だったなー こんな風に、Agile という単語は 青春 という単語使い方が似ています。 93 / 99
94.
「Agile」 と 「青春」の用例
Agile する 青春する するものじゃないので、両方変な感じになります。。。 「青春する」はコントのセリフならギリギリセーフです。。。 94 / 99
95.
おまけ (その3) 95
/ 99
96.
アジャイルソフトウェア開発宣言 で一番大事なこと 参考:アジャイルソフトウェア開発宣言
の序文 「4つの価値」 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 96 / 99
97.
アジャイルソフトウェア開発宣言 で一番大事なこと 参考:アジャイルソフトウェア開発宣言
の序文 一番、重要なのは「4つの価値」だと思 ってましたが、 もっと大事なものがありました。 97 / 99
98.
アジャイルソフトウェア開発宣言 で一番大事なこと 最初に書かれている序文が重要
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて。。。 最も重要なこと 始めること 助けること 98 / 99
99.
おまけ おわり 99
/ 99
Download now