redmine勉強会に参加してきました−実践redmineカテゴリ設計にご用心
redmine勉強会に参加してきました。
会場を提供してくれたトライコーン株式会社ありがとうございます。
実は、自分の会社から１０分ぐらいというご近所さん。今回はとっても楽でしたー
不謹慎にも、次回のredmine勉強会もトライコーンさんで・・・なんて期待をしてしまいます。
とりあえず、自分のメモをコピペ。
意外と長いので、セッションごとに分割します。
最初のプレゼンは、id:yandodさん
資料は、こちらです
しっかし、プレゼンの様子も動画で提供されるし、資料も公開されているから細かいメモはほとんど不要ですね。
でも、昔の癖が抜けないので細かいメモがたくさん。
たまたまこのページにたどり着いてしまった人は他の人のページをみましょう（苦笑）。
はじめに
- 簡単な紹介はたくさんある
- 実際の利用例は見ててこない
- redmineを使うとどうなるのか
- 世論を形成する気概で
redmineの基礎
- 柔軟さがウリのバグトラッキングシステム
- Ruby on Railsで開発されていて拡張も可能
- 勢いだけならすでにナンバーワンBTS
チケットの分類について
- チケットに対する分類が複数存在
- 分類のレベルによって機能の振る舞いがことなる
- カスタマイズができるのが仇となるケース
- 作業の実態とチケットの粒度を合わせるのが肝
- 操作方法よりも重要なポイント
チケットの分類
- プロジェクト
- トラッカー
- バージョン
- ステータス
- カテゴリ
- 作業
チケットの分類の例
- たとえば、コーディング、テスト、レビューなどをどこにいれますか？
- 会場でも意見がまちまち
豆知識
※プロジェクト書庫に保存という機能があって、一覧から一時的に消すことができる
プロジェクト
トラッカー
- 作業ごとのワークフローを定義
- 報告者が登録し、管理者が割り当て、作業者が閉じる・・・など
- 標準では管理者・開発者・報告書者・non member・anonymousが定義されている
- チャート設定が面倒
ステータス
- トラッカーで利用されるチケットの状態
- 標準では、新規・担当・解決・フィードバック、終了・却下
- ステータスを増やす場合は各権限での運用を考慮して設定しなくてはならない
- トラッカー・ステータスは全プロジェクトに反映される
カテゴリ
- チケット登録時に選択するラベリング
- プロジェクト内で自由に追加できる
作業
- チケット経過時間を登録する際の分類
- 設定はシステム全体かつ、管理者のみ
- レポートにしか現れない分類
- 時間に直接対応しているが、使いにくい
- デフォルトは、設計作業・開発作業
分類の戦略
- あとでどの画面でどのように作業を確認したいか
- 集計、表示などの機能を一通り確認
- 後で見れるように入力しないと意味がない
まとめ
- トラッカーはどの画面でも現れる。ただ、権限設定とセットとなっているので管理には注意が必要
- ステータスは、意外と表示される場所が少ない
- 作業はサマリにしか表示されない
- 全プロジェクトで共有されるとラッカー、活動はダイナミックな運用には向いていない
- バージョンはプロジェクト毎に自由に設定でき、なおかつロードマップを利用されるために欠かせない分類
- ステータスはあくまで状態でしかなく、後の分類には利用不可能
- カテゴリは、プロジェクトごとに柔軟に運用可能
- プロジェクトごとに作業形態によるちがいはバージョンとカテゴリで吸収するのがよい
内容はとっても参考になりました。
ロードマップが重要というのは、自分の感覚にもあいました。
自分は新しいプロジェクトを作ると、「ターゲットのないチケット一覧」というカスタムクエリを作る習慣があるぐらいなので（笑）。
今回のプレゼンは、自分がチケットの分類で迷ったときに指標となりそうです。
自分がredmineで迷ったときは、これまでプログラマの思索の記事を繰り返し読んでいたのですが、今後はこのプレゼン資料も繰り返して読むことになると思います。
