DQ and RFC process

From UG

(Difference between revisions)
Jump to: navigation, search
(→DQ: definition, process, etc)
Line 1: Line 1:
[[Category:DQ]]
[[Category:DQ]]
-
== Definitions Process Etc ==
+
== Urgent Bugs ==
-
 
+
-
Key challenges:
+
-
* how to SA/document
+
-
* how to manage
+
-
 
+
-
=== Urgent Bugs: definition, process, etc ===
+
*U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
*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
*Non Urgent Bugs are managed through RFC
-
=== RFC: definition, process, etc ===
+
== Glossary ==
 +
 
 +
* L0 (L zero) = initial/rough;
 +
* L1 = full
 +
* RFC = Request For Change
 +
* DQ = Development Queue
 +
 
 +
== RFC ==
 +
 
 +
1) ph=RFC (Change Request/Biz Analysis or Bug Report) // Denise
 +
 
 +
* create mantis for requested Change or Non Urgent Bug
 +
* Conduct and post into mantis L0 BA (requirements) or Detailed Bug Report
 +
 
 +
2) ph=RFC-ISA (Initial Sys Analysis) // Alex
 +
 
 +
* 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
 +
 
 +
3) ph=RFC-PR (Product Team Review) // ?
-
* RFC (Requests For Changes) is a list of Non Urgent Bugs and changes to CT2 requested by users, managers, dev team, etc .
+
* review periodically tasks that completed RFC-SA (say 5 a week)
-
* RFC is managed by Support Manager (Denise)
+
* meet to discuss requirements/solution/emh (Marc, Denise, Alex, Perry?)
-
* As request (that make sense) comes in, Denise/AG creates a mantis with ph="RFC"
+
* reject/approve (by Marc)
-
* '''RFC Review Meeting''':
+
* set T
-
** is a regular bi-weekly meeting (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry))  
+
* post notes as required
-
** 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).
+
-
** set task as ph=RFC2DQ
+
-
=== DQ: definition, process, etc ===
+
4) ph=RFC-FSA (Full System Analysis) // AG
-
DQS > DQ
+
* conduct L1 SA
 +
* consult KU, SA, developers, BA as required
 +
* create SOW
-
* DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc) through RFC2DQ Meeting
+
== DQ ==
-
* 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
+
-
* '''RFC2DQ''' Meetings
+
-
**(Sup Manager + Prod Manager):
+
-
** On this meeting approved record gets ph="DQ"(bugs) or "DQS" and T defined.
+
-
* Weekly '''DQD (Development)''' meetings:
+
-
** who: Sup Man, SAs, devs (available next week for DQ)
+
-
** review last week (filter by dueW#, should be in SIT hopefully)
+
-
** planning Devs:
+
-
*** before the meeting ask all project PMs about how many mh per developer is avail for DQ work
+
-
*** sort all tasks by T
+
-
*** based on T, Dv and Dv hours avail next week decide who is doing what next week
+
-
*** set dueW# for next week on tasks assigned
+
-
*** set ph=DQ
+
-
** planning SA:
+
-
*** before the meeting find out how many mh are avail
+
-
*** sort all tasks by T
+
-
*** based on T, A and A hours avail next week decide who is doing what next week
+
-
*** set dueW# for next week on tasks assigned
+
-
*** set ph=DQS
+
-
=== Wiki for DQ ===
+
5) ph = DQ (Dev Queue Management) // Perry
-
Each DQ should have SOW (except bugs).
+
* 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)
-
Each DQ mantis (except bugs) should have link to SOW in Description field.
+
* 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)
-
SOW should be under appropriate wiki (example: tweaks to Trendset in Trendset wiki, etc)
+
* coordinate SIT/UAT and Releases of DQ

Revision as of 21:27, 3 June 2012


Contents

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

Glossary

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

RFC

1) ph=RFC (Change Request/Biz Analysis or Bug Report) // Denise

  • create mantis for requested Change or Non Urgent Bug
  • Conduct and post into mantis L0 BA (requirements) or Detailed Bug Report

2) ph=RFC-ISA (Initial Sys Analysis) // Alex

  • 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

3) ph=RFC-PR (Product Team Review) // ?

  • 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

4) ph=RFC-FSA (Full System Analysis) // AG

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

DQ

5) ph = DQ (Dev Queue Management) // 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
Retrieved from "https://wiki.jaguarfreight.com/DQ_and_RFC_process"
Personal tools