イテレーション毎の開発速度
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を早速購入して読み始めた。
全部読んでないけど、考えていることをメモ書き。
【1.元ネタ1】第8回 チームの開発速度を計測してリリース・プランニングに役立てる:ITpro
TRICHORDの開発チームによるアジャイル開発の実践例。
イテレーション単位で開発可能な機能(ストーリー)の数から開発速度(velocity)が算出される。
つまり、この数を平均化すると、そのチームが1イテレーションで開発できる見積もり工数になる。
アジャイル開発では、最終リリースまでに複数のイテレーション単位でリリースしていくから、そのたびに実績工数を測定できる。
イテレーションを経験するたびに、以前のイテレーションの開発速度から、どれだけの機能を開発可能か分かる。
理論上では、経験したイテレーションの数が多いほど、精度の高い開発速度が得られるから、後のイテレーションほど、精度の高いイテレーション計画を作ることができる。
【2.元ネタ2】塹壕よりScrumとXP
Scrum and XP from the Trenches v.2.2(上記の日本語訳PDF)
--↓引用開始↓---
13. リリースの計画と価格確定させた契約をどうするか
通常、僕たちのリリース計画は、この質問に答えるよう試みることだ。「この新しいシステムのバージョン1.0 を、最も遅い場合、いつ納品することができるのか」
もしリリース計画について真剣に学びたいのなら、この章を飛ばして、代わりにMikeCohn の著書「Agile Estimating and Planning」を購入することをお勧めする。
僕はこの本をもっと早く読んでおきたかったと心底思う(僕がこれを読んだのは、僕たちが身をもってこの内容を理解した後だった…)。
リリース計画の僕バージョンは、ちょっと安易なものだけど、良い取っ掛かりとなる筈だ。
--↑引用終了↑---
この記事は、Scrum+XPの実践例。
イテレーション計画で工数見積するなら、まず「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を読めと言っている。
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」では、こんな端書がある。
計画作りは価値の探求なのだ。
顧客とネゴして作った要件定義書からシステムを作っておしまい、という開発スタイルは、サービス業と化したSIerにはありえない。
開発中に仕様変更と称した変更要求が、五月雨式に開発チームに必ず降ってくる。
あるいは、リリース後に機能改善と称した膨大な変更要求がやって来ることもある。
結局、システム開発は顧客と一緒に、どんなシステムが顧客にとって価値があるのか、を探検するプロセス。
従来型の計画作りの問題点は、プロジェクトのチームやステークホルダが見積もりをコミットメントと捉えてしまうことだ。
見積もりは(見積もった時間内に作業が完了する)確率だが、コミットメントは確率ではない。
つまり、見積もり工数は、平均の開発速度。
必ずその工数で完了できるコミットメントではない。
アジャイル開発ならば、複数のイテレーションを経験することで、平均の開発速度の精度が上がるので、実現可能性の高いイテレーション計画を作ることができるはず。
【3】Redmineにはレポートという機能があり、実績工数を表示する。
この機能は、時間トラッキング機能と関係している。
Redmineの時間トラッキング機能は、作業分類というチケットの属性で制御する。
作業分類は、例えば、設計・実装・テスト・管理などに分類できるから、チケットの実績工数を入力する時、作業分類によって実績工数を色付けできる。
この機能のおかげで、設計・開発・テストの各工程の実績工数を測定できる。
Redmineのレポート機能では、バージョンと月別のクロス集計を表示できる。
この集計結果から、1イテレーションにかかった実績工数がどの期間で発生したか分かるので、イテレーション単位の開発速度を測定できる。
但し、Redmineでは、予定・実績工数比較の機能が弱く、バージョン画面でしか見れない。
本当はもっと色んな角度から予実比較を見たい。
それができれば、プロジェクトのリスク管理がやりやすくなる。
例えば、この機能のテストで意外と時間が取られたのか、などの気付きが出てくる。
Redmineに、このアジャイル開発における開発速度の概念を注入して、チケット駆動開発のアイデアを強固できないか?
それから、「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」だけでなく、09/2/18発売予定の「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
」も必読だ!
【参考リンク】
続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium : テクモラトリアム
[本]アジャイルな見積りと計画づくり 安井さんとのやりとり - hiro_eの物事(楽しい物や思ったこと)
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / 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)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント