(cache) Redmine入門 - バグ管理システムとしての使い方 | プログラマーズ雑記帳

Redmine入門 - バグ管理システムとしての使い方

Redmine入門 Redmine 使い方ガイドチケット

Redmine の基本的な使い方であるバグ管理システムとしての使用法を説明します。

ワークフロー

Redmine を使用するためにはワークフローを理解する必要があります。ワークフローというのはチケットのステータスの変化の流れで、トラッカーとロールによって変わってきます。

ただし、デフォルトの設定ではバグ、機能、サポートの 3 つの機能とも同じフローとなっています。

このワークフローは通常、システム管理者しか確認できません。
Redmine インフォメーションプラグインがインストールされていれば、 [情報] → [ワークフロー] のメニューからワークフローを表示させることが出来ます。また、システム管理者でも表でしか確認できないので、流れを理解するのはなかなか難しいですが、プラグインではさらにワークフローを図で表示することもできます。
参考書やサイトにもフロー図が載っているものは多いですが、このプラグインを使えばトラッカーやスタータスを追加したとしても、現在の Redmine の設定でのワークフロー図をみることが出来ます。

以下は、デフォルトでの開発者と報告者のワークフローです。 (管理者はすべてのステータスに変更可能です)

フローの矢印の方向にしか変更は出来ません。例えば、開発者は [進行中] と [解決] 間はどちらにも変更できますが、いったん [終了] にすると他のステータスに変更できなくなります。

バグ管理の流れ

バグ管理の流れを例を挙げて、説明したいと思います。
例としてはロールのところであげた Foo システムのように複数人で開発しているプロジェクトを考えます。ただし、シンプルにするため、サブプロジェクトはないものとします。サブプロジェクトがある場合はチケットの移動なども行う必要があります。

基本的な流れは次のようになります。

1. バグ報告

開発者、テスタ等

バグを見つけた人がバグ報告を行います。バグ報告は報告者のロールやメンバ外のユーザーでも可能です。

バグ報告はトラッカーを [バグ] としてチケットを作成します。

対応プログラムのプロジェクトを開く
[新しいチケット] を選択
トラッカーを [バグ] に設定(デフォルト)
その他の必要項目を記入し、 [作成]

基本的に入力する項目は [題名] と [説明] です。
開発メンバーの場合はその他の担当者などの項目も分かるものは設定しておきます。
逆に [対象バージョン] は修正するバージョンなので、開発メンバーでなければ入力しない方がいいでしょう。

これらの項目は後から編集(チケットの更新)することが出来ます。ただし、題名や説明などを変更する方法は若干分かりづらいです。

2. 担当者の割り当て

管理者など

チケットを追加された後、プロジェクト管理者は担当者が未定のままの場合は担当者を推測します。
Redmine でチケットの [更新] から担当者に推測した担当者を設定します。担当者など一項目の変更であれば、チケット一覧の右クリックメニューからでも変更できます。

Redmine の気がつきにくい機能 | Redmine.JP Blog

この割り当ては管理者でなくてもかまいません。例えば、バグは大抵 GUI として現れるので、 GUI 担当者が原因箇所を特定して割り振りを行うといった具合です。
ただし、この割り振りを行う人は後の回で説明するメール受信の設定でプロジェクトのすべての変更を受け取る設定にしておく必要があります。

2B. 報告を却下

管理者

バグと思われたものが、環境設定のミスとかだった場合や「バグではなく仕様です」と言い張る場合(^^;) にはチケットを却下します。
この場合には、ステータスを [却下] に変更します。

[却下] のステータスは開発者や報告者のワークフローには出てきません。これはバグ報告を [却下] できるのが管理者だけであるためです。

3. 担当者の決定、修正作業の開始

担当者(開発者)

担当者として割り当てられるとその担当者にメールが届きます。担当者候補は自分の作業かどうかを確認して、修正作業を開始します。

チケットの [更新] から以下の項目を変更します。

ステータスを [進行中]
開始日を変更
期日
予定工数
対象バージョン

Redmine の昔のバージョンでは [進行中] のステータスは [担当] でした。そのころにデータベースの作成を行っている場合はステータスは [担当] になっているかも知れません。

実際には、担当が自分でない場合や調査後、バグでないと判明した場合は管理者に連絡して 2 の状態に戻したり、予定工数だけ報告して、開始はプロジェクト管理者の Go がでてからという手順を踏むこともあります。

4. 修正作業

担当者

担当者はバグの修正作業中は定期的に以下の項目を設定します。

進捗 %
作業時間の記録
活動

ここでの更新はタスク管理や工数管理に利用している場合で、単にバグ管理として使うだけであれば、経過の入力をしなくてもかまいません。

5. 修正作業完了の報告

担当者

担当者は修正作業が完了したら、作業が完了したことを Redmine で報告します。
チケットの [更新] からステータスを [解決] に変更します。

6. バグの修正確認

チケット作成者(バグ報告者)など

チケットのステータスには [解決] と [終了] の 2 つがあり、紛らわしいですが、チケットは [解決] のステータスでは終了したものとして扱われません。
[終了] または [却下] ステータスのみ、チケットがクローズしたとみなされます。修正内容を確認して [解決] を [終了] にする必要があります。

チケットを [終了] にする人はいくつか方針があると思います。

開発者が行う([解決] ではなく、直接 [終了] にします)
プロジェクトリーダー(管理者)が行う
チケット作成者が行う

私としては、バグ報告者と修正担当者が違う場合には対象となるバグに対して認識が違っている可能性があるので、基本的にバグ報告者が確認して [終了] にするのがいいのではないかと思います。

ただし、そうした場合、デフォルトの設定ではプロジェクトメンバーではない人(Non member)がチケットを作成すると、ステータスを変更することは出来ません。そのため、 Redmine の管理ページから Non member に [チケット作成時の追加の遷移] として以下の遷移を追加します。

[解決] から [終了]
[解決] から [フィードバック]

流れの例ではバグ報告者がチケットを [終了] にするようにしています。
チケットの作成者は作成したチケットの変更に対して自動的にメールを受け取るようなっているので、チケットが [解決] に変更された通知も受け取っています。

6B. フィードバック(差し戻し)

チケット作成者(バグ報告者)など

[フィードバック] の用語も分かりづらいですが、差し戻しの意味になります。
担当者が [解決] にした後、修正対象や結果がバグ報告者が思っていたのと違うということになった場合にチケットのステータスを [フィードバック] に変更します。

[フィードバック] になったものは、担当者の修正作業に戻り、3. から再度修正を行うことになります。

終了時に進行率を 100% にする

チケットの [終了] 時には進行率を 100% にする必要があります。これをしていないとロードマップでバージョンの進捗がきれいに表示されません。
ただ、意外とこれを忘れたりして、進捗率を直すだけでメールが飛んで悪いなと思ったりします。

こんなときには Issue Extensions プラグインです。チケットを終了にした時に、進行率も自動で 100% にしてくれるようにできます。
このプラグインは他にも関連するチケットを指定しやすくするなど、あると便利だなというチケット関連の機能を提供してくれます。