Soumettre la recherche
Mettre en ligne
アジャイルな見積りと計画づくり2
•
14 j'aime
•
8,198 vues
Arata Fujimura
Suivre
Signaler
Partager
Signaler
Partager
1 sur 51
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
アジャイルな見積りと計画づくり1
アジャイルな見積りと計画づくり1
Arata Fujimura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
データの価値を最大化させるためのデザイン~データビジュアライゼーションの方法~ #devsumi 17-E-2
データの価値を最大化させるためのデザイン~データビジュアライゼーションの方法~ #devsumi 17-E-2
Yahoo!デベロッパーネットワーク
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
Yahoo!デベロッパーネットワーク
Agile Estimating And Planning
Agile Estimating And Planning
Eiwa System Management, Inc.
Recommandé
アジャイルな見積りと計画づくり1
アジャイルな見積りと計画づくり1
Arata Fujimura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
データの価値を最大化させるためのデザイン~データビジュアライゼーションの方法~ #devsumi 17-E-2
データの価値を最大化させるためのデザイン~データビジュアライゼーションの方法~ #devsumi 17-E-2
Yahoo!デベロッパーネットワーク
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
Yahoo!デベロッパーネットワーク
Agile Estimating And Planning
Agile Estimating And Planning
Eiwa System Management, Inc.
Slideshare Japanese
Slideshare Japanese
Hidenori Goto
マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話
cyberagent
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
株式会社MonotaRO Tech Team
セールスアニマルになろう スタートアップ初期の営業戦略
セールスアニマルになろう スタートアップ初期の営業戦略
Takaaki Umada
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
Arata Fujimura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
Daisuke Nogami
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
【Unite Tokyo 2019】AWS for Unity Developers
【Unite Tokyo 2019】AWS for Unity Developers
UnityTechnologiesJapan002
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
Carnot Inc.
ChatGPT Impact - その社会的/ビジネス価値を考える -
ChatGPT Impact - その社会的/ビジネス価値を考える -
Daiyu Hatakeyama
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
Takao Oyobe
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
こわくない Git
こわくない Git
Kota Saito
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
Ore Product
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
Contenu connexe
Tendances
Slideshare Japanese
Slideshare Japanese
Hidenori Goto
マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話
cyberagent
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
株式会社MonotaRO Tech Team
セールスアニマルになろう スタートアップ初期の営業戦略
セールスアニマルになろう スタートアップ初期の営業戦略
Takaaki Umada
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
Arata Fujimura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
Daisuke Nogami
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
【Unite Tokyo 2019】AWS for Unity Developers
【Unite Tokyo 2019】AWS for Unity Developers
UnityTechnologiesJapan002
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
Carnot Inc.
ChatGPT Impact - その社会的/ビジネス価値を考える -
ChatGPT Impact - その社会的/ビジネス価値を考える -
Daiyu Hatakeyama
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
Takao Oyobe
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
こわくない Git
こわくない Git
Kota Saito
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
Ore Product
Tendances
(20)
Slideshare Japanese
Slideshare Japanese
マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
datatech-jp Casual Talks#3 データエンジニアを採用するための試行錯誤
セールスアニマルになろう スタートアップ初期の営業戦略
セールスアニマルになろう スタートアップ初期の営業戦略
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
決定版:サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
【Unite Tokyo 2019】AWS for Unity Developers
【Unite Tokyo 2019】AWS for Unity Developers
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
ChatGPT Impact - その社会的/ビジネス価値を考える -
ChatGPT Impact - その社会的/ビジネス価値を考える -
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
こわくない Git
こわくない Git
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
Plus de Arata Fujimura
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
Arata Fujimura
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
Arata Fujimura
スクラムマスター募集中
スクラムマスター募集中
Arata Fujimura
変化に強い、継続的に学習する組織に変わるためのステップとは
変化に強い、継続的に学習する組織に変わるためのステップとは
Arata Fujimura
クラスメソッドにおけるスクラム開発の光と影
クラスメソッドにおけるスクラム開発の光と影
Arata Fujimura
モダンオフショア開発のすすめ
モダンオフショア開発のすすめ
Arata Fujimura
スクラムワークショップ
スクラムワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
Arata Fujimura
登壇勉強会 〜それぞれの流儀がそこにある〜
登壇勉強会 〜それぞれの流儀がそこにある〜
Arata Fujimura
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
Arata Fujimura
PdMワークショップ
PdMワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
Experience DevOps Implementation Support Service
Experience DevOps Implementation Support Service
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
俺のレアジョブ利用法
俺のレアジョブ利用法
Arata Fujimura
DevOps導入支援、始めました
DevOps導入支援、始めました
Arata Fujimura
プラクティス厨から始めるアジャイル開発
プラクティス厨から始めるアジャイル開発
Arata Fujimura
Plus de Arata Fujimura
(20)
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
スクラムマスター募集中
スクラムマスター募集中
変化に強い、継続的に学習する組織に変わるためのステップとは
変化に強い、継続的に学習する組織に変わるためのステップとは
クラスメソッドにおけるスクラム開発の光と影
クラスメソッドにおけるスクラム開発の光と影
モダンオフショア開発のすすめ
モダンオフショア開発のすすめ
スクラムワークショップ
スクラムワークショップ
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
登壇勉強会 〜それぞれの流儀がそこにある〜
登壇勉強会 〜それぞれの流儀がそこにある〜
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
PdMワークショップ
PdMワークショップ
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Experience DevOps Implementation Support Service
Experience DevOps Implementation Support Service
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
俺のレアジョブ利用法
俺のレアジョブ利用法
DevOps導入支援、始めました
DevOps導入支援、始めました
プラクティス厨から始めるアジャイル開発
プラクティス厨から始めるアジャイル開発
アジャイルな見積りと計画づくり2
1.
1 2014年5月23日 GMOインターネット株式会社 次世代システム研究室 藤村 新 アジャイルな見積りと 計画づくり2
2.
2 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
3.
3 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
4.
5.
5 前回 計画の目的 なぜ従来の計画づくりは失敗するの か
なぜアジャイルな計画づくりはうまくい くのか
6.
6 今回 具体的な方法 見積り方法
優先順位の付け方 リリース計画の作り方 イテレーション計画の作り方
7.
7 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
8.
期間の見積もりは以下のようなプロセスになる 要求されるフィーチャ 規模の見積もり 期間への変換 スケジュール
9.
1.ストーリー ポイント 2.理想日
10.
http://www.slideshare.net/YohNakamura/yohhatu-yohhatu
11.
http://www.slideshare.net/YohNakamura/yohhatu-yohhatu
12.
http://www.slideshare.net/YohNakamura/yohhatu-yohhatu
13.
作業量の見積り と 期間の見積り が分離
14.
ストーリーポイントの長所 職能横断的な作業の進め方 を促進する 長持ちする
純粋に大きさだけをあらわす 早い 僕の理想日と君の理想日は 違う
15.
プランニングポーカー 活発な対話を引き出す
16.
1.ストーリー ポイント 2.理想日
17.
サッカーの試合の長さ? • 理想時間: • 45分+45分=90分 •
現実時間: • 45分+3分+15分+ 45分+5分≒113分
18.
18 •リリース済みプロダ クトのサポート •体調不良 •会議 •デモンストレーション •私用 •電話応対 •緊急の割込み作業 •トレーニング •メール •レビューやウォークス ルー •候補者の面接 •タスクの切り替え時 間 •リリース済みプロダ クトのバグ修正 •マネージャとの面談
19.
各ストーリーで 担当ごとの理想日を 見積もるという 手間をかけても、 報われる事は滅多にない
20.
理想日の長所 • プロジェクト関係 者に説明しやすい • 導入しやすい
21.
理想日 ≠ 現実日
22.
22 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
23.
優先順位づけの判断要素 1. 金銭価値 2. 開発にかかるコスト 3.
開発を通じて学べる知 識の量とその意義 4. 低減できるリスク
24.
優先順位づけの判断要素 1. 金銭価値 2. 開発にかかるコスト 3.
開発を通じて学べる知 識の量とその意義 4. 低減できるリスク
25.
オススメは 「望ましさ」 による優先順位 づけ
26.
顧客満足度の狩野モデル 1. 当たり前、または必須の フィーチャ 2. 線形、一元的なフィーチャ 3.
魅力的な、わくわくする フィーチャ
27.
例)ホテルの特徴 必須 ベッド、バスルーム、机、清潔であること
あればあるほど良い ベッドの寝心地、部屋が広い、ジムにあ るマシンの種類と台数 魅力的 ウォーキングマシンのテレビ、毎日無料 でミネラルウォーターがもらえる
28.
http://www.nttdata.com/jp/ja/insights/trend_keyword/2013071101.html
29.
例)ホテルの特徴 充足質問 毎日無料でミネラルウォーターがもらえ たらどう思いますか?
気に入る 不充足質問 毎日無料でミネラルウォーターがもらえ なかったらどう思いますか? しかたない
30.
http://sugiim.hatenablog.com/entry/2013/04/15/110321
31.
1. 当たり前のフィーチャは不可 欠。リリースまでに必ず開発。 2. 線形のフィーチャをできるだ け多く完成させる。 3.
魅力的なフィーチャはこれら の機能を実装した後に、時 間の許す範囲で対応する。
32.
32 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
33.
1. 満足条件を決める 日付主導
フィーチャ主導 2. ユーザーストーリーを見積もる 3. イテレーションの長さを決める 4. ベロシティを見積もる 5. ユーザーストーリーに優先順位 を付ける
34.
6. ストーリーを選択し、リリース日 を決める 日付主導
イテレーション数にベロシティを掛け れば、リリースに含められるストーリー ポイントの合計を求められる。 フィーチャ主導 リリースに必要なすべてのフィーチャ の見積りを合計し、その値をベロシ ティで割る。
35.
36.
ストーリーポイント合計 ÷ ベロシティ
37.
38.
重要なのはリリース計 画を更新する事。 イテレーション終了時 点でリリース計画を見 直す。
39.
39 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
40.
リリース計画 イテレーション計画 計画の 「水平線」 3~6ヶ月先 1~4週間先 構成要素
ユーザーストーリー タスク 見積り単位 ストーリーポイント または理想日 理想時間
41.
イテレーション計画 の成果物
42.
43.
イテレーション 計画で やらない事
44.
タスクの 担当者を 決めない
45.
プロジェクトが最もうまくいくのは、 チームに「全員が一丸となって取り 組む」という態度が備わっていると きだ。 自分の空いた時間はチームのため に使うし、他のメンバーもきっとそう してくれると思える状態である。
46.
イテレーションが始まる前に、すべて のタスクにサインアップして担当者 を決めてしまうと、イテレーションの ゴールに向かってチーム全員が一丸 となって取り組むという参加意欲に 水を差すことになるのだ。
47.
1. 優先順位を調整する 2. 目標ベロシティを決める 3.
イテレーションのゴールを決める 4. ユーザーストーリーを選ぶ 5. ユーザーストーリーをタスクに分 解する 6. タスクを見積もる
48.
多少の設計はOK ある程度の設計に関する議 論は必要
クラス図などのモデルまでい くと危険 タスクの適切なサイズ 1営業日に1つ完了できるぐ らいの大きさが適切
49.
49 目次 1) 前回の復習 2) 見積もり方法 3)
優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ
50.
ストーリーポイントを用いるべき 優先順位も感覚ではなく手法 (狩野モデル等)を用いて決め てみる
イテレーション終了時にリリー ス計画を見直す 「タスクの担当者を決めない」 はやってみる価値がある
51.
51 おわり
Télécharger maintenant