SDLC and related for 2012
From UG
(Difference between revisions)
(→Support Process) |
(→Post Project Review) |
||
| (5 intermediate revisions not shown) | |||
| Line 93: | Line 93: | ||
* Evaluate request and add into RFC list. | * Evaluate request and add into RFC list. | ||
* For new items in the development queue: | * For new items in the development queue: | ||
| - | ** status = StatusX | + | ** status = StatusX |
| - | ** ph= | + | ** ph=DQR (development queue review) |
** Dv=? | ** Dv=? | ||
** T=[priority] | ** T=[priority] | ||
| + | * For items in DQS phase: | ||
| + | ** Review and perform further analysis. Update item to DQ phase once analysis is complete. | ||
| + | |||
| + | '''Analyst''' | ||
| + | * For items in DQS phase: | ||
| + | ** Review and perform further analysis. Update item to DQ phase once analysis is complete. | ||
'''Change Control Board''' | '''Change Control Board''' | ||
| Line 102: | Line 108: | ||
'''Architect''' | '''Architect''' | ||
| - | * Review items | + | * Review DQR items. Post notes if necessary. |
| + | ** For complex items, update item to DQS (Development Queue Support) phase. | ||
| + | ** For items that can immediately go into development, update item to DQ (Development Queue) phase. | ||
'''Developers''' | '''Developers''' | ||
* Review Development Queue (Mantis Q=Y) | * Review Development Queue (Mantis Q=Y) | ||
| - | ** Select a task that you wish to start working on. | + | ** Select a task in DQ phase that you wish to start working on. |
** Update Mantis with: | ** Update Mantis with: | ||
*** ph=DEV | *** ph=DEV | ||
*** DV=<yourself> | *** DV=<yourself> | ||
** Each developer will be expected to create an SOW in Wiki along with Post-Implementation notes. This will help us keep our documentation in order as well as help QA with testing. Analyst, Support, and Architect will definitely provide assistance if necessary. | ** Each developer will be expected to create an SOW in Wiki along with Post-Implementation notes. This will help us keep our documentation in order as well as help QA with testing. Analyst, Support, and Architect will definitely provide assistance if necessary. | ||
| - | ** Once development for task is complete, follow the usual ph=QA, then ph=SIT, then ph=UAT | + | *** '''Note: We are not asking developers to write complete specifications. The SOW should be an addendum to the existing specification for that specific module - basically this is so we can maintain a trail of changes. If a specification becomes too cumbersome, we will allocate time to update the entire specification with all changes.''' |
| + | ** Once development for task is complete, follow the usual ph=QA, then ph=SIT, then ph=UAT, then ph=T2S phases. | ||
[[File:JFS Development Queue v1.jpg]] | [[File:JFS Development Queue v1.jpg]] | ||
| Line 122: | Line 131: | ||
Sup tasks cleanup is managed by Sup Manager. | Sup tasks cleanup is managed by Sup Manager. | ||
| + | |||
| + | === Post Project Review === | ||
| + | www.surveymonkey.com | ||
| + | |||
| + | username: perry@jaguarfreight.com | ||
| + | |||
| + | password: Jaguar123 | ||
== Misc == | == Misc == | ||
Current revision as of 20:12, 21 December 2012
Contents |
[edit] Info
[edit] Teams and roles
[edit] Product Team
- Project Sponsor (Simon)
- Product Manager/Lead Module Owner (Marc)
- - reports to Project Sponsor
- Module Owners (Simon, Marc, Karen, CK, ...)
- - report to Project Sponsor
- CT2 Board (Simon, Marc, Karen, Alex, Perry)
- - report to Project Sponsor
[edit] Dev Team
- Director of Development (Alex)
- - reports to Project Sponsor
- Project Manager (Perry)
- - reports to Director of Development
- - managing timeline and resources
- - managing all backlogs (projects, BA, Dev)
- - project planning
- - status updates
- - escalations, conflict resolutions
- - liaison between Dev and Product teams
- - liaison between Dev and Support teams
- - review RFCs with Product Team
- - review Product Vision and Roadmap with Product Team
- Solutions Architect (Alex)
- - reports to Director of Development
- Development Manager (Kostya)
- - reports to Director of Development
- Business/Systems Analysts (Tira, Alex, Perry)
- - reports to Director of Development; for Sprint tasks to Project Manager
- Developers (Kostya, Sasha, AK, Misha)
- - report to Development Manager; for Sprint tasks to Project Manager
- QA (Roma)
- - reports to Development Manager; for Sprint tasks to Project Manager
[edit] Support Team
- Support Manager (Denise)
- - reports to Development Manager
- Systems Administrator (Vlad)
- - reports to Development Manager
- Support Engineers (Tracie, AG)
- - reports to Development Manager
[edit] Development Process
[edit] RFC
ph = RFC
This phase is for ....
[edit] BA
??? I suggest to re-use .e, ..., 1,2,... for BAs. Add flag if required "type of hours"
BA phases: |RFC|Blog|BA|SA|ArcSR|MOSR|Est|
Dev phases:|Dlog|Dev|QA|UAT|WU|T2S|TG|CDR|Arc
[edit] Current AS-IS SDLC Process
[edit] Proposed TO-BE SDLC starting March 2012
[edit] Support Process
Product Management
- Submit request to Support
Support
- Evaluate request and add into RFC list.
- For new items in the development queue:
- status = StatusX
- ph=DQR (development queue review)
- Dv=?
- T=[priority]
- For items in DQS phase:
- Review and perform further analysis. Update item to DQ phase once analysis is complete.
Analyst
- For items in DQS phase:
- Review and perform further analysis. Update item to DQ phase once analysis is complete.
Change Control Board
- Evaluate all RFCs and development queue items. Re-prioritize if necessary.
Architect
- Review DQR items. Post notes if necessary.
- For complex items, update item to DQS (Development Queue Support) phase.
- For items that can immediately go into development, update item to DQ (Development Queue) phase.
Developers
- Review Development Queue (Mantis Q=Y)
- Select a task in DQ phase that you wish to start working on.
- Update Mantis with:
- ph=DEV
- DV=<yourself>
- Each developer will be expected to create an SOW in Wiki along with Post-Implementation notes. This will help us keep our documentation in order as well as help QA with testing. Analyst, Support, and Architect will definitely provide assistance if necessary.
- Note: We are not asking developers to write complete specifications. The SOW should be an addendum to the existing specification for that specific module - basically this is so we can maintain a trail of changes. If a specification becomes too cumbersome, we will allocate time to update the entire specification with all changes.
- Once development for task is complete, follow the usual ph=QA, then ph=SIT, then ph=UAT, then ph=T2S phases.
[edit] Project Management
[edit] Mantis cleanup
Review tasks from previous sprints that remain in open state and push BAs to resolve.
Sup tasks cleanup is managed by Sup Manager.
[edit] Post Project Review
www.surveymonkey.com
username: perry@jaguarfreight.com
password: Jaguar123
[edit] Misc
[edit] Communication hours
[edit] Mantis feedback
[edit] Status updates
[edit] Ver 2.0
- add est fields for BAs and weekly schedule (alex)
- Formal approval of SOWs
- Change control for tasks in Dev
- UAT by end users
- Formal communication plan for executives (dashboard)
- post mortem for Sprint with Dev team // post proj review
- weekly status updates (all dev team together)
