バージョンに紐付いたすべてのチケットが終了ステータスになれば、モジュールをリリースできる。リリースした内容は、ニュースへ書いて公開する(図23)。
リリースしたモジュールは、ファイル欄にダウンロード用モジュールとしてアップロードする。これによって、ユーザーはリリースモジュールをダウンロードできる(図24)。
リリース後のチケットは、集計結果として表示される。筆者が重宝するのは、サマリ、リポジトリ統計、変更記録の3つの機能だ。
サマリは、トラッカーやバージョン、カテゴリなどの単位でチケットの未完了・完了・合計数を一覧表示する。虫眼鏡のアイコンをクリックすると、ステータスごとにチケット数を集計表示する。
図25の表は、開発チームの実績そのものといえる。進ちょく報告の元ネタとして使えるだろう。
あるいは、図25の表から過去のバージョンのどれにバグが多かったのかをうかがい知れる。次のバージョンに向けて、バグを減らすにはどうすればよいかなどのリスク管理に使える。
変更記録は、リリースしたバージョンのロードマップ一覧(図26)。リリースしたバージョンには、どのチケットが対応されたのかを追跡できる。ChangeLogやリリースログとして使える。
リポジトリ統計は、ソースリポジトリの月別のコミット回数、変更回数などを表示する。プロジェクトの開発の活発具合や、プロジェクトに対する開発者の貢献度が分かる(図27)。
レポートは、実績工数をバージョンや期間などでクロス集計して表示する(図28)。
バージョンやカテゴリ単位で、期間ごとの実績工数を表示すれば、「このバージョンやカテゴリで工数が大きすぎるのはなぜか?」という問題に気付き、今後のリスク管理として使える。
ユーザーからの障害報告や改善要望は、簡易な掲示板の機能を持つRedmineのフォーラムへ収集するように運用すればよいだろう(図29)。
障害報告や改善要望だけでなく、システムの使い方に関する質問も、フォーラム内部で回答するなどの運用も可能である(図30)。
筆者は、リリース後に開発チームでKPT(振り返り)した後の結果をフォーラムで残すようにしている。そうすることでメンバーはいつでも過去のKPTを読み直すことができ、何かの気付きを得てくれるだろうと考えている。
システム運用やリリース作業、実装技術などのノウハウは、Wikiでまとめて情報共有すると良いだろう(図31)。Wikiの記法については「Redmine.JP | wikiの記法は?」参照。
Copyright © ITmedia, Inc. All Rights Reserved.