test

2011/08/30 Tue redmine

[] 運用について

注意事項

以下の手順はあくまでも想像世界の話なので、運用にあった使い方を推奨します。

旨いことシステムとして組み込むことが出来れば、何事にも代えがたい作業が出来るでしょう(誇大広告)。

他にいい案があったら、教えていただきたいです。

手順

ある事象が発生したときに以下の手順で事象の行き先(処置)を決定します。

判断基準処置
期限/優先度のある情報/作業チケット
更新される情報/作業wikiもしくは文章
全体に周知すべき情報/作業ニュース
その他フォーラム

処置がチケットの場合

はじめに

チケットに事象が流れた場合は、作業完了の基準(or期日)を明確にして起票してください。

  • 専任の場合
    • 担当として振ることが出来る場合は、担当者を決めておくのがよいです。
  • 複数人の場合
    • 複数人にわたる場合はウォッチャーに追加してください。
    • 担当漏れを発生させないために以下の手順を取ることをお勧めします
      • 子チケットを発行し、それぞれに担当者として割り振る
      • 回覧形式をとり、担当者を持ちまわる
        • チケット発行時か作業割り振り時にだれがどの順序で持ちまわるかをチケットに記載する
        • チケット内容を判断し、自分の作業ではない場合は次の人にまわす
進捗を記録する

状況が変化した時点で、チケットのステータスを変更してください。変更すべき箇所は以下の通りです。

  • ステータス
  • 進捗

基本的に、以下のような進捗となるはずです。ただ、プロジェクトにより、基準を決めておくと、作業しやすくなります。

ステータス進捗
新規0%
処置中100%ではない
解決80%〜100%
テスト80%〜100%
終了100%
対応/却下100%

進捗を記録することにより、プロジェクトの進捗管理もできます。

進捗を記録すると同時に、時間も記録すると、プロジェクトの評価等にとても有用なので、強く推奨します。


作業の分割

チケットの粒度が大きいと判断した場合に、作業を分割します。

判断基準処置
数週間要する若しくはプロジェクトとなった場合新規プロジェクトを作成
複数人に分割しなくてはならない場合子チケットを発行する
派生したり、何かに影響を受けた場合別チケットを発行し、関係するチケットに元のチケット番号を入力する
ある程度の指標があり、期日が明確となっている場合バージョンを作成し、終わらせなくてはならないチケットを関連付ける
作業の分類

分類は以下の順序と考えると綺麗にまとまる可能性が高いです。

関係するチケットは必要に応じて使うこと。


処置がwikiもしくは文章の場合

wiki もしくは 文章 にて新たなページを発行する。

名称はできるだけわかりやすい名前にすること。

wiki と 文章 どちらにするか判断がつかない場合は、以下の順序で処置を決める

判断基準処置
所有者で分類する場合文章
変更履歴を残す場合wiki
変更履歴を残さない場合文章
Wikiの場合

Wikiの場合は文章やチケットからの派生も可能で、ページへのリンク

リンクを経由してページを作成してください。





開発の場合の設定

トラッカー
  • デグレード
    • 対応する必要がなかった作業とか。主にバグからの移動がメイン
    • 発生件数とか取りまとめるのにあったほうがよい
  • バグ
    • 主に不具合。各作業の子チケットとして起票する
    • 発生件数とか取りまとめるのにあったほうがよい
  • 要望
    • 客先からの要望について。それに付随するもの
      • 細かいものはそのまま子チケットもしくは関係するチケットとして対応
      • 大きいものになると、バージョンで取りまとめて、要望は終了とする
      • さらに大きい案件は、サブプロジェクトとして対応
    • お金にもかかわることなので取りまとめれるようにする
  • 作業
  • 疑問
    • それぞれの工程で出た質問とかを分類するために利用
  • 調査
    • 事前調査や、環境構築などのチケットを格納する
  • 打合せ

注意: 多くすると意味不明になるので、頻繁に必要性を感じたら作るレベルでよいと思います。


カテゴリ

不明な場合、以下の切り口で分類すると便利かもしれない。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/indication/20110830/1314724402