Ticket workflow - Bug

Redmine

'Bug' Ticket's specification sheet is bvelow;

Status

    1. new *1
    2. assigned *2
    3. resolved *3
    4. testing *4
    5. feedback *5
    6. verified *6
    7. rejected *7
    8. closed *8

Role

    1. Leader
    2. Developer
    3. Reporter


footnote

*1: 新規

*2: 担当中

*3: 解決

*4: 検証中

*5: フィードバック(差し戻し)

*6: 検証完了

*7: 却下

*8: 終了

Ticket model (Redmine tracker model)

Redmine

My Ticket model (Redmine tracker model) characteristics are like below;

  1. Implementing the ITIL*1 framework
  2. 7 types ticket
    1. Common
      1. QA
      2. ToDo
    2. For Service Desk
      1. Incident
      2. RFC *2
    3. For Release Management
      1. Release
    4. For Developer Team
      1. Bug
      2. Change
  3. Escalation Flow
    • When an incident is not a known QA, it is changed to QA ticket(Change ticket type). Of course, you can create a RFC ticket without creating a incident ticket. *3
    • When an incident is a RFC, it is changed to RFC ticket(Change ticket type). Of course, you can create a RFC ticket without creating a incident ticket.*4
    • CAB*5 decides to accept or reject each RFC ticket. *6
    • A 'Change' ticket is created as a child of an accepted 'RFC'. Developer Team Leader breaks down a 'Change' ticket and create some 'ToDo' tickets as its children. *7
    • When an incident looks like a bug, you can create a Bug ticket as its child. Several customers' incident tickets may be linked to a same bug ticket. *8


Table of contents

  1. Introduction
  2. Ticket model (Redmine tracker model)
  3. Ticket workflow
    1. ToDo
    2. QA
    3. Bug
    4. Change
    5. Incident
    6. Relase
    7. RFC
  4. Project Tree Model

footnote

*1: Information Technology Infrastructure Library。ITサービスマネジメントにおけるベストプラクティス。

*2: Request for Changes。仕様変更、機能追加の要望を受け付けます。

*3: 既知のQAでない場合はチケットの種類をインシデントからQAに変更します。最初からQAチケットを作成するのもありです。

*4: 変更要求の場合はチケットの種類をインシデントからRFCに変更します。最初からRFCチケットを作成するのもありです

*5: Change Advisory Board. 変更諮問委員会

*6: 変更諮問委員会にて各RFCを受付けるか拒否するか決定します

*7: 変更許可が下りたRFCについては、その子として変更チケットを起票します。開発チームリーダはさらに作業を分解し変更チケットの下にToDoチケットをぶらさげます。WBSのイメージ。

*8: インシデントがバグの可能性があるときは、その子としてバグチケットを起票します。各お客様のインシデントがひとつのバグチケットに紐づくことが想定されます