Cybertrax 2.1 Client (project plan)

From UG

(Difference between revisions)
Jump to: navigation, search
(→Requirements and Documentation Team)
(→Requirements and Documentation Team)
Line 86: Line 86:
** documentation (managing [[#3CS specs]])
** documentation (managing [[#3CS specs]])
** focus on analysing all existing docs and making sure nothing is missing
** focus on analysing all existing docs and making sure nothing is missing
 +
** face to face meetings with dev leads / developers about specs/design in some cases as required
 +
** answer questions from developers/ dev leads about specs
=== Implementation team ===
=== Implementation team ===

Revision as of 22:34, 24 June 2010


Contents

About this doc

This wiki provides all Proj Management info for Cybertrax 2.1 Client project.

Intro

This project is very important therefore planning is critical.

Time vs Features vs Quality

Focus of this project is to deploy minimal set of core features ASAP. As a result feature set will be reduced to minimum and quality might be average (but must not fall below reasonable level)

Time allocated and Error margin 

Summary of time allocated:
 * only 1 week for analysis and requirements gathering
 * only 1 week for design
 * only 3 weeks for coding, testing, rollout/training planning
 * only 1 week for staging/release
-----------------
Total: 6 weeks
                 NOTE: This is an estimate. Error is -1 week/+2 weeks.

Project documentation

All information is gathered and structured in several wikis under Category:Cybertrax 2.1 Client

Current list of docs: 

Cybertrax 2.1 Client (Q and A)
Cybertrax 2.1 Client (data dictionary)	 
Cybertrax 2.1 Client (design)
Cybertrax 2.1 Client (glossary)
Cybertrax 2.1 Client (project plan)	 
Cybertrax 2.1 Client (requirements)
Cybertrax 2.1 Client (use cases)

Project communication

All communication is done through:

  • mantis
  • Skype
  • email (everyone must check min 2 times a day and reply or at least confirm e-mail received same day)
  • Q and A wiki article: Cybertrax 2.1 Client (Q and A)

All mantis tasks are under this parent: http://mantis.jaguarfreight.com/mantis/view.php?id=2077

Project broadcasts and forum

Project update meetings

  • who must attend: Andrei, Sasha, Alex, Denise, Tira
  • Tuesd, Thursd 10-11am
  • Skype chat
  • Coordinator on NY side / Host: Alex
  • Coordinator on Kiev side: Sasha

Project Team and responsibilities

  • Alex - Proj Manager and Solutions Architect; responsible for:
    • proj management/coordination
    • solution architecture/structure
    • helping everyone as required

Requirements and Documentation Team

  • Denise - Business Analyst, RFP Lead; responsible for:
    • gathering requirements and interfacing stackeholders/clients/module owners
    • documenting requirements (#RFP specs)
    • must help Sys Analysts to discover info
    • proof reading/editing docs (in terms of English lang)
  • Tira - Systems analyst, UI/UC Lead; responsible for:
    • creating solution based on requirements
    • documenting design
    • focus on creating user interface mockups, use cases (UC)
    • helping Denise in more technical aspects of requirements gathering/analysis
  • Andrei - Systems analyst, 3CS lead; responsible for:
    • creating solution based on requirements
    • documentation (managing #3CS specs)
    • focus on analysing all existing docs and making sure nothing is missing
    • face to face meetings with dev leads / developers about specs/design in some cases as required
    • answer questions from developers/ dev leads about specs

Implementation team

  • Kostya - Development Manager
  • Sasha - Lead developer
    • serving as a communication liaison between Implementation team (Kiev) and Requirements team (NY)
  • Andriy - Developer
  • Roma - QA and Support

Workflows

Specs workflow

  • Sys Arch (Alex) provides high level breakdown into components / wiki sections
  • BA (Denise) creating:
    • "(requirements) wiki", #RFP specs type
    • "business story" for (use case) wiki
  • SA1 (Tira) creates use cases (UI mockups+descr) based on "business story" and "(requirements) wiki"
  • SA1 (Tira) helps Denise with more technical parts of "(requirements) wiki"
  • Tira and Denise review/proof read each other work
  • Completed sections get passed to SA2 (Andrei). His goal is:
    • a) transform #RFP specs into #3CS specs:
      • asking questions (if something is incomplete/incorrect/unclear)
        • first reach out to Denise (business req questions) or Tira (if more technical question). If they for some reason can not answer then escalate to Sys Arch (use this option with care - SAs/BAs should be able to make your own decisions)
      • rewriting/restructuring spec as required
    • b) update them if new info comes in
    • c) assigns into Estimation
    • answer questions from Developers and Dev Leads (walk them through spec in face to face in some cases as required )
    • Note: #Black box design has additional specs of updating spec after Dev is completed
  • Sys Arch:
    • resolves escalations
    • reviews final specs (in some cases) and assigns into Estimation if it is good

Dev and QA workflow

As usual

Tasks

It is very important to find a good way to disect an monster into pieces to be able to digest it.

Requirements and Documentation tasks

  • 2126 Shipper functionality - Finalize specs/document
  • 2128 Planner functionality - Finalize specs/document
  • 2129 Jaguar functionality - Finalize specs/document
  • 2122 Misc functionality - Finalize specs/document

Support tasks

  • 0002140: (Client 2.1) Create User Guide, Rollout Schedule, Training Plan, Support plan

Implementation tasks

week 1

  • 2134 (Client 2.1) (implementation) Add Shipper, Planner roles to Non Jag User profile
  • 2135 (Client 2.1) Create all new DB fields

week 2

  • 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
  • 2137 (Client 2.1) Code core Planner functionality (authorize/list CTs)

week 3

  • 2138 (Client 2.1) Code all Jaguar functionality (new fields, constraints, Approval Report)
  • 2139 (Client 2.1) Code all misc functionality (notifications, etc)

Weekly Plan

Note: This plane has been approved!

Important Dates

  • 1st date for Release: Thur, July 15
  • 2nd date for Release: Thur, July 22

File:2010 summer calendar.JPG

week 1: June 7 Mon - June 11 Fri

Plan

  • meetings with clients
  • preliminary design sessions
  • end of the week targets:
  • requirements: 50% done
  • design: 30% done
  • documentation: 10% done
  • coding: 0% done
  • QA: 0% done

Actual

Completed as planned!

week 2: June 14 Mon - June 18 Fri

Plan

  • analyze requirements
  • invent design
  • write detailed documentation
  • Wed 2pm: send draft to Simon, Marc
  • Fri 4pm: send ver 1.0 to Bill
  • end of the week targets:
  • requirements: 80% done
  • design: 70% done
  • documentation: 60% done
  • coding: 5% done
  • QA: 0% done

Actual

Completed as planned!

week 3: June 21 Mon - June 25 Fri

Coding week #1

Plan

  • Mon/Tue tasks for every developer must be defined/assigned, start coding
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets :
    • specs:
      • 2126 Shipper functionality - Finalize specs/document
      • 2128 Planner functionality - Finalize specs/document
    • code:
      • complete [andriy] 2134 (Client 2.1) (implementation) Add Shipper, Planner roles to Non Jag User profile
      • complete [kostya] 2135 (Client 2.1) Create all new DB fields
      • start [sasha] 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
    • metrics:
    • code: 30% done
    • QA: 20% done

Actual

TBD

week 4: June 28 Mon - July 2 Fri

Coding week #2

Plan

  • continue coding and QA
  • start UC testing
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets
    • specs:
      • complete: 2129 Jaguar functionality - Finalize specs/document
      • complete: 2122 Misc functionality - Finalize specs/document
    • code:
      • complete: 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
      • start: 2137 (Client 2.1) Code core Planner functionality (authorize/list CTs)
    • metrics:
    • code: 60% done
    • QA: 40% done

Actual

TBD

week 5: July 5 Mon - July 9 Fri

Coding week #3

Plan

  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets
    • specs:
      • complete: 0002140: (Client 2.1) Create User Guide, Rollout Schedule, Training Plan, Support plan
    • code:
      • completed 2137 (Client 2.1) Code core Planner functionality (authorize/list CTs)
      • completed 2138 (Client 2.1) Code all Jaguar functionality (new fields, constraints, Approval Report)
      • completed 2139 (Client 2.1) Code all misc functionality (notifications, etc)
    • metrics:
    • code: 100% done
    • QA: 100% done

Actual

TBD

week 6: July 12 Mon - July 16 Fri

Plan

  • QA on staging
  • Release
  • Training users
  • Mon 9am: release to Staging
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • Thur 7-8pm: release to Production

Actual

TBD

week 7: July 19 Mon - July 23 Fri

Plan

  • "2nd release date" in case we could not release previous week
  • Mon 9am: release to Staging
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • Thur 7-8pm: release to Production

Actual

TBD

Appendix. Two types of specs

Lets introduce the following.

RFP specs

All specs start as informal collection of information. At this stage they could be considered as a Request For Proposal. That is why this type of spec called "RFP type". .

3CS specs

Gradually specs should take shape and finally considered to comply to 3CS:

  • complete
  • correct
  • clear
  • structured

These type of specs we call "3CS specs".

Appendix. Two types of Design methodology

Lets introduce the following.

White box design

What we follow now in most cases:

  • Requirements doc completed
  • Sys analyst creates and documents Design based on Requirements doc
  • Design goes through review process
  • developer codes based on Design doc
  • QA tests based on Design doc

Black box design

Alternative approach:

  • Requirements doc completed
  • Developer codes based on Requirements doc (creating functional Prototype)
  • Sys analyst creates and documents Design based on Prototype
  • Design and Prototype go through review process
  • QA tests based on Design doc
Retrieved from "https://wiki.jaguarfreight.com/Cybertrax_2.1_Client_(project_plan)"
Personal tools