SDLC and related for 2012

From UG

Revision as of 20:18, 20 March 2012 (edit) Perry (Talk | contribs) ← Older edit		Current revision as of 20:12, 21 December 2012 (edit) (undo) Perry (Talk | contribs) (→Post Project Review)
(8 intermediate revisions not shown)
Line 86:		Line 86:
	== Support Process ==		== 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.
		+
		+	[[File:JFS Development Queue v1.jpg]]
	== Project Management ==		== Project Management ==
Line 94:		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 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 5.2 Post Project Review 6 Misc 6.1 Communication hours 6.2 Mantis feedback 6.3 Status updates 7 Ver 2.0

[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)