リードタイムとベロシティ

651 Views

April 01, 23

スライド概要

ベロシティだけでは見えてこないリードタイムについて考えてみた。どちらが正しい、とかではなく、リードタイムを短くしたいのか並列度をあげたいのか、分かった上で選べるようになりたいですね。

profile-image

scrum master, software engineer

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

リードタイムとベロシティ rev.1

2.

ベロシティだけ見ていれば十分か? 前提 ● アジャイル開発をやっているチーム ● チームの開発が良くなっていることをどう計測するか

3.

ベロシティだけ見てれば十分か? スプリント1 スプリント2 タスク 1 /8pt タスク 2 /8pt タスク 3 /8pt スプリント3 済 スプリント4 スプリント5 同じ8ptだが並行作業多いのでタスク 3以降はリードタイムは伸びている LT: 9 済 LT: 8 済 LT: 11 タスク 4 /8pt 済 タスク 5 /8pt 3名体制のイメージ。同時にアク ティブなタスクは3つまで スプリント6 済 LT: 15 LT: 12 タスク 6 /8pt タスク 7 /8pt タスク 8 /8pt 作業トータル: 64pt 0 簡便のためcapacityは 12固定とします 8 16 LT: 14 済 LT: 12 済 タスク 9 /8pt 8 済 8 ベロシティは 8~24 / LTは 8 ~ 15 24 LT: 13

4.

リードタイムを意識する スプリント1 スプリント2 タスク 1 /8pt タスク 2 /8pt タスク 3 /8pt スプリント3 スプリント4 スプリント5 スプリント6 済 LT: 8 済 LT: 8 済 LT: 8 タスク 4 /8pt 済 タスク 5 /8pt LT: 8 済 LT: 9 タスク 6 /8pt 済 LT: 8 タスク 7 /8pt タスク 8 /8pt 作業トータル: 56pt 0 簡便のためcapacityは 12固定とします 16 8 タスク 9 /8pt 8 16 ベロシティは 8~16 / LTは 8 ~ 9 8

5.

さらにリードタイムを意識する スプリント1 スプリント2 タスク 1 /8pt LT: 4 済 タスク 1 済 タスク 2 /8pt タスク 2 スプリント3 スプリント4 スプリント5 LT: 6 タスク 3 /8pt LT: 6 3 済 タスク 4 /8pt 済 4 タスク 5 LT: 5 LT: 6 済 5 タスク 6 /8pt 作業トータル: 48pt 済 LT: 6 6 8 簡便のためcapacityは 12固定とします 8 8 16 8 ベロシティは 8~16 / LTは 4 ~ 6 スプリント6

6.

● いずれも瞬間同時実行タスクは3。 ● 理想論 ● スキル移転が必要 ● 外に依存しないチームなほど良い ● 個々人の稼働率は高い ● 実際はコンテキストスイッチのぶんさらに 効率落ちる ● コードのコンフリクトが起こりやすい→余 分な作業が増える ● 優先度の逆転がおこる ● できるだけ、今のタスクを終わらせてから次 のタスクに着手する ● (実際はここまでキレイにはできない)

7.

● ● ● ● 実際ここまでキレイにはできない スキル移転やチームで完結できることを増やす必要あり リソース効率は落ちる(落としたほうがよい)。手が空いている人が出るが、 リファクタリングや自動テスト整備、内部ドキュメンテーションなど開発以外でもや れることは実はけっこうある。 でも目指す価値はある → なぜか? Why アジャイル開発を選んでいる ? ● 早くフィードバックを得て次の活動に活かしたいから ● フィードバックはユーザーや顧客だけでなく、社内ステークホルダーやエンジニアだった り、自分たち自身で得ることもある ● リリースして初めて価値を生む(可能性がある)。それまでは仕掛り在庫。実利ゼロ。 ● リードタイムを短くすることに価値を感じないのであればアジャイルやらなくても良い