1 / 51

eBay Project Management (PJM) Process Overview

eBay Project Management (PJM) Process Overview. Contents. Definitions eBay Train Concept Product Development Life Cycle Key Activities, Tools and Roles & Responsibilities Planning Design Development Feature Test and merge Regression Roll-Out/Launch International Rollout/Launch

dawson
Download Presentation

eBay Project Management (PJM) Process Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eBay Project Management (PJM) Process Overview

  2. Contents • Definitions • eBay Train Concept • Product Development Life Cycle Key Activities, Tools and Roles & Responsibilities • Planning • Design • Development • Feature Test and merge • Regression • Roll-Out/Launch • International Rollout/Launch • Overall Key PJM Responsibilities • Detail walk-through of MS project plan template

  3. Definitions • Tracker – Custom built eBay tool used for project scoping, project initiation, resource booking, release management and reporting • LTS – Live to Site • Train Seats – measurement of LOE, equivalent to 3 weeks of a developer’s time • GPP/Portforlio Management – Global Product Planning Team • Pools – A set of servers that are grouped together based on functionality (e.g: My eBay Pool, SYI, SYI pool, etc.) • Rebasing – upgrading code base to latest version of production code “main” branch. Rebasing is done throughout the project and the number of times is based on the duration of the project. • CARB – Capacity Architecture Review Board • JAD/ARB: Joint Architecture Design / Architecture Review Board • Groups: PjM – Project Manager, PM – Product Manager, PD – Product Development, QA – Quality, Assurance, Ops – Operations, UED – User Experience and Design • GXT – Global Cross-Functional Team

  4. eBay Train Concept Overview • The eBay web sites are constantly being updated in order to add new features, modify existing features, or to remove features not liked by the eBay community. Release terminology uses the metaphor of Trains. • EBay's software releases are referred to as "trains". Each Train has a code number (e. g. 495 = the e495 core train / e495i = intl train). A core train (for the . com site) is released every week: 2 weeks = 1 train number. International Train rolls out 1 week after the Core LTS • eBay Releases Features, Enhancements, Patches every 2 weeks which is referred to as trains. Trains are branches of the code, trains are released every 2 weeks, and hence the increment from e495 -> e497 (skips one, the number is the actual number of rollouts since the 1st one) the last state of a train is suffixed with "_caboose" so before a train, e.g. e495 gets released, it is labeled as e495_carboose. Trains are branched off from main and later get merged back into main again. Train conductors are people who facilitate the release of the train. The international train is branched off on the regular train (not off the main branch) and it is rolled out 1 week after core LTS. • Each train has a specific amount of capacity on it: "train seats". • Train seats reflect the amount of development effort associated with each train. One train seat is equal to 15 developer days. e.g: 1 week (5 days) = . 3 train seats • eBay features are sized in terms of how many train seats it takes to build them.Business units are given a budget for trainseats. (e.g: 1 PD TS = $42K (approximate)) • Trains are even numbers for Search_BE (e494, e496…), rolls every 6 weeks • API Train rolls out on Wednesdays of the Core LTS week. • Train schedule can be found at: • https://tracker.corp.ebay.com/cfdocs/ProdDev/releaseschedule/help/train_week_cheat_sheet.cfm

  5. Product Development Life Cycle (PDLC) Phases of the PDLC • Planning • Analysis • Design • Development • Testing • Release

  6. Planning Phase: Key Activities • Concepts are submitted to be scoped by BU/PM team through tracker • Scoping team assigns level of effort to the concept • Operations, Product Development, IM (information management), UED (usability engineering design), QA • Project is prioritized and assigned a GXT priority • Project is booked based on GXT priority • Key milestone dates are assigned – PRD start/end dates; LTS • Resources are assigned • Developers and Operations engineers are assigned based on scope by GPP • Project manager is assigned by PMO managers • Product Managers are assigned by PM manager • UED is assigned by UED managers Planning Analysis Design Development Testing Release

  7. Planning Phase: Tracker Interaction Examples http://tracker • Concept • Scope Request • Project Initiation – project summary, milestones, resources, contacts

  8. Planning Phase: Deliverables • Concept Submission – Product Management • Concept Scoped – GPP scoping team (Ops, PD, IM, UED) • Project Prioritized & Booked – GPP resource management • Project Hand-off from GPP to PMO

  9. Planning Phase: Roles & Responsibilities

  10. Analysis Phase: Key Activities • Product Requirements document (PRD) Kick-off • Working sessions to complete Product Requirements document (PRD) • Usability testing • Design sessions between architecture, PD leads, PM and PMO • High level requirement review • Determination if JAD/ARB are required • Joint Architecture Design (JAD) & Architecture Review Board (ARB) • PRD reviews • Resource booking starts for project • Develop Project Management Team Material (Technology kick-off deck, draft project plan) Planning Analysis Design Development Testing Release

  11. Analysis Phase: Tracker Interaction Example of… http://tracker • Project Summary • Milestone dates (PRD, JAD/ARB) • Documentation Area • Contacts • Resources

  12. JAD/ARB • What is JAD? • JAD stands for Joint Architecture Design • JAD is required whenever a project requires an architectural change or challenge to eBay’s platform • Who is the JAD team? • PD architects • Who Participates from the project team • PD architect – presents • Ops architect • PD leads and Dev managers • Project Manager • Product Manager (optional) • How to Schedule JAD • PD architect schedules JAD through tracker • JAD schedule is published by the JAD facilitator • JAD takes place every Monday and Wednesday • What is ARB? • Architecture Review Board • Projects go to ARB after approved through JAD • ARB is made up of Architecture and PD Directors, Operations & VP’s • ARB takes place every Tuesday and Thursday

  13. Analysis Phase: Deliverables • Final PRD – Start of Change Control • Project Booked (with on-going planning this may not be completed yet) • JAD/ARB Complete (instances where it is not completed until beginning of design) • Project Management material completed (kick-off deck, draft project plan)

  14. Project Kick-off • PJM should hold project team kick-off on the first day that development starts • Your team will have a template for the project kick-offs

  15. MS Project Plan Creation • MS project plan needs to be created for all projects • Project plan should be based on PMO template and modified as necessary based on the project • Link to MS project template “One Plan”: http://share/sites/PMOPortal/Tabs/Templates%20and%20Tools.aspx?RootFolder=%2fsites%2fPMOPortal%2fProcess%20Templates%2fProject%20Plans&FolderCTID=&View=%7bA312DAA2%2dD60D%2d42D5%2d9435%2d98F9B1D07739%7d&PageView=Shared

  16. Analysis Phase: Roles & Responsibilities

  17. Design Phase: Key Activities • Baseline Project Plan Complete • JAD/ARB Completion • PRD re-scoping completed by PD, IM & Ops team • PD Engineering Requirements Document Development (ERD) – PD focused • ERD Ops Checklist Development – Ops focused • Ops ERD checklist exemption -- DL-eBay-OPS-ERD-exemption • DR Deferral - DL-eBay-Ops-DR-DeferralExemption • ERD Reviews • PD ERD reviews • Pre-Ops ERD reviews (Ops project stakeholders) • Ops ERD review • Ops Tickets Submitted • Pooling Decisions Made • Change Requests Process in effect • Determine if L&P is needed (Load and Performance Testing) Planning Analysis Design Development Testing Release

  18. PRD Rescoping • All PRD’s are rescoped by PD, IM, and Ops once they are completed • PJM sends out PRD scope request to project leads to scope (tracker scoping in beta/manual process) • Leads complete scope and PJM compiles final scope document if several PD teams involved • PJM facilitates scope review with leads and PM to review final scope (only required if greater than original scope) • Team agrees on final scope. If scope cuts are made, PM will submit CR to remove requirements. • If scope increases, PJM will work with GPP on resourcing options and submit train seat approval requests via email (note: will be automated with tracker scoping tool) • Once train seats are approved, PJM will update tracker launch details (note: will be automated with tracker scoping tool)

  19. Example of PRD rescope summary

  20. Spreadsheet Template

  21. TrainSeat & Train Move Approval Process • Train seat approval is required whenever there is an increase in PD train seats • Train move approval is required whenever there is a need to move a project to a different train • Process can be found at: http://share/sites/PMOPortal/Tabs/Process%20Updates.aspx?PageView=Shared

  22. PD ERD • ERD (Engineering Requirements Document) is developed by the PD leads on the project • ERD cannot be completed without JAD/ARB being approved or determined as not needed • Best practice is to have one ERD for the project and designate a lead to pull it together if there are more than one development teams working on a project • ERD template can be found at: • \\Sjc-efs-01\group\Engineering\ProdDev\ProdDvlpmt\WEEKLY_ERD_REVIEWS

  23. Ops ERD Checklist • ERD checklist is completed by the PD leads on the team and the main audience is operations • Critical that ERD checklist is done as early possible, because it determines the operation needs for a project, which may have a long lead-time(e.g: new Hardware, firewalls, monitoring, etc.) • Once ERD checklist completed, a draft review is mandatory with the PD lead, Architect, project manager and pertinent operations team members (pre-ops ERD review) • Ops ERD review is then conducted and project is either designated as green, yellow or red from operations • Information on scheduling ops ERD review, templates and process can be found here: • \\Sjc-efs-01\group\Engineering\ProdDev\ProdDvlpmt\WEEKLY_ERD_REVIEWS

  24. Change Request (CR) Process • Submission of CR’s is done through tracker by the product manager • Approval of the CR is the responsibility of the project manager after soliciting feedback from the team on scope and risk • CR process can found here: • \\SJC-EFS-01.corp.ebay.com\GROUP\Engineering\ProdDev\ProjectMgmt\Training\ChangeRequests.pdf

  25. Pooling • Information on Pooling can be found at: • http://rms2/sites/RMMisc/pool/default.aspx

  26. Design Phase: Deliverables • JAD/ARB • PD ERD • Ops ERD • All tickets filed from Ops ERD checklist • Capacity, Batch, dB, Monitoring, Pooling, etc. • Capacity tickets should be filed for each project • Determine whether project falls into tier 1 (add’l capacity required), 2 (potentially requires add’l capacity), 3 (no add’l capacity required) • Determines if project will need CARB review • PRD rescope completed • All resources required on the project are booked

  27. Design Phase: Tracker Interaction Example of… http://tracker • Requesting an Ops Architect • JAD flag • Scheduling JAD • Ops ERD checklist • Making train seats/train changes in tracker • Change requests (CR’s) • Status reporting • Validate booking (PD, Ops, IMD, Content, UED)

  28. Design Phase: Trace Interaction • Demo of Trace and different tickets • Detailed training given in Operations Training

  29. Design Phase: Roles & Responsibilities

  30. Development Phase: Key Activities • Coding • Integrated Testing • Test Plan and Test Case Creation • L&P test planning • Install any needed HW and/or configuration changes to QA and production environments • Dev2QA hand-off date determined • L10N (localization) reviews and requests submitted • Code branches registered with SCM • PHD • ROP (roll-out Plan) Planning Analysis Design Development Testing Release

  31. PHD (Production Hand-over Document) & Batch Supplement • What is it? • PHD stands for production hand-over document and is the handover document from PD to the site operations team • PHD documents high level functionality, system diagram, partner contingency, monitoring, and PD contacts required for escalation purposes. • There is a standard template for the PHD and can be found at: • http://portal.corp.ebay.com/showfiledetails.cfm?ChannelID=66&Object=template&objectID=6935 • Process Flow: http://portal.corp.ebay.com/ChannelFiles/66/PHD_Workflow1.pdf • Do all projects need a PHD and/or batch supplement? • Not all projects require a PHD or batch supplement • Site ops & batch representative in Ops ERD review will identify whether either a PHD or batch supplement is required. • When does the PHD review occur and how is it scheduled? • PHD reviews are weekly – every Wednesday • Project manager schedules it on iportal • Link to PHD sign-up: http://portal.corp.ebay.com/showfaq.cfm?ChannelID=66&faqType=Default • When does the review need to take place • No later than 3 weeks before a project LTS date • Who attends • PD lead(s) presents PHD and/or batch supplement to the operations team • Operations team members present (site ops, batch, monitoring) • Project Manager

  32. Dev2QA Hand-off What is the Dev2QA hand-off? • Dev2QA hand-off is the official hand-over from development to QA. • This is the milestone where QA testing officially begins • PD demonstrates to QA that the build is stable and coding is complete. What environment does it need to be conducted on? • Dev2QA hand-off must be conducted on the feature pool that QA will be testing on (not a dev machine) How is it conducted? • PD leads(s) typically demonstrate key functionality to the project team • Critical that the PM is in attendance during this review • PJM, all QA and key developers need to be at the review • QA lead takes notes of issues and these result in bugs created Who determines if the Dev2QA hand-off is completed? • QA lead is responsible for either accepting or declining the build PjMs update Tracker with Dev2QA dates on the Train Page

  33. Merge Approval deadlines and Expected Dev2QA handoff Dates by Track

  34. Development Phase: Tracker Interaction Example of… http://tracker • ROP (roll-out plan)

  35. Development Phase: Deliverables • Code Complete • Test Plan and Test Cases identified and approved by team • QA HW additions and/or configuration changes completed • Production HW in process • Dev2QA hand-off completed • L10N (localization) reviews and requests submitted • PHD completed • ROP (roll-out Plan) completed • Branch registration

  36. Development Phase: Roles & Responsibilities

  37. Testing Phase: Key Activities • Feature Testing • UI Review • L10N Translation (localization) • Merge Approval • Merge Code to Main • Regression Testing • International Regression Testing • ROP completion • PHD (Production Handover Document) & Batch Supplement development and review Planning Analysis Design Development Testing Release

  38. Testing Phase Week 1 Week 2 Week 3 Week 4 Feature Testing • Code deployed to a feature pool (each project team has their own feature pool or set of pools depending on the complexity of the project) • PD continual rebases to latest version of production code base “main” • At the end of feature testing, QA is required to give merge approval for the feature to be merged to the upcoming train branch Merge • All features slated for a particular train are merged onto the same branch “main” • Project must meet merge criteria to obtain merge approval • PD must register their code branch(es) with SCM • SCM team schedules merge time slot for each project • PD merges code onto main Regression Testing • Regression testing is conducted in the staging environment • L&P testing • Automated test runs • Project team re-runs test cases on staging environment • Project must meet criteria to launch International Testing • Localization complete • International testing conducted on international staging environment (paradise) • Regression testing completed for international • Automated testing • International testing by in country teams

  39. Merge Criteria Percentage of Bugs Closed • P1 100% • P2 100%  • P3 90 %  • P4 75%  Other Merge and LTS Criteria • Global Functional Testing Complete (all sites as applicable) • Should occur during core regression testing • International regression testing only applicable for L10N testing • Automation Pass Rate Greater than 93% (for applicable features/releases) • L&P Testing Complete (for applicable features/releases)

  40. 2007 Web Train Release Criteria/Guidelines Requirements for release of all trains: • QA Manager is comfortable that all required regression testing on the train has been accomplished. • Late bug fixes have had adequate regression testing in surrounding areas. • The QA Mgr has audited the "deferred bugs" (bugs found on this train and moved to another train (including US to Intl trains and to another numbered train) to ensure that such deferred bugs will not be exposed to the community as a result of having been moved. Additional Requirements For release of the US train: • Count total P1 bugs on all US "Web" trains (ISAPI, V3, HTML, Search_F, Batch_EOA, Msg_BE, & V3_Batch). • Train may roll with zero open* P1s. Partial train release using "Pool Blocking" technique is not to be used if there are any P1 bugs. • Count total P2 bugs on all US "Web" trains (same list as P1). Train should roll with zero open P2s. • Partial train release using "Pool Blocking" technique should be used with care and when everyone is completely confident that bug/pool relationship is well understood. Partial train release using "Pool Blocking" technique should be used only when the number of open P2s is <= 6. When there are > 6 open P2 bugs, the entire train should be blocked until the number of open P2s is <= 6. • Count total P3 bugs on all US and Intl trains (ISAPI, Intl, V3, V3_Intl, HTML, HTML_Intl, Search_F, Search_F_Intl, Batch_EOA, Msg_BE, & V3_Batch). Train may roll with unfixed** P3s totaling no more than 10% of total or 50 which ever is lower. • Count total P4 bugs on all US and Intl trains (same list as P3). Train may roll with unfixed P4s totaling no more than 25% of total or 50 which ever is lower.

  41. 2007 Web Train Release Criteria/GuidelinesCon’t Additional Requirements For Release of the Intl train: • (Same basic approach as for US trains.) • Count total P1 bugs on all Intl "Web" trains (Intl, V3_Intl, HTML_Intl, Search_F_Intl). • Train may roll with zero open P1s. Partial train release using "Pool Blocking" technique is not to be used if there are any P1 bugs. • Count total P2 bugs on all Intl "Web" trains (same list as P1). Train should roll with zero open P2s. • Partial train release using "Pool Blocking" technique should be used with care and when everyone is completely confident that bug/pool relationship is well understood. • Partial train release using "Pool Blocking" technique should be used only when the number of open P2s is <= 6. When there are > 6 open P2 bugs, the entire train should be blocked until the number of open P2s is <= 6. • Count total P3 bugs on all US and Intl trains (ISAPI, Intl, V3, V3_Intl, HTML, HTML_Intl, Search_F, Search_F_Intl, Batch_EOA, Msg_BE, & V3_Batch). Train may roll with unfixed P3s totaling no more than 10% of total or 50 which ever is lower. • Count total P4 bugs on all US and Intl trains (same list as P3). Train may roll with unfixed P4s totaling no more than 25% of total or 50 which ever is lower

  42. Testing Phase: Tracker Interaction Example of… http://tracker • Testing Status • Bug List in tracker

  43. Testing Phase: Deliverables • Merge approval obtained • QA testing 100% complete • HW set-up complete • UI reviews complete • L10N complete • Feature ready to roll-out to production

  44. Testing Phase: Roles & Responsibilities

  45. Release Phase: Key Activities • Core LTS Activities • All train criteria met • All production CR’s completed • All hardware set-up • All production smoke testing completed • Close tracker sub-features once project rolls out • International LTS Activities • All translations completed • All train criteria met • All production CR’s completed • All hardware set-up • All production smoke testing completed • Close tracker sub-features once project rolls out Planning Analysis Design Development Testing Release

  46. Release Phase: Tracker Interaction Example of… http://tracker • Train status report • Closing Sub-features: PjMs are responsible for the closing the following types of subfeatures • V3 Batch • Search_BE • Operations • IMD • Data Tools • NTR

  47. Release Phase: Deliverables • Core & International Release Deliverables • Code is rolled to site within train SLA • Tracker Sub-features are closed once code is rolled to site • Conduct team lessons learned session

  48. Release Phase: Roles & Responsibilities

  49. Detail overview of PMO MS project template • Walk-through PMO MS project template as a review of all the steps required to launch a technology roadmap project

  50. Summary of Key Responsibilities of the Project Manager • Understand project requirements, obtain and facilitate updates and clarifications from PM as necessary • Create, update, and communicate project schedule and milestones • Work with project team on resolving issues and escalate at the appropriate times if needed. Escalation is only bad if not done at the correct time and if the project team or direct managers are surprised by the escalation. • Manage project issues --- track issue with clear owner and due dates. • Lead cross-functional team from final requirements to rollout • Gather and communicate status on an ongoing basis to project team and stakeholders • Keep Tracker information current • Manage scope changes • Work closely with other organizations supporting the project (for example., operations for hardware, db work; Legal for legal reviews of content; QA during the QA cycle; etc.) Remember, you are the leader of the project team so, go out there and Lead Completely!!!!

More Related