DQ and RFC process

From UG

Revision as of 17:54, 12 June 2012 (edit) Alex (Talk | contribs) (→Details of DQ workflow) ← Older edit		Current revision as of 20:30, 27 June 2012 (edit) (undo) Alex (Talk | contribs) (→DQ)
(5 intermediate revisions not shown)
Line 24:		Line 24:
	* Projects (Prj). Examples: GM Split, POEM, DR/KPI, I-Portal		* Projects (Prj). Examples: GM Split, POEM, DR/KPI, I-Portal
	* Urgent Bugs (UB)		* 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'''		* 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.		* Support (Sup). Examples: create new user, re-start server, etc.
Line 31:		Line 32:
	* Prj		* Prj
-	* DQ1 - Invention/Analysis phases (BA/SA/etc)	+	* UB
-	* DQ2 - Implementation phase (Dev/QA/SIT/etc)	+	* UC
		+	* DQ1 - Invention/Analysis phases of DQ (BA/SA/etc)
		+	* DQ2 - Implementation phases of DQ (Dev/QA/SIT/etc)
	* Sup		* Sup
	* Misc		* Misc
Line 46:		Line 49:
	* SIT		* SIT
	* UAT		* UAT
-	* T2S (Transfer To Support)	+	* Stg (Staging)
	* Rel (Release)		* Rel (Release)
-	== UB Phases ==	+	== UB ==
-		+	Phases:
	* BR - bug report		* BR - bug report
-	* [[#IS]]	+	* [[#IP]]
		+
		+	== UC ==
		+	Phases:
		+
		+	* BA
		+	* SA
		+	* Est
		+	* [[#IP]]
	== Proj ==		== Proj ==
		+	Phases:
	* BA		* BA
	* SA		* SA
	* Est		* Est
-	* [[#IS]]	+	* [[#IP]]
	== DQ ==		== DQ ==
		+
		+	Phases:
	DQ1:		DQ1:
Line 69:		Line 83:
	* PTR		* PTR
	* FSA		* FSA
		+	* Est
	DQ2		DQ2
-	* [[#IS]]	+	* [[#IP]]
	== Details of DQ workflow ==		== Details of DQ workflow ==
Line 153:		Line 168:
	* consult KU, SA, developers, BA as required		* consult KU, SA, developers, BA as required
	* create SOW		* create SOW
		+
		+	=== Est ===
		+
		+
		+	* '''purpose''': Exact estimation
		+	* '''owner''': Developer/ Dev Manager
		+	* '''ph mantis field:''' Est
		+
		+	Details:
		+
		+	* conduct L1 estimation (replace L0 with L1)
	===  DQ2  details ===		===  DQ2  details ===

---

Current revision as of 20:30, 27 June 2012

Contents 1 Info 2 Glossary 3 Top level Jag Soft Dev Workflow classes 4 IP 5 UB 6 UC 7 Proj 8 DQ 9 Details of DQ workflow 9.1 DQ1 details 9.1.1 RFC 9.1.2 IBA 9.1.3 ISA 9.1.4 PTR 9.2 FSA 9.3 Est 9.4 DQ2 details

[edit] 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)

[edit] Glossary

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

[edit] 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

[edit] 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
• Stg (Staging)
• Rel (Release)

[edit] UB

Phases:

• BR - bug report
• #IP

[edit] UC

Phases:

• BA
• SA
• Est
• #IP

[edit] Proj

Phases:

• BA
• SA
• Est
• #IP

[edit] DQ

Phases:

DQ1:

• RFC
• IBA
• ISA
• PTR
• FSA
• Est

DQ2

• #IP

[edit] 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

[edit] DQ1 details

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] FSA

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

Details:

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

[edit] Est

• purpose: Exact estimation
• owner: Developer/ Dev Manager
• ph mantis field: Est

Details:

• conduct L1 estimation (replace L0 with L1)

[edit] 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