Issue Tracking Systemの利用パターン - こくぼ＠Everything is the experience.
ツールは手段です。ツールを使用するには目的が伴うのが普通です。 本記事では目的に応じたIssue Tracking Systemの使い方を示したいと思います。 Issue Tracking Systemを導入する目的 Issue Tracking Systemを導入する目的はなんでしょう？ 要件を管理したい タスクを管理したい 報告書の元ネタにしたい 情報を共有する場にしたい 進捗を管理したい 課題を管理したい いろいろ挙げられると思いますが、ここでは次の3点に絞ります。 要件管理 要件 + タスク管理 課題管理 順番に見ていきます。 その前に前置き 要件という用語はユーザーストーリーとして置き換えてもらっても構いません。 ざっくりと次のようなイメージをしてもらえば良いでしょう。 要件(ユーザーストーリー) お客さん*1が望んでいること、お客さんに提供する価値 タスク 要件を実現するために
前略、private issue 使ってみました。あるいはITSの黒魔術とは何か - ハードコイルド・ワンダーランド
RedmineのtrunkにPrivate Issueの機能が追加されたとのことなので自分のローカルでデモしてみた。 実際のリリースはv1.2.0が予定されているようだ。 プロジェクトのメンバーは以下。 SIer1 SIer2 Dev1 Dev2 Cust1 顧客1人にSIer(笑)2人、丸投げされた開発会社2人という、なんともきな臭い人数構成にしてみた。 小規模のWFとか、大体どこもこんな感じなのではないだろうか。 Private Issueの権限割り当て Private Issueに関連する権限割り当ては 管理-ロールと権限 からおこなう。 各ロールごとに設定するのは以下の２点 プライベートチケットを表示するか チケットをプライベートに設定できるか 表示できるチケットで「すべてのチケットを表示」を選択した場合は、Private Issueであるかどうかに 関わらずすべてのチケットを表示
2009-07-08
RedMineの管理単位について プロジェクト：問題区分 トラッカー：追跡項目 ステータス：状態項目 カテゴリ：細分区項目 活動：作業概要項目 こう考えてみた、なるほどソフトウェア開発以外の管理にもつかえるな。今までなんで仕事が出来てたんだ？これは可能性が無限大だな。 活動のとこに開発作業の詳細項目を入れようかな、分析、設計、テスト、実装、リファクタリング。 トラッカー 項目 概要 アイデア やるかやらないか分からないアイデア。 課題 既存の仕組みの問題点。 要望 既存の仕組みへの要求項目。 機能 機能追加や変更などの開発作業。 問合せ 自部署以外からの問合せ事項。 タスク サービスの運用・保守作業等。 構築 サービスの環境構築、設置作業。 トラブル システム障害、ヒューマンエラー等。 バグ 発見されたバグや不具合項目。 ステータス 項目 概要 未着手 新たに登録されたもの、作業は未着手状
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TracとRedmineの比較
