λ Trac TimingAndEstimationPlugin + Scrum Burndown

trac + TracBurndownプラグインでスクラム開発のすすめ を参考にしつつ、 最新の Scrum Burndown は cron での設定が不要なので、基本的には以下の作業をそれぞれのプラグインに対して行った。

• Subversion で最新ソースを取得
• sudo python setup.py install でインストール
• [components] に hogehoge.* = enabled と書く
• tracadmin . upgrade
• apache 再起動

tracadmin . upgrade したところで、ラベルの文字列が trac.ini に含まれるようになっていた。そこのところを日本語化する。hoge.label 以外のところの数値とかはそのままで。

[ticket-custom]
...
billable.label = 集計対象?
...
estimatedhours.label = 作業時間見積(hour)
...
hours.label = 今回の実作業時間
...
totalhours.label = 合計実作業時間

Scrum 向けなので、運用は以下のような流れになるはず。

• チケット登録時に 「作業時間見積」 を入れる。いつやるかはこの時点では決めなくてもいい。決めてもいい。(決めたものはマイルストーンの設定をする)
• スプリントの開始時に、どれをやるか決めてマイルストーンを設定。「Start Milestone」を押して作業開始!
• チケットをやっつけたら、「今回の実作業時間」 に時間を入れる。「合計実作業時間」の方は勝手に加算される。
• 状況が変わったら、「作業時間見積」を適宜変更する。

時間の入力には、小数が含まれていても良い。「今回の実作業時間」にはマイナスの値を入れて入力間違いの修正をすることもできる。

しかしやろうと思ってから、ほぼ1ヶ月経過してしまったなあ。

λ Trac 重要度の設定 改

重要度 (severity) ... 技術面の指標 をより明確に表現してみるテスト

• 常にシステム停止
• 稀にシステム停止
• 不整合が拡大中
• 不整合が常に表面化
• 不整合が稀に表面化
• 不整合は存在しない

システム停止の件は Bug Triage Meeting - Severity & Priority にあるのを もってきた。 その続きについては、プログラムは動き続けられるという状況だとしても、 バックエンドにデータベースが存在するシステムの場合「データの不整合をどう修正するか」がコードの修正と密接に連携する、 ということで主にデータの不整合に注目してみた。

不整合が拡大中…てのは状況としてはシステム停止よりも悪いことの方が多いのだが、そこは優先度 緊急、ということで。