Redmineバーンダウンチャート表示プラグイン

前回に続いて再びRedmineのプラグインを公開。

バーンダウンチャートはアジャイルの開発によく使用されているもので、進捗率に比べて、実際に進捗状況がより可視化される点が利点となっている。

burndown.png

Redmineにもいくつかバーンダウンチャートのプラグインがあるが、2系でしか動かなかったり、有償だったり、何よりも残工数の計算の仕方が気になる。

私自身のバーンダウンチャートの理解では、日々の進捗報告の際、そのタスクに対して、あとどのくらいかかかるかの見積りを行い、それを記録し、グラフ化して理想的な進捗と比較するというものである。残作業については、時間で計算するタイプと、ストリーポイントで計算するタイプのものがあるが、ここでは前者に絞る。

例えば、あるタスクに最初15時間を見積もっていたが、開始してみると思ったよりもボリュームや難易度が高くて、その日6時間かけたものの、残り9時間では住みそうではなく、あと12時間必要となったら、それを書き入れる。それを日々更新していくと、実際に手をつけているので、より正確になる。途中でスコープが追加になったとしても、それを残工数に組み入れる形になる。

これは進捗率と比べると優位性が明らかになる。進捗率は見た目、ほぼ完了となって90%とやったとしても、実際そこから完成に持っていくためには結構時間がかかる。そうすると、後もうちょっとが延々と続くことになる。そうすると実際それがいつ完了するのかが見えてこない。

ところが、世の中のツールを見ていると、必ずしも私の理解とは一致しない。他のRedmineのプラグインもチケットの進捗率をベースにしているものが多い。先の例でいうと、1日で進捗が20%だった場合、残工数は12時間と判断する。進捗90%までいくと、残り1.5時間となる。多くの場合プロジェクトでまとめて集計するため、全て合計して残り時間を算出し、それをグラフ化する。
正直これでは、進捗率を横軸に日にちを置いたグラフと変わらない。これを逆にして進捗率が上に上がっていくようにすればバーンアップチャートになる。
進捗率の変動をグラフにして見るのはありだろうが、これは正確に物事を反映しているといは言えない。先の例にあるように、90%から先進まないというケースもあり、そもそも進捗率などテキトーなものである。それに対して、残工数は、進捗率に比べて言い訳ができない。
全体の進捗であれば、Redmineで開発フェーズを親チケットととして切って、その下に各機能を子チケットとすれば、全体の進捗は自動的に計算されるので、これらのプラグインは不要である。

この計算方式は、Redmineと並んで有名なプロジェクト管理ツールのBacklogでも同じだった。残工数を入力するようなところはなく、こちらはむしろ、チケットが完了しないと、バーンダウンチャートに反映されないようになっている。これは結局、グラフを下に向けて、進捗の可視化を強化したものに過ぎない。

さらには、かけた工数を減らしていくような計算式もある。これは全くナンセンスである。単純作業で時間と成果が比例しているのであれば、事故がない限り、残り時間も正確に見れる。これは、むしろ仕事をしたかしていないかということにチェックの重点が置かれる。ところが、ソフトウエアの開発作業は創造的な作業であり、進めるうちに予期せぬことが多発するため、見積りを正確に行うことは不可能である。

正直、自分の理解が正しいのかどうか、かなり不安になってきて調べたものだ。

ということで、今回自分で作成した。
そして、他のプラグインが、プロジェクト単位で集計するのに対して、私が作成したものは、チケット単位で集計が可能である。もしそのチケットに子チケットがあれば、それら全て含めて集計する。つまり単一の機能開発単位でも見れるし、それを集めたグループ単位で見ることもできる。

重要なのは、以下の二つを必ず入力することである。
・初期の見積り(予定工数)
・期日
・残工数
 これは作業をした場合、日々入力する必要がある。
 進捗がなければ、入力する必要はない。前回の値がそのまま使用される。

標準では、残工数を入力するフィールドはないため、このプラグインを入れると自動的に、残工数のカスタムフィールドが追加される。そしてプロジェクトでこのモジュールを使用するようにすると、このカスタムフィールドをプロジェクトのチケットで入力可能になる。

チャートでは、指定チケット(子孫チケット含む)の予定工数合計を出発点として、期日に残工数が0になるように理想的な進捗工数のグラフが表示され、日々の残工数の入力を合計して、それをその間の日付に実残工数としてプロットする。

プラグインの入手先は、こちら。
https://github.com/dayan888/redmine_issue_burndown_chart

ここから開発の話:

開発においては、チャートの描画は、chartkickを使用した。これはRailsで簡単にチャートを扱えるもので(実際はJSで稼働)、いろんなチャートが作れるが、今回は複数のラインチャートのみを使用した。
ここまで行けば、あとは簡単だと思ってしまうのだが、いつものごとく周辺周りで異常に時間がかかった。最初新規の管理テーブルを追加しようと思ったが、チケット登録時にそこに残工数の入力を入れなければ行けないのが面倒なのでカスタムフィールドを使うことにしたが、プラグインのインストール時にどうやってテーブルに値を入れるか、またプロジェクト用のフックは用意されていないため、Rubyのクラス拡張ミックスインで元のProjectControllerには手を加えずに機能追加した。こういうあたりが時間がかかった。
あとは、developmentにしているのに、
Unable to autoload constant...のエラーが出て、unicornの再起動を気なくされ、これが起動に時間がかかり、本当はささっと試したいのだが、一つ一つ時間がかかり、生産性はガタ落ちだった。
結局のところ、この原因は、ProjectControllerの拡張のところと、Controllerのunloadableだった。前者は、マイグレーションのところでしか使わないので、その実装が終わったら、開発中はコメントアウトした。後者は、これまでおまじないとして何の疑問もなく入れていたが、文字通り、これが入っているとauto reloadはできないようだ。そこからはだいぶ楽になった。あとは、Railsの2系と3系の違いが多すぎで、2系で作られたプラグインはあまり参考にならないこと。
関連記事
スポンサーサイト

コメント

非公開コメント

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ