Redmineでチケット駆動開発をAgileに運用するための4つの方法

Redmineでチケット駆動開発をAgileに運用するための方法をもう一度まとめておく。
あくまでも僕の一意見なので参考までに。

【参考】
チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

Agile開発の肝はイテレーションにあり: プログラマの思索

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【Redmineでチケット駆動開発をAgileに運用するための4つの方法】
(1)RedmineチケットをXPのタスクカードのように扱う (Ticket First)
(2)Redmineチケットに構成管理情報をリンクさせる (No Ticket, No Commit!)
(3)イテレーションをビルドモジュールのリリース予定バージョンに対応付ける
(4)ビルドモジュール(コンポーネント)ごとにRedmineプロジェクトを作る

【解説】
(1)チケットは障害報告書だけでなく、仕様変更もタスクも扱う。
　チケットは作業指示書である。
　チケットは仕様書ではなく、どんな仕様を実装するかという作業内容や、どのように実装していったのか、という作業履歴が書かれている。
　チケットに作業の予定日や実施した作業日、予定工数や実績工数を毎日入力する運用にすれば、進捗報告の代わりになる。
　そして、チケット集計機能を使えば、ガントチャートやかんばんなどで、リアルタイムに進捗を確認できる。

(2)SVNコミット時に、コミットログに必ずチケットNoと修正理由を書く。
　例えば、「refs #10 リンクを直した」「fixes #11 パッチを取り込んだ」など。
　すると、チケットにSVNリビジョンの履歴が残るので、どんなコミットをしたのか、が分かるようになる。
　一度、この運用ルールに慣れてしまうと、チケットNo無しのコミットは修正理由が後で分からなくなるので怖くなる。

(3)Redmineバージョンはイテレーションに紐づけて、進捗が100％になったらリリースするように運用する。
　つまり、Redmineバージョンはビルドモジュールのリリース予定バージョンに対応付ける。
　これが小規模リリースになる。
　駄目な開発チームは、Redmineバージョンが工程や機能の単位などに分かれていて、リリースできるモジュールのバージョンに対応していないため、イテレーション管理がやりにくくなる。
　特にシステムテストや受入テストで厳格に障害修正を管理してリリースするプロセスでは、Redmineのロードマップがリリース計画に対応付けられていないため、リリース管理が運用しづらい。

(4)Redmineプロジェクトは、動くモジュール、リリース対象のコンポーネント単位に対応付ける。
　基本は、ブランチ(コードライン)単位にRedmineプロジェクトをアサインする。
　すると、ビルドモジュールに関わる修正やリリース作業などは全て、一つのRedmineプロジェクトで一括管理できる。
　駄目な大規模プロジェクトでは、工程単位にRedmineプロジェクトをアサインしているため、突発的なタスクをどこのプロジェクトにアサインしたらよいか迷うし、どのバージョンにどんな機能をリリースするのかというロードマップがあちこちに散在してしまって、Agileに開発しにくい。

Redmineを運用してみると、それぞれの機能は実はこういう目的のために作られていたのか、と改めて気づく時が多く、それがすごく楽しい。
Agile開発だけでなく、ソフトウェア開発で発生する作業をサポートする機能がとても面白い。

プロジェクトとブランチ(trunk)、バージョンとイテレーション、チケットとタスクカード/ストーリーカード、ワークフローとチケットのトラッカー、チケットのコピーと複製、関連チケット、作業分類と工数出力機能、ガントチャートとチケットの開始・終了日、チケットとSCM連携、サマリとチケットのステータス、ロードマップと変更履歴、ニュース、フォーラムのスティッキー、など数々の機能にはそれぞれ意味がある。

更に、RedmineもVer1.1に上がってもっと機能も改良され、数多のプラグインで機能拡張もできる。
色々試してみたい。