XPを実現するCaseツールは?→Redmineだ!
JaSST関西2008で出た質問。
アジャイル開発を現場で使っているが、イテレーションが短くて多いから管理しにくい。
イテレーションを管理できる良いCaseツールはありますか?
XPJUG関西代表の細谷さんは立場上曖昧に答えたけれど、僕の回答は、Redmineを使って下さい、だな。
RedmineこそXPを実現する開発インフラです。
Redmineでチケット駆動開発を実践すれば、XPの計画ゲームを実現できます。
と。
Redmineを2ヶ月使ってみて、プロジェクトリーダーの本来の仕事である、タスクの優先順位付けやリスク管理に時間を費やせるようになった。
【1】もう一度おさらい。
Redmineでプロジェクト作成後にまず設定するものは下記の通り。
1-1.バージョン
マイルストーンと同値。
XPのイテレーションに相当する。
1-2.カテゴリ
システムの機能別の単位。
XPのストーリーカードの分類単位。
1-3.トラッカー
チケットの種類。
バグ修正、仕様変更、仕様追加、新機能開発など。
XPのタスクカードの分類単位。
1-4.リポジトリ
SVNを指定する。
リビジョン単位のコミットログが一覧表示されるように、チームでフォーマットを統一しておく。
XPのソースコード共有そのもの。
カテゴリやトラッカーは、チケットの集計結果を多面的に見る時に使う。
だから、カテゴリやトラッカーにどんな項目を作って運用するか、は、プロジェクト管理の醍醐味。
ソフトウェア工学の知識をフルに使えばいいだろう。
【2】それからチケットを登録していく。
チケットは、プロジェクト内部で発生する作業全て。
チケットは、XPのタスクカードに相当する。
基本は1チケット1担当者。
チケットの工数は5人日以内に抑える方が管理しやすい。
チケットには予想工数の欄もあるので、開発者に見積もりしてもらえばいい。
Redmineのチケットには他チケットとリンクする機能があるので、階層化、カテゴリ化できる。
「関連する」「先行する」「ブロックする」の3種類の使い分けもようやく分かった。
リンク付けは、チケットの依存関係の意味を表す。
複数の作業を階層化したい場合、「関連する」でリンク付ける。
これは単純な相互リンク。
機能Bを作る前に共通機能Aを開発する必要があるなら、BのチケットへAのチケットを「先行する」リンクをはる。
これによって、ガントチャートのFS関係のようにできる。
チケットBはチケットAが終わらないと実行できない場合、チケットBへチケットAを「ブロックする」リンクを張る。
例えば、テストケースAでバグが出て、テストケースBの検証ができない場合が相当するだろう。
あるいは、バグAの検証が完了しないと、バグBの検証も終わらない場合。
TestLinkでも同様の概念がある。
【3】プロジェクトの進捗は下記でリアルタイムに誰でも確認できる。
3-1.活動
チケット更新やSVNリビジョンを表示。
バグ発生やバグ修正、検証作業が多いと、活動欄が一杯になる。
少ない場合は、進捗がはかどっていない証拠。
3-2.ロードマップ
バージョン単位のチケットの状態と進捗パーセンテージを表示。
XPのイテレーションが終了するには、進捗を100%にしなければならない。
3-3.ガントチャート
遅れていると赤字で表示されるので、MSProjectよりも分かりやすい。
プロジェクトリーダーでなくとも、開発者もプロジェクトの進捗がすぐ分かる。
「プロジェクトの見える化」で最も有効な箇所。
3-4.カレンダー
チケットの開始終了日やマイルストーンを表示。
マスタースケジュールみたいなもの。
3-5.レポート(サマリ)
トラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに、チケットの状態(未完了・完了)の集計結果を表示
CSV出力ができるので、ここからバグ収束曲線、バーンダーンチャートを作ったりできる。
ソフトウェア工学の知識をフルに使える。
3-6.経過時間
実績工数(単位:h)をトラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに表示。
このデータを蓄積すれば、2次開発以降に、見積もり工数の精度を上げることができる。
Redmineの強みは、ガントチャート自動生成と、多様な集計結果だ。
これによって、人、時間という貴重で有限な資源を、ぴったりのタイミングで的確に投入するのが可能になる。
Redmineでチケット駆動開発(TiDD)がXPを実現する仕掛けだ。
つまり、Redmineのチケットの状態管理でプロジェクト管理できる。
チケットの状態の集計結果から、ソフトウェア工学の知識が使えるようになる。
Redmineはリソース管理そのものだ。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineの直近の課題~競合ツールGitlabに対抗できるか(2018.04.25)
- AstahのRedmine連携プラグインが公開されました(2018.01.18)
- 複数Redmineの内容を一つのRedmineに集約して見る方法(2018.03.16)
- RedmineもOSLC規格を導入してトレーサビリティを強化すべきか(2018.03.12)
- Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化(2017.11.30)
「チケット駆動開発」カテゴリの記事
- 第18回Redmine大阪の感想 #RedmineOsaka(2018.02.04)
- 気象庁の数値予報課におけるRedmine利用事例(2017.05.22)
- チケット駆動の罠~複雑さはチケットの粒度に関連している(2016.12.28)
- Redmineのアンチパターンは2種類に区別できるのではないか(2018.02.21)
- 第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT(2017.11.19)
「プロジェクトマネジメント」カテゴリの記事
- チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由(2018.03.09)
- 【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで」(2014.03.07)
- プロジェクトリーダーやマネージャに問われる能力は何か?(2005.10.05)
- Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例(2016.07.23)
- TiDDをRubyで補強するアイデア(2009.12.26)
コメント