DQ and RFC process

From UG

Revision as of 20:16, 6 June 2012 (edit) Alex (Talk | contribs) (→DQ Phases) ← Older edit		Revision as of 20:20, 6 June 2012 (edit) (undo) Alex (Talk | contribs) (→DQ RFC) Newer edit →
Line 30:		Line 30:
	=== DQ RFC ===		=== DQ RFC ===
		+
		+	* purpose: create mantis
		+	* owner: Alex
		+
	Details:		Details:
-	* create mantis for requested Change or Non Urgent Bug	+	* create mantis record with initial available info for Change Request or Non Urgent Bug
	=== BC IBA ===		=== BC IBA ===

---

Revision as of 20:20, 6 June 2012

Contents 1 Info 2 Glossary 3 DQ UB Proj and Sup 4 Urgent Bugs 5 DQ Phases 5.1 DQ RFC 5.2 BC IBA 5.3 DQ ISA 5.4 DQ PTR 5.5 DQ FSA 5.6 DQ Dev, QA, SIT, UAT, T2S, Rel

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

DQ UB Proj and Sup

?|Map|Misc|Sup| --- UB: |BR| --- DQA: |IBA|ISA|PTR|FSA| --- ProjA: |BA|SA|Est|---- Impl:|Dev|QA|SIT|UAT|UAT1|UAT2|UAT3|UAT4|UAT5|UAT6|UAT7|UAT8|T2S|Arc|----- Old: |ArcBDlogs|Blog2009|Blog2010|Blog2011|Blog2012| Dlog|

Urgent Bugs

• U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
• Non Urgent Bugs are managed through RFC

DQ Phases

DQ RFC

• purpose: create mantis
• owner: Alex

Details:

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

BC IBA

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

Details:

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

DQ 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

DQ 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

DQ FSA

4) (Full System Analysis) // AG

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

DQ 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