Submit Search
Upload
アジャイルな見積りと計画づくり2
•
14 likes
•
8,195 views
Arata Fujimura
Follow
Report
Share
Report
Share
1 of 51
Download now
Download to read offline
Recommended
アジャイルな見積りと計画づくり1
アジャイルな見積りと計画づくり1
Arata Fujimura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
Tsuyoshi Ushio
こわくない Git
こわくない Git
Kota Saito
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
Recommended
アジャイルな見積りと計画づくり1
アジャイルな見積りと計画づくり1
Arata Fujimura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
Tsuyoshi Ushio
こわくない Git
こわくない Git
Kota Saito
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
Takao Oyobe
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
ブレークスルーパートナーズ 赤羽雄二
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
Takaaki Umada
アジャイルベンダーの未来
アジャイルベンダーの未来
Yukio Okajima
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
プレゼン初心者にありがちなアンチパターン
プレゼン初心者にありがちなアンチパターン
真俊 横田
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
Takaaki Umada
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
More Related Content
What's hot
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
Takao Oyobe
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
ブレークスルーパートナーズ 赤羽雄二
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
Takaaki Umada
アジャイルベンダーの未来
アジャイルベンダーの未来
Yukio Okajima
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
プレゼン初心者にありがちなアンチパターン
プレゼン初心者にありがちなアンチパターン
真俊 横田
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
Takaaki Umada
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
What's hot
(20)
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
リーンスタートアップ時代の事業計画とサービス開発、資金調達のあり方
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
アジャイルベンダーの未来
アジャイルベンダーの未来
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
プレゼン初心者にありがちなアンチパターン
プレゼン初心者にありがちなアンチパターン
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
ユーザーストーリーの分割
ユーザーストーリーの分割
テストコードの DRY と DAMP
テストコードの DRY と DAMP
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
More from 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
More from 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 おわり
Download now