Velocity駆動のイテレーション計画の作り方とは
RedmineやTracから工数集計に関するメトリクスを採取していて、色々気付いたことがあった。
「アジャイルサムライ」「アジャイルな見積りと計画づくり
」「アート・オブ・プロジェクトマネジメント
」も読んでみて考えたことをメモ。
ラフなメモ書き。
RedmineやTracから工数集計に関するメトリクスから僕が一番抽出したいのは、Velocityだ。
Velocityは開発チームの生産能力を意味する。
Velocityが分かれば、顧客から突然降ってきた要求に対して、開発チームが受け入れる能力があるかどうか、プロジェクトリーダーが判定できるし、顧客へ対応を延期するよう説明することもやりやすくなる。
Agile開発では、複数回のイテレーションを繰り返して最終リリースするから、イテレーション単位の生産能力(Velocity)を計測しやすい。
複数回イテレーションをこなせば、理論的にはVelocityのばらつきもなくなり、安定してくるはず。
「アジャイルな見積りと計画づくり」では、イテレーション計画の作り方として、Velocity駆動とコミットメント駆動をあげていて、コミットメント駆動を推奨している。
「アジャイルサムライ」では、Velocityをチームが分かっているという前提で、Velocity駆動による計画づくりを具体的に説明してくれている。
Velocity駆動でイテレーションを計画すると、バーンダウンチャートで右肩下がりにいつ頃リリース出来るのか、を予測しやすくなる。
「アート・オブ・プロジェクトマネジメント」では、プロジェクト後半の戦略として、残作業の降下速度の調整が重要と書いているが、残作業の降下速度はまさにVelocityを意味していると思う。
XPやScrumが教える所では、Velocityは安定しているものだから、期日までにリリースするには、残作業の量を減らすしか選択肢がない。
つまり、リリース順位の高い作業を優先することで、残作業の量を絞り、残作業の降下速度(Velocity)の先を期日に合わせるように調整するのがAgile開発の本来のマネジメントになる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント