« Redmineでプロジェクトを見える化する | トップページ | ソフトウェア開発をIT化する »

2008/05/13

RedmineがExcelよりも素晴らしい点

Redmineの使い方は下記を見よ。

http://www.redmine.org/projects/show/redmine

【1】以下、Redmineを使った感想を書いてみる。

1-0.ガントチャートがリアルタイムに表示される。
 こいつに一番感動した。
 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。
 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。

 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。
 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。
 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。

Redmine_gantchart

1-1.SVNリポジトリとチケットが相互リンクできる
 これによって、チケット無しのSVNコミットは禁止できる。
 本番稼動しているソースはチケット無しの修正は不可。

Redmine_rivision


1-2.SVNリポジトリのソース差分表示が読みやすい
 リビジョンごとに差分箇所を色分けしてくれている。
 ソースインスペクションが楽しくなる。
 他の利点として、プロジェクトリーダーでなくとも、誰もがソースインスペクションしやすい環境が整ったこと。

Redmine_diff



1-3.複数のプロジェクトを親子プロジェクトで管理できる
 例えば、本番リリース後、SVNのtrunkで新規開発しながら、SVNのbranchで運用保守モジュールを管理している場合、管理するSVNリポジトリ単位にRedmineでプロジェクトを作る。
 これによって、新規開発時のチケットと運用保守のチケットを別々に管理できる。
 Tracと異なる大きな利点。

1-4.ステータスのデフォルト設定に「却下」「フィードバック」がある
 「却下」とは、バグ報告を修正せずに終了すること。
 例えば、「このバグは仕様なのです」みたいなケースだろう。

 「フィードバック」とは「差し戻し」。
 例えば、バグ修正して検証したら、実はバグが直っていなかった場合、PGへ差し戻しになる。

 上記2項目がデフォルト設定されているRedmineは、実に良く考えられている。

1-5.ワークフロー画面で、ユーザの権限ごとにステータスを設定できる
 これによって、開発者やテスト担当者は、指定されたステータスしか変更できなくなる。
 この機能は業務システムで良く出てくるのだが、汎用的に上手に作っている。

1-6.チケット同士の関係リンクに「関係する」「先行する」がある
 例えば、新規機能を開発するチケットへ、関連するバグ修正のチケットを「関係する」リンクにする。
 例えば、機能Bを作る前に共通機能Aを開発する必要があるなら、BのチケットへAのチケットを「先行する」リンクをはる。
 これによって、ガントチャートのFS関係のようにできる。

1-7.活動の画面で、開発作業のログを見れる。
 SVNコミットログやチケットの記入内容などが表示される。
 RSS機能もあるので、プロジェクトリーダーは常に活動の画面を見張っておく。

Redmine_activity

1-8.カレンダーには、チケットの開始・終了日やマイルストーンを表示する。
 チームメンバー全員にプロジェクトのゴールや各自のミッションを説明するのに役立つ。

1-9.ロードマップは、バーンダーンチャートそのものだ。
 バージョンにマイルストーン名を入力しておくと、バージョンごとのチケットの一覧と進捗のパーセンテージを表示してくれる。
 プロジェクトリーダーは普通は、ロードマップから、残作業のボリュームを推し量り、対策を立てるだろう。

Redmine_roadmap

1-10.レポート(サマリ)は、その時点のプロジェクトのソフトウェアメトリックスそのものだ。
 レポートには、トラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに、チケットの状態(未完了・完了)の集計結果を表示する。
 プロジェクト終了後、この集計結果からバグ経験曲線などを作ることもできるだろう。

Redmine_report

1-11.経過時間の画面で、実作業時間を表示できる。
 チケットの予定工数(見積工数)と経過時間(実績工数)から、工数見積の精度を上げることができる環境になる。

Redmine_worktime


【2】チケット駆動開発の手順

2-1.チケット記載の前準備

2-1-1.バージョン
 マイルストーンと同値。
2-1-2.カテゴリ
 システムの機能別の単位。
2-1-3.トラッカー
 チケットの種類。
 バグ修正、仕様変更、仕様追加、新機能開発など。
2-1-4.リポジトリ
 SVNを指定する。
 リビジョン単位のコミットログが一覧表示されるように、チームでフォーマットを統一しておく。

Redmine_repository

2-2.PLがチケットを新規作成する
 ステータスは「新規」から始まる。
 WBSから更にチケットへ作業を分割し、担当者にアサインする。
 バージョン、カテゴリ、トラッカーの指定が重要。この区別でチケットの状態を集計するから。

2-3.開発者がチケットを更新する
 ステータスは「担当」になる。
 気づいた点は、チケットの注記欄へどんどん追加していく。
 合わせて、進捗(%)や経過時間も毎日入力してもらう。

2-4.開発者がチケットを閉じる
 SVNコミット時に、チケットにSVNリビジョンがリンクされる。
 開発又はテストが完了したら、ステータスは「実装完了」「検証完了」になる。

2-5.PLはチケットの中身を精査する
 そのチケットの内容を本番リリースしたら、ステータスは「終了」になる。
 もし、実装のやり直しがあれば、ステータスは「フィードバック」になる。
 新規チケットを更に作り、新規チケットに「関連する」リンクを張る場合もあるだろう。

 ITプロジェクト管理が難しい状況は、当初のWBSにないチケットがどんどん増えていく時だ。
 しかも納期が決まっているならば、たとえメンバーの人数が増えようとも、消化できるチケットの枚数に必ず上限はある。
 チケットの状態管理がチケット駆動開発の一番の肝なのだ。

2-6.チケットの状態をPLが見張っておく
 下記の画面で、プロジェクトの進捗をリアルタイムに確認できる。

2-6-1.活動
 チケット更新やSVNリビジョンを表示。

2-6-2.ロードマップ
 バージョン単位のチケットの状態と進捗パーセンテージを表示。

2-6-3.ガントチャート
 遅れていると赤字で表示されるので、MSProjectよりも分かりやすい。

2-6-4.カレンダー
 チケットの開始終了日やマイルストーンを表示。

2-6-5.レポート(サマリ)
 トラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに、チケットの状態(未完了・完了)の集計結果を表示

2-6-6.経過時間
  実績工数(単位:h)をトラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに表示。

【3】Redmineでのバグ修正フローをアクティビティ図で書いてみた。

Redmine_flow

 プログラムに例えると、
「却下」は GO TO EXIT。
「フィードバック」は、Exception発生でRollbackしたケース。

 上記の図では、3人のアクターで7つのステータスが入れ替わる。
 だから、結合テスト以降のバグ修正フローを管理するのはすごく難しいのだ!!

|

« Redmineでプロジェクトを見える化する | トップページ | ソフトウェア開発をIT化する »

Redmine」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/41199414

この記事へのトラックバック一覧です: RedmineがExcelよりも素晴らしい点:

« Redmineでプロジェクトを見える化する | トップページ | ソフトウェア開発をIT化する »