DQ and RFC process

From UG

(Difference between revisions)
Jump to: navigation, search
(→RFC: definition, process, etc)
(→DQ)
 
(61 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 changes to CT2 requested by users, managers, dev team, etc and Non Urgent Bugs.
+
* L0 (L zero) = initial/rough;
-
* RFC is managed by Support Manager (Denise)
+
* L1 = full
-
* As request that make sence comes in Denise creates a mantis with ph="RFC"
+
* RFC = Request For Change
-
* RFC Review Meeting is a regular bi-weekly meeting during which all requests are reviewed by participants (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry)) and given tentative solution (posted in mantis note) and rough estimate (posted into emh/emhR fields with "r" prefix). SA time must be estimated es well. Also at this point some requests might be combined, rejected, comments to Prod Man posted, etc. Also Dv field must be assigned (whenever possible to "any" or if not then to specific developer).
+
* DQ = Development Queue
-
=== 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