DQ and RFC process
From UG
(Difference between revisions)
(→RFC: definition, process, etc) |
(→DQ: definition, process, etc) |
||
| Line 29: | Line 29: | ||
=== DQ: definition, process, etc === | === DQ: definition, process, etc === | ||
| - | *DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc) | + | DQR > DQS > DQE > DQ |
| - | *DQ is managed by Support Manager (Denise) | + | |
| - | *This list has a limited number of items (max=40) | + | * 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 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. | + | * DQ is managed by Support Manager (Denise) |
| - | *Weekly | + | * 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 '''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=??? | ||
| + | ** 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 === | === Wiki for DQ === | ||
Revision as of 22:26, 31 May 2012
Contents |
Definitions Process Etc
Key processes:
- 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.
- Non Urgent Bugs are managed through RFC
RFC: definition, process, etc
- RFC (Requests For Changes) is a list of Non Urgent Bugs and changes to CT2 requested by users, managers, dev team, etc .
- RFC is managed by Support Manager (Denise)
- As request (that make sense) comes in, Denise/AG creates a mantis with ph="RFC"
- RFC Review Meeting:
- 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
DQR > DQS > DQE > DQ
- 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 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 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=???
- 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
Each DQ should have SOW (except bugs).
Each DQ mantis (except bugs) should have link to SOW in Description field.
SOW should be under appropriate wiki (example: tweaks to Trendset in Trendset wiki, etc)
