DQ and RFC process

From UG

(Difference between revisions)
Jump to: navigation, search
(DQ)
(Details of DQ workflow)
Line 67: Line 67:
== Details of DQ workflow ==
== Details of DQ workflow ==
-
===   RFC ===
+
For convenience it is broken into 2 sub phases: DQ1 and DQ2.
 +
 
 +
=== DQ1 RFC ===
* purpose: create mantis
* purpose: create mantis
Line 75: Line 77:
* create mantis record with initial available info for Change Request or Non Urgent Bug
* create mantis record with initial available info for Change Request or Non Urgent Bug
-
===   IBA ===
+
=== DQ1 IBA ===
* '''purpose:''' (Biz Analysis or Bug Report)  
* '''purpose:''' (Biz Analysis or Bug Report)  
Line 83: Line 85:
* Conduct and post into mantis L0 BA (requirements) or Detailed Bug Report
* Conduct and post into mantis L0 BA (requirements) or Detailed Bug Report
-
===   ISA ===
+
=== DQ1 ISA ===
* '''purpose:''' (Initial Sys Analysis)  
* '''purpose:''' (Initial Sys Analysis)  
Line 104: Line 106:
* set L0 emh/emhR
* set L0 emh/emhR
-
===   PTR ===
+
=== DQ1 PTR ===
*  (Product Team Review)  
*  (Product Team Review)  
Line 117: Line 119:
* post notes as required
* post notes as required
-
===   FSA ===
+
=== DQ1 FSA ===
4)  (Full System Analysis) // AG
4)  (Full System Analysis) // AG
Line 125: Line 127:
* create SOW
* create SOW
-
===   Dev,  QA, SIT, UAT, T2S, Rel ===
+
=== DQ2 Dev,  QA, SIT, UAT, T2S, Rel ===
5) ph = DQ (Dev/QA/SIT/UAT/T2S/Rel phases of RFCs and Non Urgent Bugs) // Perry
5) ph = DQ (Dev/QA/SIT/UAT/T2S/Rel phases of RFCs and Non Urgent Bugs) // Perry

Revision as of 20:40, 6 June 2012


Contents

Info

This wiki is about RFC and DQ methodology.

Problems with old process:

  • no specs/SA in many cases
  • developers had no clear plans
  • we had no idea what will be completed when (except urgent tasks)

Glossary

  • L0 (L zero) = initial/rough;
  • L1 = full
  • RFC = Request For Change
  • DQ = Development Queue

Top level Jag Soft Dev Workflows

We have the following top level workflows

  • Projects (Prj)
  • Urgent Bugs (UB)
  • Development Queue (DQ) - any work that is subject to CT2 Release and is not covered by Prj and UB
  • Support (Sup)
  • Misc (MIsc)

See also "wf" mantis field.

IS

Prj, UB, DQ have different initial phases but common end - IS (Implementation Sequence):

  • Dev
  • QA
  • SIT
  • UAT
  • T2S
  • Rel

UB Phases

  • BR - bug report
  • #IS

Proj

  • BA
  • SA
  • Est
  • #IS

DQ

DQ1:

  • RFC
  • IBA
  • ISA
  • PTR
  • FSA

DQ2

Details of DQ workflow

For convenience it is broken into 2 sub phases: DQ1 and DQ2.

DQ1 RFC

  • purpose: create mantis
  • owner: Alex

Details:

  • create mantis record with initial available info for Change Request or Non Urgent Bug

DQ1 IBA

  • purpose: (Biz Analysis or Bug Report)
  • owner: Denise

Details:

  • Conduct and post into mantis L0 BA (requirements) or Detailed Bug Report

DQ1 ISA

  • purpose: (Initial Sys Analysis)
  • owner: Alex

Details:

  • review periodically RFC records (say 5 a week)
  • meet to discuss: Alex, AG, Sasha, Denise, etc (all together or in sub groups) (group might depend on the task)
  • split / combine as required
  • tweak summary/desc as required
  • Mantis Description field should have 3 sections:
    • Problem/Request
    • Solution
    • SOW link
  • identify what is large enough to be classified as a project and tag as such
  • discuss solution
  • conduct and post into Mantis L0 SA
  • set Dv (to "any" if possible or to specific dev)
  • set L0 emh/emhR

DQ1 PTR

  • (Product Team Review)
  • owner: ???

Descr:

  • review periodically tasks that completed RFC-SA (say 5 a week)
  • meet to discuss requirements/solution/emh (Marc, Denise, Alex, Perry?)
  • reject/approve (by Marc)
  • set T
  • post notes as required

DQ1 FSA

4) (Full System Analysis) // AG

  • conduct L1 SA
  • consult KU, SA, developers, BA as required
  • create SOW

DQ2 Dev, QA, SIT, UAT, T2S, Rel

5) ph = DQ (Dev/QA/SIT/UAT/T2S/Rel phases of RFCs and Non Urgent Bugs) // Perry

  • conduct weekly DQ meetings to: a) review previous week's progress b) create plans for next week
  • review previous week's progress (post mortem):
    • sort by due=wYY
    • go task by task and see status/ph it is in (most must pass QA and be in SIT/UAT)
    • send weekly review (post mortem) to all managers (Marc, KU, Ale, Den)
  • create plans for next week:
    • identify how many mh available from each dev next week
    • sort tasks in DQ by T and create plan for each dev:
      • assign mantis to dev
      • set due mantis field to wXX where XX is week number
    • send weekly plan to all managers (Marc, KU, Ale, Den)
  • coordinate SIT/UAT and Releases of DQ
Personal tools