Cybertrax 2.1 Client (project plan)
From UG
(Difference between revisions)
(→Specs workflow) |
(→Specs workflow) |
||
| Line 105: | Line 105: | ||
* SA1 (Tira) creates use cases (UI mockups+descr) based on "business story" and "(requirements) 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" | * 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: | * Completed sections get passed to SA2 (Andrei). His goal is: | ||
** a) transform [[#RFP specs]] into [[#3CS specs]]: | ** a) transform [[#RFP specs]] into [[#3CS specs]]: | ||
| Line 112: | Line 113: | ||
** b) update them if new info comes in | ** b) update them if new info comes in | ||
** c) assigns into Estimation | ** 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 | ** Note: [[#Black box design]] has additional specs of updating spec after Dev is completed | ||
* Sys Arch: | * Sys Arch: | ||
Revision as of 22:28, 24 June 2010
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
- Broadcasts / News posted into mantis: http://mantis.jaguarfreight.com/mantis/view.php?id=2127
- Questions / answers about proj planning should be posted there as well
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; 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; responsible for:
- creating solution based on requirements
- documenting design
- focus on creating user interface mockups
- helping Denise in more technical aspects of requirements gathering/analysis
- Andrei - Systems analyst; responsible for:
- creating solution based on requirements
- documentation (managing #3CS specs)
- focus on analysing all existing docs and making sure nothing is missing
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
- asking questions (if something is incomplete/incorrect/unclear)
- 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
- a) transform #RFP specs into #3CS specs:
- 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
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
- specs:
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
- specs:
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
- specs:
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
