DQ and RFC process

From UG

(Difference between revisions)
Jump to: navigation, search
(→RFC: definition, process, etc)
(→DQ)
 
(57 intermediate revisions not shown)
Line 1: Line 1:
[[Category:DQ]]
[[Category:DQ]]
-
== Definitions Process Etc ==  
+
== Info ==
-
Key processes:
+
This wiki is about RFC and DQ methodology.
-
* how to SA/document
+
-
* how to manage
+
-
=== Urgent Bugs: definition, process, etc ===
+
Problems with old process:
-
*U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
+
* no specs/SA in many cases
-
*Non Urgent Bugs are managed through RFC
+
* developers had no clear plans
 +
* we had no idea what will be completed when (except urgent tasks)
-
=== RFC: definition, process, etc ===
+
== Glossary ==
-
* RFC (Requests For Changes) is a list of Non Urgent Bugs and changes to CT2 requested by users, managers, dev team, etc .
+
* L0 (L zero) = initial/rough;
-
* RFC is managed by Support Manager (Denise)
+
* L1 = full
-
* As request (that make sense) comes in, Denise/AG creates a mantis with ph="RFC"
+
* RFC = Request For Change
-
* '''RFC Review Meeting''':
+
* DQ = Development Queue
-
** is a regular bi-weekly meeting (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry))
+
-
** each request is given:
+
-
*** reviewed
+
-
*** given tentative solution (posted in mantis note)
+
-
*** given rough estimate (posted into emh/emhR fields with "r" prefix).
+
-
** SA time must be estimated es well
+
-
** some requests might be combined, rejected, comments to Prod Man posted, etc.
+
-
** Dv field must be assigned (whenever possible to "any" or if not then to specific developer).
+
-
=== DQ: definition, process, etc ===
+
== Top level Jag Soft Dev Workflow classes ==
-
*DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc)
+
We have the following top level workflows
-
*DQ is managed by Support Manager (Denise)
+
-
*This list has a limited number of items (max=40)
+
-
*DQ is re-filled from RFC list through regular bi-weekly RFC2DQ Meetings (Sup Manager + Prod Manager). On this meeting approved record gets ph="DQ" and T defined.
+
-
*Weekly DQ Development meet
+
-
=== Wiki for DQ ===
+
* 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)
-
Each DQ should have SOW (except bugs).  
+
"wf" mantis field is used to associate task with specific workflow class.
-
Each DQ mantis (except bugs) should have link to SOW in Description field.
+
* Prj
 +
* UB
 +
* UC
 +
* DQ1 - Invention/Analysis phases of DQ (BA/SA/etc)
 +
* DQ2 - Implementation phases of DQ (Dev/QA/SIT/etc)
 +
* Sup
 +
* Misc
-
SOW should be under appropriate wiki (example: tweaks to Trendset in Trendset wiki, etc)
+
== 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)
 +
 
 +
== UB ==
 +
Phases:
 +
* BR - bug report
 +
* [[#IP]]
 +
 
 +
== UC ==
 +
Phases:
 +
 
 +
* BA
 +
* SA
 +
* Est
 +
* [[#IP]]
 +
 
 +
== Proj ==
 +
Phases:
 +
 
 +
* BA
 +
* SA
 +
* Est
 +
* [[#IP]]
 +
 
 +
== DQ ==
 +
 
 +
Phases:
 +
 
 +
DQ1:
 +
* RFC 
 +
* IBA 
 +
* ISA 
 +
* PTR 
 +
* FSA
 +
* Est
 +
 
 +
DQ2 
 +
* [[#IP]]
 +
 
 +
== 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
 +
 
 +
=== Est ===
 +
 
 +
 
 +
* '''purpose''': Exact estimation
 +
* '''owner''': Developer/ Dev Manager
 +
* '''ph mantis field:''' Est
 +
 
 +
Details:
 +
 
 +
* conduct L1 estimation (replace L0 with L1)
 +
 
 +
===  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

Current revision as of 20:30, 27 June 2012


Contents

[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

[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
Retrieved from "https://wiki.jaguarfreight.com/DQ_and_RFC_process"
Personal tools