プログラマの思索

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

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

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

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

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

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

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

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機能もあるので、プロジェクトリーダーは常に活動の画面を見張っておく。

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

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

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

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

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

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

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

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でのバグ修正フローをアクティビティ図で書いてみた。

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

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