SDLC and related for 2012
From UG
Contents |
Info
Teams and roles
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
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
Support Team
- Support Manager (Denise)
- - reports to Development Manager
- Systems Administrator (Vlad)
- - reports to Development Manager
- Support Engineers (Tracie, AG)
- - reports to Development Manager
Development Process
RFC
ph = RFC
This phase is for ....
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
Current AS-IS SDLC Process
Proposed TO-BE SDLC starting March 2012
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.
Project Management
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.
Misc
Communication hours
Mantis feedback
Status updates
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)
