DQ and RFC process

From UG

Revision as of 17:59, 12 June 2012

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 Workflow classes

We have the following top level workflows

• Projects (Prj). Examples: GM Split, POEM, DR/KPI, I-Portal
• Urgent Bugs (UB)
• Urgent Change (UC)
• Development Queue (DQ) - any work that is subject to CT2 Release and is not covered by Prj or UB
• Support (Sup). Examples: create new user, re-start server, etc.
• Misc (Misc)

"wf" mantis field is used to associate task with specific workflow class.

• Prj
• UB
• UC
• DQ1 - Invention/Analysis phases of DQ (BA/SA/etc)
• DQ2 - Implementation phases of DQ (Dev/QA/SIT/etc)
• Sup
• Misc

IP

Prj, UB, DQ have different initial phases but common end: IP (Implementation Phase).

It consists of the following sub-phases:

• Dev
• QA
• SIT
• UAT
• T2S (Transfer To Support)
• Rel (Release)

UB Phases

• BR - bug report
• #IS

Proj

• BA
• SA
• Est
• #IS

DQ

DQ1:

• RFC
• IBA
• ISA
• PTR
• FSA

DQ2

• #IS

Details of DQ workflow

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

DQ1:

• covers BA, SA and related
• wf mantis field = DQ1

DQ2:

• covers Implementation (Dev/QA/SIT/etc)
• wf mantis field = DQ2

DQ1 details

RFC

• purpose: create mantis
• owner: Denise
• ph mantis field: RFC

Details:

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

IBA

• purpose: (Initial Biziness Analysis or Bug Report)
• owner: Denise
• ph mantis field: IBA

Details:

• Conduct and post into mantis preliminary Business Analysis/Requirements (for changes) or Detailed Bug Report (for bugs)
• design/solution ideas could be added as well if needed/available

ISA

• purpose: (Initial Sys Analysis)
• owner: Alex
• ph mantis field: ISA

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

PTR

• purpose: (Product Team Review)
• owner: Denise or Alex?
• ph mantis field: PTR

Details:

• 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

FSA

• purpose: Full System Analysis
• owner: AG
• ph mantis field: FSA

Details:

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

DQ2 details

• purpose: Implementation
• owner: Perry
• ph mantis field: Dev/QA/SIT/UAT/T2S/Rel

Details:

• 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). Highlight in RED overdue tasks/developers that have overdue tasks.

• create plans for next week:
  • identify how many m/h available from each dev next week (Normally, each dev would contribute 8 hours a week to DQ2. 4 hours if super busy with the Proj )
  • 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 Release phases of DQ2