DQ and RFC process
From UG
(Difference between revisions)
(→DQ) |
(→Details of DQ workflow) |
||
| Line 67: | Line 67: | ||
== Details of DQ workflow == | == Details of DQ workflow == | ||
| - | === | + | 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 | ||
| - | === | + | === 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 | ||
| - | === | + | === DQ1 ISA === |
* '''purpose:''' (Initial Sys Analysis) | * '''purpose:''' (Initial Sys Analysis) | ||
| Line 104: | Line 106: | ||
* set L0 emh/emhR | * set L0 emh/emhR | ||
| - | === | + | === DQ1 PTR === |
* (Product Team Review) | * (Product Team Review) | ||
| Line 117: | Line 119: | ||
* post notes as required | * post notes as required | ||
| - | === | + | === DQ1 FSA === |
4) (Full System Analysis) // AG | 4) (Full System Analysis) // AG | ||
| Line 125: | Line 127: | ||
* create SOW | * 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 | 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
