プロジェクトの健康管理

6869336880_31ae61b74a_z

チケットを時系列で見てみよう

enishのプロジェクトではRedmineを利用したチケット管理によりプロダクトの見える化をしています。

チケット量の現状の残量だけでなく時系列での増減を取得し複数の粒度で自動レポート化して利用しています。

ここでは自社プロダクトのレポートを参考に、どの様にチケットを時系列で見るかをお伝えします。

metrics1

こちらが弊社の誇る、スタンダードなチケット推移のパターンとなります。

  1. 黒が不具合
  2. 青が要望や調整のタスク

の残量を表しています。

 

1.リリース前

2017-02-28_17h56_21

リリース前はどのプロジェクトも判りやすく残量を減らしていく事になります。

特に”不具合”が綺麗に落ちていく状態が描けていれば一般的にプロダクトの終盤のパターンとしては大きな問題はありません。

このプロダクトで、リリース前のグラフの活用としては、リリース4週間の段階から不具合の減りが停滞した問題への対策として”軽微な不具合”を対処しないという判断をリリースの前週に判断しました。なので前週段階で”ガクン”とグラフが下落しています。これは実績ベースの遷移としては異常値ですが意図をもって終わらせるための対策を実施した結果、このようなグラフになっています。なので逆に言うと、なんの対策も行わずに、この様なグラフを他のプロジェクトで描いていた場合は要注意です。

また残数10件については極めて再現性が低い不具合なので大きな問題がない事も判っていましたので、このプロダクトは大きな問題もなくリリースする事が出来ました。

2.運用開始からバージョンアップ

2017-02-28_18h18_06

リリース後から皆様からのフィードバックを反映させながら、ロードマップに合わせた追加開発が行われます。このプロダクトではリリースした週から順調に要望がふえていきました。これは皆さまからのフィードバックをチケット化していた時期となります。その後にversion1.1と書かれたタイミングでversion1.1リリース予定の仕様が追加されました。そこで大きく要望、タスクチケットの残量が跳ね上がっています。

この様な状態は極めて健全な状態と言えると思います。皆様からのフィードバックと社内の追加要望をマージしたうえで最終的には6週間を利用して優先度の高い100件程の追加、修正を行った事がグラフから判ります。

そしてversion1.2と書かれたところでまた追加要望が整理されたのでチケットとして一気に発行されています。運用サービスは以降はこのタスク増減を繰り返しつつ、不具合を一定量以下に抑えてリリースを繰り返している状態が適正な状態と言えるといえます。

欲を言えば、このプロダクトでは最後に35件ほどの不具合を残してリリースした事を表していますが、技術的負債の軽減のために、20件程度を目標としてバグ修正を優先出来ていると更にベターであると言えます。

時系列で何が判るの?

過去の増減による実績値から「本当にリリースが可能か?」という予測がしやすくなる点、チームの本当の消化量、異常値が無いか(謎の増減、大幅減など)が起こっていないか、不具合が残されてタスクばかり消化されている(技術的負債が溜まりすぎていないか)という事が時系列で見る事で、とても判り易くなります。

そして今回ご紹介したプロダクトがスタンダードな「技術的な問題が起こっていない」プロダクトとして、他のプロダクトと比較しリリース時の残量や増減に異常が無いかの確認に利用する事が可能です。

ツール自体はgithubで公開していますので興味のある方はご利用ください! github-redmine-reportr

その他、レポートの他の機能の説明はQiitaのこちらの記事を参考にして頂ければと思います Qiita チケット計測のススメ