DQ and RFC process
From UG
(Difference between revisions)
(→PTR) |
(→Details of DQ workflow) |
||
| Line 77: | Line 77: | ||
For convenience it is broken into 2 sub-workflows: DQ1 and DQ2. | For convenience it is broken into 2 sub-workflows: DQ1 and DQ2. | ||
| - | DQ1 covers BA, SA and related. | + | DQ1: |
| + | * covers BA, SA and related. | ||
| + | * wf mantis field = DQ1 | ||
| - | DQ2 covers Implementation (Dev/QA/SIT/etc) | + | DQ2: |
| + | * covers Implementation (Dev/QA/SIT/etc) | ||
| + | * wf mantis field = DQ2 | ||
=== DQ1 details === | === DQ1 details === | ||
| Line 85: | Line 89: | ||
==== RFC ==== | ==== RFC ==== | ||
| - | * purpose: create mantis | + | * '''purpose''': create mantis |
| - | * owner: Denise | + | * '''owner''': Denise |
Details: | Details: | ||
| Line 103: | Line 107: | ||
* '''purpose:''' (Initial Sys Analysis) | * '''purpose:''' (Initial Sys Analysis) | ||
| - | * owner: Alex | + | * '''owner''': Alex |
Details: | Details: | ||
| Line 126: | Line 130: | ||
* '''owner''': Denise or Alex? | * '''owner''': Denise or Alex? | ||
| - | + | Details: | |
* review periodically tasks that completed RFC-SA (say 5 a week) | * review periodically tasks that completed RFC-SA (say 5 a week) | ||
| Line 136: | Line 140: | ||
=== FSA === | === FSA === | ||
| - | + | * purpose: Full System Analysis | |
| + | * owner: AG | ||
| + | |||
| + | Details: | ||
* conduct L1 SA | * conduct L1 SA | ||
| Line 144: | Line 151: | ||
=== DQ2 details === | === DQ2 details === | ||
| - | * | + | * purpose: Implementation |
| - | * | + | * owner: Perry |
| - | * ph field = Dev/QA/SIT/UAT/T2S/Rel | + | |
| + | * ph mantis field = Dev/QA/SIT/UAT/T2S/Rel | ||
| + | |||
| + | Details: | ||
* conduct weekly DQ meetings to: | * conduct weekly DQ meetings to: | ||
Revision as of 17:46, 12 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 Workflow classes
We have the following top level workflows
- Projects (Prj). Examples: GM Split, POEM, DR/KPI, I-Portal
- Urgent Bugs (UB)
- 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
- DQ1 - Invention/Analysis phases (BA/SA/etc)
- DQ2 - Implementation phase (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
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
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
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
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?
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
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
