SDLC and related for 2012

From UG

(Difference between revisions)
Jump to: navigation, search
(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=DQ (development queue)
+
** 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 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) 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. 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 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 process.  
+
*** '''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

File:JFS SDLC ASIS rev1.1.JPG

[edit] Proposed TO-BE SDLC starting March 2012

File:JFS SDLC Proposed TOBE rev1.1.JPG

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

File:JFS Development Queue v1.jpg

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