SDLC and related for 2012

From UG

Revision as of 18:31, 4 April 2012 (edit) Perry (Talk | contribs) (→Support Process) ← Older edit		Revision as of 21:25, 5 April 2012 (edit) (undo) Perry (Talk | contribs) (→Support Process) Newer edit →
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 = DQR (Development Queue Review)
-	** ph=DQ (development queue)	+	** ph=DQR (development queue)
	** Dv=?		** Dv=?
	** T=[priority]		** T=[priority]
		+	* For items DQS:
		+	** 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 that make it into the Development queue. Post notes if necessary.	+	* Review DQR items. Post notes if necessary.
		+	* For complex items, update item to DQS (Development Queue Support).
	'''Developers'''		'''Developers'''
	* Review Development Queue (Mantis Q=Y)		* Review Development Queue (Mantis Q=Y)
-	** Select a task that you wish to start working on. YELLOW items have not passed Architect review. If you wish to work on any YELLOW items, please circle back with Architect first.	+	** Select a task a DQ task that you wish to start working on.
	** Update Mantis with:		** Update Mantis with:
	*** ph=DEV		*** ph=DEV

---

Revision as of 21:25, 5 April 2012

Contents 1 Info 2 Teams and roles 2.1 Product Team 2.2 Dev Team 2.3 Support Team 3 Development Process 3.1 RFC 3.2 BA 3.3 Current AS-IS SDLC Process 3.4 Proposed TO-BE SDLC starting March 2012 4 Support Process 5 Project Management 5.1 Mantis cleanup 6 Misc 6.1 Communication hours 6.2 Mantis feedback 6.3 Status updates 7 Ver 2.0

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 = DQR (Development Queue Review)
  • ph=DQR (development queue)
  • Dv=?
  • T=[priority]
• For items DQS:
  • 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).

Developers

• Review Development Queue (Mantis Q=Y)
  • Select a task a DQ task 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)