Enviar pesquisa
Carregar
はじめてのアジャイル
•
4 gostaram
•
2,238 visualizações
Takao Kimura
Seguir
Negócios
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 64
Recomendados
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
うそのアジャイル、まことのアジャイル 公開用
うそのアジャイル、まことのアジャイル 公開用
ESM SEC
リーンスタートアップ、アジャイル開発導入事例
リーンスタートアップ、アジャイル開発導入事例
Arata Fujimura
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
Recomendados
はじめてのアジャイル
はじめてのアジャイル
Yoshihito Kuranuki
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
うそのアジャイル、まことのアジャイル 公開用
うそのアジャイル、まことのアジャイル 公開用
ESM SEC
リーンスタートアップ、アジャイル開発導入事例
リーンスタートアップ、アジャイル開発導入事例
Arata Fujimura
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
スクラム開発について
スクラム開発について
Akio Terayama
はじめてのScrum
はじめてのScrum
Kenji Morita
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
リーンソフトウェア開発とは
リーンソフトウェア開発とは
StudyTech
アジャイル入門
アジャイル入門
Kenji Morita
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
満徳 関
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
Hiroyuki Ito
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
Takafumi Ikeda
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました
Hajime Yanagawa
僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!
Yasui Tsutomu
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
Agile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
現場の見える化で、チーム力を向上させる
現場の見える化で、チーム力を向上させる
ESM SEC
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
Makoto Iguchi
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
Dai FUJIHARA
Agile Software Development for Newbies
Agile Software Development for Newbies
Naoto Nishimura
はじめてのスクラム
はじめてのスクラム
Kaoru NAKAMURA
はじめてのアジャイル
はじめてのアジャイル
Rakuten Group, Inc.
Mais conteúdo relacionado
Mais procurados
スクラム開発について
スクラム開発について
Akio Terayama
はじめてのScrum
はじめてのScrum
Kenji Morita
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
リーンソフトウェア開発とは
リーンソフトウェア開発とは
StudyTech
アジャイル入門
アジャイル入門
Kenji Morita
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
満徳 関
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
Hiroyuki Ito
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
Takafumi Ikeda
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました
Hajime Yanagawa
僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!
Yasui Tsutomu
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
Agile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
現場の見える化で、チーム力を向上させる
現場の見える化で、チーム力を向上させる
ESM SEC
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
Makoto Iguchi
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
Dai FUJIHARA
Agile Software Development for Newbies
Agile Software Development for Newbies
Naoto Nishimura
Mais procurados
(20)
スクラム開発について
スクラム開発について
はじめてのScrum
はじめてのScrum
リーン開発の本質 公開用
リーン開発の本質 公開用
リーンソフトウェア開発とは
リーンソフトウェア開発とは
アジャイル入門
アジャイル入門
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
チーム開発を支えるプロセス再入門~アジャイル開発とスクラム~ - TFSUG
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
メトリクスによる「見える化」のススメ: エッセンシャル・リーン
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました
僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Agile2010とは何だったのか
Agile2010とは何だったのか
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
現場の見える化で、チーム力を向上させる
現場の見える化で、チーム力を向上させる
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
Agile Software Development for Newbies
Agile Software Development for Newbies
Destaque
はじめてのスクラム
はじめてのスクラム
Kaoru NAKAMURA
はじめてのアジャイル
はじめてのアジャイル
Rakuten Group, Inc.
コーディングスタイル入門~人に伝えるプログラミング~
コーディングスタイル入門~人に伝えるプログラミング~
Hideki MACHIDA
俺の エクストリームプログラミング入門 (GuildWorks様向け)
俺の エクストリームプログラミング入門 (GuildWorks様向け)
Fumihiko Kinoshita
覚えておきたいプログラミング作法
覚えておきたいプログラミング作法
Junya Shimazu
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
Shigenori Sagawa
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Shigenori Sagawa
スクラム再入門
スクラム再入門
Minoru Yokomichi
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
Kenji Urushima
Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」
Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」
Fujio Kojima
良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
Shunji Konishi
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
Agile in 30mins
Agile in 30mins
Shintaro Kakutani
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
Fumihiko Kinoshita
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
Moriharu Ohzu
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
20141105 俺のコードレビュー(lightning talk) #devraku
20141105 俺のコードレビュー(lightning talk) #devraku
Takao Oyobe
20141105 俺のコードレビュー(opening) #devraku
20141105 俺のコードレビュー(opening) #devraku
Takao Oyobe
振り返ればカンバンがある ~チームとカンバンとProduct Ownership~
振り返ればカンバンがある ~チームとカンバンとProduct Ownership~
Takao Oyobe
Destaque
(20)
はじめてのスクラム
はじめてのスクラム
はじめてのアジャイル
はじめてのアジャイル
コーディングスタイル入門~人に伝えるプログラミング~
コーディングスタイル入門~人に伝えるプログラミング~
俺の エクストリームプログラミング入門 (GuildWorks様向け)
俺の エクストリームプログラミング入門 (GuildWorks様向け)
覚えておきたいプログラミング作法
覚えておきたいプログラミング作法
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
スクラム再入門
スクラム再入門
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」
Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」
良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Agile in 30mins
Agile in 30mins
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
20141105 俺のコードレビュー(lightning talk) #devraku
20141105 俺のコードレビュー(lightning talk) #devraku
20141105 俺のコードレビュー(opening) #devraku
20141105 俺のコードレビュー(opening) #devraku
振り返ればカンバンがある ~チームとカンバンとProduct Ownership~
振り返ればカンバンがある ~チームとカンバンとProduct Ownership~
Semelhante a はじめてのアジャイル
Scrum
Scrum
雄一 増宮
アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904
Masaru Takahashi
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
Rakuten Group, Inc.
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
ふりかえりワークショップ@オープンラボ備後
ふりかえりワークショップ@オープンラボ備後
Shinsuke Abe
Opscode overview july2013 jp
Opscode overview july2013 jp
Creationline,inc.
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
Works Applications
ビジネスを加速するためのウェブサイト運営戦略
ビジネスを加速するためのウェブサイト運営戦略
Concent, Inc.
Gnus intro web_2021
Gnus intro web_2021
耕介 長田
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Ken Azuma
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Yuichi Hasegawa
株式会社ONE WEDGE_company information_202403.pdf
株式会社ONE WEDGE_company information_202403.pdf
ONEWEDGE1
ONE WEDGE_companyinformation20240311.pdf
ONE WEDGE_companyinformation20240311.pdf
ONEWEDGE1
プロジェクト管理支援環境の高度化に向けた取り組み
プロジェクト管理支援環境の高度化に向けた取り組み
agileware_jp
ビジネスを加速するためのウェブサイト運営戦略
ビジネスを加速するためのウェブサイト運営戦略
Concent, Inc.
STOVE_website_dl_1.pdf
STOVE_website_dl_1.pdf
STOVEInc1
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Ken Azuma
BASE株式会社 エンジニア向け会社紹介資料
BASE株式会社 エンジニア向け会社紹介資料
BASE, Inc.
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
「RAD Studio で実践する継続的インテグレーション ~ アプリとデベロッパーの価値を拡張するエッセンス」
「RAD Studio で実践する継続的インテグレーション ~ アプリとデベロッパーの価値を拡張するエッセンス」
Embarcadero Technologies
Semelhante a はじめてのアジャイル
(20)
Scrum
Scrum
アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
ふりかえりワークショップ@オープンラボ備後
ふりかえりワークショップ@オープンラボ備後
Opscode overview july2013 jp
Opscode overview july2013 jp
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
ビジネスを加速するためのウェブサイト運営戦略
ビジネスを加速するためのウェブサイト運営戦略
Gnus intro web_2021
Gnus intro web_2021
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
株式会社ONE WEDGE_company information_202403.pdf
株式会社ONE WEDGE_company information_202403.pdf
ONE WEDGE_companyinformation20240311.pdf
ONE WEDGE_companyinformation20240311.pdf
プロジェクト管理支援環境の高度化に向けた取り組み
プロジェクト管理支援環境の高度化に向けた取り組み
ビジネスを加速するためのウェブサイト運営戦略
ビジネスを加速するためのウェブサイト運営戦略
STOVE_website_dl_1.pdf
STOVE_website_dl_1.pdf
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
BASE株式会社 エンジニア向け会社紹介資料
BASE株式会社 エンジニア向け会社紹介資料
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
「RAD Studio で実践する継続的インテグレーション ~ アプリとデベロッパーの価値を拡張するエッセンス」
「RAD Studio で実践する継続的インテグレーション ~ アプリとデベロッパーの価値を拡張するエッセンス」
Mais de Takao Kimura
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Takao Kimura
Agile and Team Building
Agile and Team Building
Takao Kimura
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Takao Kimura
Ost
Ost
Takao Kimura
アジャイルコーチから見たScaled Agile Method LeSS版
アジャイルコーチから見たScaled Agile Method LeSS版
Takao Kimura
LeSSでつなぐビジネスとIT
LeSSでつなぐビジネスとIT
Takao Kimura
強いチームを創るには-20160124 Gaiakitchen
強いチームを創るには-20160124 Gaiakitchen
Takao Kimura
Agile Discussion 1st
Agile Discussion 1st
Takao Kimura
Nexus and LeSS #rsgt2016
Nexus and LeSS #rsgt2016
Takao Kimura
POStudy Large Scale Scrum
POStudy Large Scale Scrum
Takao Kimura
LeSS Study LeSS Framework Overview
LeSS Study LeSS Framework Overview
Takao Kimura
自社ブログサービス「ヤプログ!」でスクラム開発
自社ブログサービス「ヤプログ!」でスクラム開発
Takao Kimura
20141222 アジャイルサムライ横浜道場 LT&忘年会
20141222 アジャイルサムライ横浜道場 LT&忘年会
Takao Kimura
DevLOVE現場甲子園2014 東日本大会 一回表
DevLOVE現場甲子園2014 東日本大会 一回表
Takao Kimura
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
Takao Kimura
20140214 TOCfEBC openjam
20140214 TOCfEBC openjam
Takao Kimura
20130425 branch1
20130425 branch1
Takao Kimura
20130320 agile pm
20130320 agile pm
Takao Kimura
横浜道場忘年会
横浜道場忘年会
Takao Kimura
横浜道場紹介 AJ12
横浜道場紹介 AJ12
Takao Kimura
Mais de Takao Kimura
(20)
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Agile and Team Building
Agile and Team Building
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Ost
Ost
アジャイルコーチから見たScaled Agile Method LeSS版
アジャイルコーチから見たScaled Agile Method LeSS版
LeSSでつなぐビジネスとIT
LeSSでつなぐビジネスとIT
強いチームを創るには-20160124 Gaiakitchen
強いチームを創るには-20160124 Gaiakitchen
Agile Discussion 1st
Agile Discussion 1st
Nexus and LeSS #rsgt2016
Nexus and LeSS #rsgt2016
POStudy Large Scale Scrum
POStudy Large Scale Scrum
LeSS Study LeSS Framework Overview
LeSS Study LeSS Framework Overview
自社ブログサービス「ヤプログ!」でスクラム開発
自社ブログサービス「ヤプログ!」でスクラム開発
20141222 アジャイルサムライ横浜道場 LT&忘年会
20141222 アジャイルサムライ横浜道場 LT&忘年会
DevLOVE現場甲子園2014 東日本大会 一回表
DevLOVE現場甲子園2014 東日本大会 一回表
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
20140214 TOCfEBC openjam
20140214 TOCfEBC openjam
20130425 branch1
20130425 branch1
20130320 agile pm
20130320 agile pm
横浜道場忘年会
横浜道場忘年会
横浜道場紹介 AJ12
横浜道場紹介 AJ12
Último
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
masakisaito12
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
masakisaito12
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
KayaSuetake1
20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdf
ssuser80a51f
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
ssuserfb441f
コダワリ抜いた経営指南書(概要版) - コダワリ・ビジネス・コンサルティング株式会社
コダワリ抜いた経営指南書(概要版) - コダワリ・ビジネス・コンサルティング株式会社
hmoriyama
答えのないコンセンサスゲーム「無人島での出来事」運営用パワーポイントスライド説明資料
答えのないコンセンサスゲーム「無人島での出来事」運営用パワーポイントスライド説明資料
Jun Chiba
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
ユニパー株式会社
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ 株式会社
KestrelPro Flyer Japan IT Week 2024 (Japanese)
KestrelPro Flyer Japan IT Week 2024 (Japanese)
Data Analytics Company - 47Billion Inc.
Service-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadership
Yasuyoshi Minehisa
Último
(11)
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdf
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
コダワリ抜いた経営指南書(概要版) - コダワリ・ビジネス・コンサルティング株式会社
コダワリ抜いた経営指南書(概要版) - コダワリ・ビジネス・コンサルティング株式会社
答えのないコンセンサスゲーム「無人島での出来事」運営用パワーポイントスライド説明資料
答えのないコンセンサスゲーム「無人島での出来事」運営用パワーポイントスライド説明資料
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
KestrelPro Flyer Japan IT Week 2024 (Japanese)
KestrelPro Flyer Japan IT Week 2024 (Japanese)
Service-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadership
はじめてのアジャイル
1.
はじめてのアジャイル
flickr glennia ©2012 atWare,Inc
2.
自己紹介
株式会社 アットウェア 木村 卓央 KIMURA Takao tw_takubon http://facebook.com/kimura.takao ©2012 atWare,Inc
3.
アジャイルプロセス協議会 • 2004/3 アジャイルプロセス協議会
アジャイル プロジェクトマネジメントWG (APMWG) 参加 • 2010 アジャイルプロセス協議会会報誌に執筆 • 超訳!? クリスタルクリア(第二回) ©2012 atWare,Inc
4.
今日お話すること •アジャイルとは? •アジャイルな開発のはじめ方
flickr soma-samui.com ©2012 atWare,Inc
5.
アジャイルとは?
flickr Paul Hedges ©2012 atWare,Inc
6.
最近アジャイルって聞くようになりましたね。
http://www.nttdata.com/jp/ja/news/release/2012/041700.html ©2012 atWare,Inc
7.
3つの真実 1.プロジェクトの開始時点にすべて の要求を集めることは出来ない 2.集めたところで、要求はどれも必
ずといっていいほど変わる 3.やるべきことはいつだって、与え られた時間と資金より多い ©2012 atWare,Inc
8.
SEC
Software Engineering for Mo No Zu Ku Ri No.1 No.2 No.3 … 1. 2. 3. 25% 63% 12% Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 10 「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」調査概要報告書 http://sec.ipa.go.jp/reports/20120328.html ©2012 atWare,Inc
9.
機能の利用度
©2012 atWare,Inc
10.
アジャイルとは 迅速かつ適応的にソフトウェア開発を行う
軽量な開発手法群の総称 ©2012 atWare,Inc
11.
アジャイルソフトウェア開発宣言
©2012 atWare,Inc http://agilemanifesto.org/iso/ja/
12.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
13.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 顧客満足を最優先し、価値のあるソフトウェアを 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 早く継続的に提供します。 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
14.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 要求の変更はたとえ開発の後期であっても歓迎します。 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 変化を味方につけることによって、 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え お客様の競争力を引き上げます。 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
15.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 リリースします。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
16.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネス側の人と開発者は、プロジェクトを通して ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
17.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 意欲に満ちた人々を集めてプロジェクトを構成します。 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 環境と支援を与え仕事が無事終わるまで 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 彼らを信頼します。 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
18.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 情報を伝える最も効率的で効果的な方法は ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 フェイス・トゥ・フェイスで話 をすることです。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
19.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 動くソフトウェアこそが進捗の最も重要な尺度です。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
20.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを アジャイル・プロセスは持続可能な開発を促進します。 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 一定のペースを継続的に維持できるように 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え しなければなりません。 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
21.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 技術的卓越性と優れた設計に対する ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 不断の注意が機敏さを高めます 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
22.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 シンプルさ(ムダなく作れる量を最大限にすること) ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 が本質です。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
23.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 最良のアーキテクチャ、要求、設計は ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 自己組織的なチームから生み出されます。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
24.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で チームがもっと効率を高めることができるかを 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 定期的に振り返り、それに基づいて自分たちのやり方を 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 最適に調整します。 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
25.
重要なこと 顧客満足を最優先し、価値のあるソフトウェアを 早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、 お客様の競争力を引き上げます。 チームがもっと効率を高めることができるかを 定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。
©2012 atWare,Inc
26.
誤解 早いの∼、うまいの∼、安いの∼
©2012 atWare,Inc
27.
誤解 •設計しない? •ドキュメントを書かない? •計画を立てない? •いつでも仕様変更出来るよね?
©2012 atWare,Inc
28.
アジャイルやってます
プロセス 利用者満足 仕様 ビジネス/ユーザー Lean UX ATDD,BDD チーム活動 Scrum 技術プラクティス CI,TDD Metrics Delivery テスト,品質 計測 スムーズなリリース E-Agility Conference 2012 To be an agile enterprise ∼ 楽天でのふつうのアジャイル・アダプションの進め方 楽天 川口さん https://speakerdeck.com/u/kawaguti/p/eagility ©2012 atWare,Inc
29.
問題を解決する手法ではない
•問題を早期に発見しやすくする • The Scrum Team The Product Owner The Scrum Master The Development Team Scrum Board Burndown Chart Definition of Done Product Backlog Sprint Backlog Increment ©2012 atWare,Inc
30.
Agileとは?
be Agile ©2012 atWare,Inc
31.
アジャイル開発手法の種類 http://www.versionone.com/state_of_agile_development_survey/11/
©2012 atWare,Inc
32.
アジャイルな開発のはじめ方
flickr glennia ©2012 atWare,Inc
33.
アジャイルコーチに来てもらう
flickr somecanuckchick ©2012 atWare,Inc
34.
自力でがんばる
flickr SURF&ROCK (Miguel Navaza) ©2012 atWare,Inc
35.
出来るところにお願いする
flickr Michael Dawes ©2012 atWare,Inc
36.
flickr tomplunkett ©2012 atWare,Inc
37.
flickr Form<->Function ©2012 atWare,Inc
38.
アジャイルな開発のはじめ方
flickr fraggy ©2012 atWare,Inc
39.
ユーザー企業
織田さん 情報システム部に所属 開発はベンダーに依頼している 携帯向けサービスプロジェクトを担当 趣味は自転車 昨今のビジネススピードに対応すべく アジャイルに開発を⾏行行いたい ©2012 atWare,Inc
40.
Scrumから始めましょう
The Scrum Team The Product Owner The Scrum Master The Development Team Scrum Board Burndown Chart Definition of Done Product Backlog Sprint Backlog Increment ©2012 atWare,Inc
41.
スクラムチーム ユーザー企業
開発ベンダー プロダクトオーナー 開発チーム 第三者 アジャイル スクラムマスター コーチ ©2012 atWare,Inc
42.
我われはなぜここにいるのか
エレベーターピッチ パッケージデザイン • [潜在的なニーズを満たしたり、 • 大事な理由その1 潜在的な課題を解決したり] したい (プロダクトの名前) • 大事な理由その2 • [対象顧客] 向けの、 • [プロダクト名] というプロダクトは、 • 大事な理由その3 (素敵な写真) • [プロダクトのカテゴリー] です。 • これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー) 理由] ができ、 <このプロジェクトの根幹に • [代替手段の最右翼] とは違って、 (ユーザーへのアピールその1) (ユーザーへのアピールその2) 関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3) やらないことリスト プロジェクトコミュニティは... やる やらない (ほげほげ部門) (他のチーム) コアチーム (○○グループ) あとで决める 関係者全員を! ...思っているよりもずっと大きい! 技術的な解決策の概要 インセプションデッキ 夜も眠れなくなるような問題は何だろう? 期間を見極める • もし起きたらこわーいこと、その1 リリース! • もし起きたらこわーいこと、その2 構築 受入テスト トレーニング 3ヶ月 1週間 1週間 • もし起きたらこわーいこと、その3 採用する技術: あくまで推測であって、確約するものではありません。 * <プログラミング言語> * <ライブラリ> ←リスクがある箇所 * <ツール> * <その他の要素技術> ←今回は対象外 トレードオフ・スライダー 俺たちの Aチーム 典型的なフォース 人数 役割 強みや期待すること MAX MIN 機能をぜんぶ える(スコープ) 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。 テストも喜んで手伝える。 MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。 2 開発者 C#、MVC.NET、jQuery、SQL MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、 継続的インテグレーション MAX MIN 高い品質、少ない欠陥(品質) 0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。 上記以外で重要なこと 状況報告、スコープ調整、予算管理、レポートラインへの報告 MAX MIN 簡単に使える MAX MIN 考えさせない! MAX MIN 詳細な証跡(なんでもログを取る) MAX MIN (などなど) ©2012 atWare,Inc
43.
プロダクトオーナーとしての責務 •プロダクトバックログは優先順位順 に並べる •優先順位の高いバックログアイテム は開発チームが理解出来るほど詳細
か •プロジェクトの為に毎日時間を割け るようにする •プロジェクトの決定を下せる ©2012 atWare,Inc
44.
最初の数スプリントは •開発チームが作られていく過程で重 要です •以降、安定したチームとなる事が理 想(なっていない場合はどこかに問
題がある) ©2012 atWare,Inc
45.
発注者側の不安 •アジャイルな開発は、開発チームの 自己組織化で運営していくけど、本 当に成果が出るの?期日には納品し
てもらわないと困るのだけど。。。 ©2012 atWare,Inc
46.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 意欲に満ちた人々を集めてプロジェクトを構成します。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 環境と支援を与え仕事が無事終わるまで ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 彼らを信頼します。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 ビジネス側の人と開発者は、プロジェクトを通して スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 日々一緒に働かなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
47.
SIer
佐々木さん システム開発部所属 社内の標準的な開発手法はウォーターフォール 会社としては、アジャイル開発手法にも力を入 れようとしている お客様満⾜足度度を上げる為に、開発を アジャイルに⾏行行いたい ©2012 atWare,Inc
48.
スクラムチーム
お客様 開発ベンダー プロダクトオーナー 開発チーム 第三者 アジャイル スクラムマスター コーチ ©2012 atWare,Inc
49.
受注者側の不安 •アジャイルな開発では、最後まで変 更を受け入れると言うけど、結局、 今まで通り期日までに全て納品して
って言われるんじゃないの ©2012 atWare,Inc
50.
原則
我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって 顧客満足を最優先し、価値のあるソフトウェアを お客様の競争力を引き上げます。 動くソフトウェアを 2 3週間から2 3ヶ月というできるだけ短い時間間隔で 早く継続的に提供します。 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 要求の変更はたとえ開発の後期であっても歓迎します。 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 変化を味方につけることによって、 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 お客様の競争力を引き上げます。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc
51.
一開発者
吉田さん システム開発部所属 社内の標準的な開発手法はウォーターフォール 今回のセミナーで感銘を受けてアジャイル開発 手法を導入したいと考えている お客様満⾜足度度を上げる為に、開発を アジャイルに⾏行行いたい ©2012 atWare,Inc
52.
まずは一人でもはじめてみよう お客様
開発ベンダー 開発チーム ©2012 atWare,Inc
53.
始めやすい •ふりかえり •見える化 •タスクかんばん •バーンダウンチャート
•インピーディメントリスト(障害 リスト) ©2012 atWare,Inc
54.
必ずやった方が良いプラクティス •ユニットテスト •リファクタリング •CI •TDD
©2012 atWare,Inc
55.
信頼関係が重要 ©2012 atWare,Inc
56.
アカウンタビリティー 「自分の意思で、現実を見つめ、問題に当事者 として取り組み、解決策を見出し、その解決策 を実行しようとする意識」
©2012 atWare,Inc
57.
お話したこと ① •アジャイルとは? •アジャイルが話題になる理由
•価値と原則 •アジャイルについての誤解 ©2012 atWare,Inc
58.
お話したこと② •アジャイルな開発のはじめ方 •3つの方法 •はじめ方モデルケース
•ユーザー企業として •SIerとして •開発者として •信頼関係が重要 •アカウンタビリティ ©2012 atWare,Inc
59.
参考書籍
http://www.scrum.org/scrumguides/ : 2011 Developed and sustained by Ken Schwaber and Jeff Sutherland http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches ©2012 atWare,Inc
60.
参考書籍
©2012 atWare,Inc
61.
コミュニティ
#suc3rum http://www.taoofscrum.org/ #scrumdo #agilesamurai #横浜道場 https://github.com/agile-‐‑‒samurai-‐‑‒ja/support/wiki/Readingagilesamuraiinyokohama ©2012 atWare,Inc
62.
regional
2013.1.15-16 at Akihabara UDX CONFERENCE 2012年10月上旬エントリー開始予定!! J urgen Jame s O. 氏 野中郁 次郎氏 A ppelo Co plien氏 Scrum Alliance Regional Gathering - Tokyo - 2013 http://www.scrumgatheringtokyo.org/ #sgt2013 @ScrumTokyo 主催 : Scrum Regional Gathering Tokyo 2013 実行委員会 / 共催 : 株式会社翔泳社
63.
64.
ご清聴ありがとうございました
©2012 atWare,Inc