イテレーション毎の開発速度
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を早速購入して読み始めた。
全部読んでないけど、考えていることをメモ書き。
【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の物事(楽しい物や思ったこと)
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント