バグトラッカーの可能性

RedMineの管理単位について

• プロジェクト：問題区分
• トラッカー：追跡項目
• ステータス：状態項目
• カテゴリ：細分区項目
• 活動：作業概要項目

こう考えてみた、なるほどソフトウェア開発以外の管理にもつかえるな。今までなんで仕事が出来てたんだ？これは可能性が無限大だな。

活動のとこに開発作業の詳細項目を入れようかな、分析、設計、テスト、実装、リファクタリング。

Redmineの管理項目について

トラッカー

項目	概要
アイデア	やるかやらないか分からないアイデア。
課題	既存の仕組みの問題点。
要望	既存の仕組みへの要求項目。
機能	機能追加や変更などの開発作業。
問合せ	自部署以外からの問合せ事項。
タスク	サービスの運用・保守作業等。
構築	サービスの環境構築、設置作業。
トラブル	システム障害、ヒューマンエラー等。
バグ	発見されたバグや不具合項目。

ステータス

項目	概要
未着手	新たに登録されたもの、作業は未着手状態。
保留	対応や確認を待ってからでないと進められない状態。
着手済み	担当者が作業に着手している状態。
確認待ち	担当者の作業が終了した状態、確認の必要有り。
差戻し	確認の結果、修正や追加が必要となった状態。
終了	作業終了状態。(※含む確認の必要がないもの)
却下	採用されなかった提案や、修正する必要のない状態。

活動 : ※[列挙項目][作業分類(時間トラッキング)]

項目	概要
分析	問題事象に対するモデリング。
設計	問題解決に対するモデリング。
実装	問題解決への具体的行動。
テスト	問題解決の整合性確認。
設定	環境構築・保守・管理などの作業。
調査	問題対応に必要な、調査・リサーチ。
ドキュメント	仕様・設計・報告など、ドキュメント作成。
その他	上記以外の雑多な作業。

とりあえずこんな感じで設定を変更しようと思います。

チケットドリブンの可能性

Redmineの機能調査

カテゴリは、プロジェクト毎に設定する要求機能項目

• アプリの機能単位レベル。(例.設定インポート機能)
• 粒度が大きければカテゴリを分割すればいい。
• 自由度は高い、クラス単位の機能で設定してもいいかも。

チケットは具体的で細分化された作業の1単位

• プロジェクト間で移動することが可能である。
• カテゴリを変更することが可能である。
• トラッカーを変更することが可能である。
• 担当を変更することが可能である。(※他メンバーに引き継ぐ)

そして変更内容は全て履歴に表示される。

これはツールとして非常に強力だ、頭の中に沸いた小さなアイデアを膨らませて、結果に結びつけるプロセスを見える化してくれるツールなのだ。

ああぁ・・というか今まで必死にアプリケーションの改変履歴とか、テキストファイルにまとめていた苦労はなんだったんだ・・