アジャイルな見積りと計画づくり1

1

2014年4月25日

ＧＭＯインターネット株式会社

次世代システム研究室

藤村新

アジャイルな見積りと

計画づくり1

2

目次

1)発表目的

2)計画の目的

3)なぜ計画づくりに失敗するのか

4)なぜアジャイルな計画づくりがうまくいくのか

5)よくある誤解

6)まとめ

3

目次

1)発表目的

2)計画の目的




6)まとめ

4

最近次研でもアジャイル

開発用語が定着してきたプロダクトバックログ[スクラム]

ストーリー[XP]

(ストーリー)ポイント

スプリント[スクラム]

ベロシティ

このタイミングで一度知識の整理をすべき

•AEPがバイブル •本当は全員読んで読書会したい •まずは概要を伝えたい

一回では伝えられない

9

今回

計画の目的

なぜ従来の計画づくりは失敗するの

か

なぜアジャイルな計画づくりはうまくい

くのか

10

次回

具体的な方法

見積り方法

優先順位の付け方

リリース計画の作り方

イテレーション計画の作り方

11

目次

1)発表目的

2)計画の目的




6)まとめ

計画づくりは難しい

1. まったく計画しない

2. 労力を費やしすぎる

良い計画とは？

• ステークホルダーが信頼できる計画

• その計画を基にして意思決定できる

18

目次

1)発表目的

2)計画の目的




6)まとめ

• フィーチャ(ユーザーにとっての価値)ではなく作業を計画している

• 優先順位順にフィーチャを開発していない

• 不確実性を無視している

• 見積もりがコミットメントになっている

23

目次

1)発表目的

2)計画の目的




6)まとめ

• 頻繁に計画を見なおしている

• 規模の見積もりと期間の見積もりを分離している

• 複数レベルの計画を立てている

リリース計画スプリント計画今日やる事

• 計画の基準がタスクではなくフィーチャである

• チーム全体を対象にトラッキングしている

• 不確実性を受け入れて計画に取り込んでいる

目標の不確実性開発手法の不確実性

30

目次

1)発表目的

2)計画の目的




6)まとめ

「アジャイルでは長期スケジュールが立てられない」

詳細は次回話しますが

ストーリーポイント合計 ÷

ベロシティ

ただし

プロダクトバックログが常に更新されている前提

スクラムでも、プロダクトバックログリファインメントに 10%の時間を使えと定義

「変更を受け入れるとリリースが延び延びになる」

計画の変更は必ずしも予定期日を動かす事ではない

固定固定固定可変

「スプリントで行うストーリーをスプリント計画 MTGで追加する」

基本はプロダクトバックログの上位から選択

プロダクトバックログが常に更新されている前提

「どうせ後から変更できるから最初にしっかり考えない」

• なぜ変更が発生？何かを学習したから

(開発チーム) フィーチャーを追加したいと思った(PO)

• ふりかえり • スプリントレビュー

52

目次

1)発表目的

2)計画の目的




6)まとめ

• 自己流のアーキテクチャ設計

• 自己流のソフトウェア設計

同じく

自己流のプロジェクトマネジメント

守：型を守る破：型を破る離：型から離れる

59

おわり

アジャイルな見積りと計画づくり1

Documents

Transcript of アジャイルな見積りと計画づくり1