Adaptive Project Framework



Poker NightAdaptive Project FrameworkInfo 638 – Spring Qtr 2011 – Dr. GassonTony Abruzzo, Reggie James, Brian Raak, Chad Stephenson6/6/2011I/We certify that:This paper/project/exam is entirely my/our own work. I/We have not quoted the words of any other person from a printed source or a website without indicating what has been quoted and providing an appropriate citation. I/We have not submitted this paper / project report, or any substantial portion thereof, to satisfy the requirements of any other course. Signature Anthony Abruzzo, Brian Raak, Chad Stephenson, Reginald James Date _____6/6/2011________________Table of Contents TOC \o "1-2" \h \z \u 1Company Background and Operations PAGEREF _Toc295087760 \h 41.1Key Business Processes PAGEREF _Toc295087761 \h 41.2Other operational opportunities PAGEREF _Toc295087762 \h 41.3Major operational complaints PAGEREF _Toc295087763 \h 41.4Operational expectations for growth PAGEREF _Toc295087764 \h 41.5Analysis PAGEREF _Toc295087765 \h 42Project Overview Statement PAGEREF _Toc295087766 \h 42.1Problem and Opportunity PAGEREF _Toc295087767 \h 42.2Goal PAGEREF _Toc295087768 \h 42.3Objectives PAGEREF _Toc295087769 \h 52.4Success Criteria PAGEREF _Toc295087770 \h 62.5Risks, Assumptions and Obstacles PAGEREF _Toc295087771 \h 73Work Breakdown Structure (WBS) PAGEREF _Toc295087772 \h 73.1High Level WBS PAGEREF _Toc295087773 \h 73.2Mid-Level WBS PAGEREF _Toc295087774 \h 84Detailed Planning and Estimation PAGEREF _Toc295087775 \h 94.1Requirements Breakdown Structure (RBS) PAGEREF _Toc295087776 \h 94.2Gantt Chart PAGEREF _Toc295087777 \h 94.3Cycle Plan PAGEREF _Toc295087778 \h 104.4Schedule and Cost Estimation PAGEREF _Toc295087779 \h 105Project management and control approach PAGEREF _Toc295087780 \h 105.1Status reporting and operations meetings PAGEREF _Toc295087781 \h 105.2Control Meetings PAGEREF _Toc295087782 \h 10Table of Contents (Continued)6Change Control PAGEREF _Toc295087783 \h 116.1Changes in Scope PAGEREF _Toc295087784 \h 116.2Scope change Procedure PAGEREF _Toc295087785 \h 116.3Defect Change Control PAGEREF _Toc295087786 \h 126.4Deployment Change Control PAGEREF _Toc295087787 \h 13Company Background and OperationsKey Business ProcessesZynga can either accept credit card payments or credits can be purchased through a third party (ITunes for example). Credits are needed in order to continue to play certain types of games. For example in Zynga Poker you can purchase 60,000 chips for $0.99. Other game types might require engery. Zynga also sells advertising sponsorship.Other operational opportunitiesWith the development of a web-based online poker game Zynga has the opportunity to leverage the future state architecture for use on the Apple iPhone and the Droid series of smartphones. This capability will allow Zynga to develop low costs solutions that take advantage of native features within each respective platform. The suite of games combined with usage statistic software will allow Zynga to gain a better understanding of their client-base and further provide its advertisers with pertinent user data for marketing analysis.Operational expectations for growthBased on initial marketing research Zynga expects a 120% increase on game penetration in the first quarter of the games launch. Zynga also expects 40% recurring users in the first quarter with increasing growth in subsequent quarters. This market research is based off of private studies conducted on Zynga’s target market of online web-based poker games.AnalysisKey Performance IndicatorsProject Overview StatementProblem and OpportunityZynga has had great success with Zynga Poker. With Zynga Poker users can either go to and play on a web browser or download an app to their IPhone or Droid OS phone. In order to remain successful Zynga has to continue developing games that users will download, play, and pay to maintain(ie: buy chips). Zynga is aware of the popularity of home poker games and sees this as an opportunity in a niche market, with deep marketing possibilities.The multi-variable poker games will refresh the static Zynga card playing market. The younger electronically bound, tech savvy users will be the main focus of a new product and combined marketing strategy to drive Zynga growth. Zynga sees the young technology savvy sector as a niche market, where competition amongst them is welcome. Zynga sees this an opportunity to entertain that competition as well as market to them.Marketing inside the games will allows greater detail of consumer interests and patterns and has the most earning potential with the launch of this new platform. The marketing segment for this product is meant to capture the details of consumer habits while they are surrounded by their friends. The ability to monitor their traffic patterns as a group is the special interest inside this concept.GoalAs with any business the main goal is to bring in additional revenue. In 2010 Zynga revenues were around $850 million. Zynga believes that they can reach revenues of over $1 billion with the successful development of PokerNight. This goal will be achieved by both new gamming users and new marketing vendors.Our goal is to provide so much flexibility within the possibility of online poker games that we offer something for everyone. We envision ‘guys poker night’ as several friends together in the same room with mobile devices playing online cards, together at the same online card table.Our goal is to achieve greater marketing detail that fits our clientele so perfectly our marketing vendors will spend top dollar with the knowledge that advertising on our site will yield the highest returns.ObjectivesPROJECT SCOPEThe scope of this project is to create online poker games for user communities who come together at a common gambling table. It is also the scope of this project to collect user traffic patterns that can be used as statistical data to attract vendors for advertising and marketing. There are total of 9 games identified as the original portion for the scope of this effort. The skin of this game will include also be the prime the marketing space for a single vendor. The system back end will collect all data about user navigation when they leave our site, so we can show user statistics for advertisement purposes.PRODUCT SCOPEZynga would like to design an online game that will be based on poker night ‘at the guys house.’ Currently online poker games exist (both for real money and fake money) but they only allow you to play one game; this is normally Texas-Holdem. After each hand is over a different type of poker game may be selected. This selection can be selected randomly, selected by whoever has the dealer chip in front of them, selected by who ever won the most amount of money in the previous hand. The objective of the game is to win chips (that have no monetary value). The game idea is based off Zynga poker that can be played in a Internet browser, on an IPhone or on a Droid Phone. Zynga only offers Texas-Holdem at the present time. The game will be developed to be played on a Internet browser but will include apps for the IPhone and Droid phones in later iterations.Because this is not gambling for actual money, there is no restriction on the age of people that can join or play the game. A general understanding of the different types of poker games is needed however. The site will offer tutorials on how each one is played. The game will be played around a table (the person hosting the game will be able to select from different types of tables) Poker being a multiple player game, a minimum of two players is needed, however some games will require a minimum of three in order to be played. All tables will have a maximum of nine players, but an infinite number of players can be logged in a the same time on different tables. Players can either join a public game or play private games.The site will be free to join, but you have to purchase chips in order to play the games. This purchase cost of the chips will help to maintain the cost of the site. The site will also bring in additional income by advertising. Players on the site will maintain a profile. Information in the profile will include a user name, location, sex, age (if you want to provide), amount of chips that you currently have, what level of a poker and player you are.Different types of poker games that can be played.Lowball: Based on five card draw, Lowest hand wins.High-Low Split: Highest and lowest hands split the pot5 card stud7 card studTexas HoldEm. Users are dealt two cards. Betting takes place.5 card drawRollercoaster: Players are dealt one card at a time, betting after each card;Harem: All jacks and kings in your hand are wild unless you have a queen. In which case you have no wilds cards. But if you have 3 queens you have a harem, automatic win.Hurricane: Players are dealt two face-down cards. Players can draw two cards or bet. Deuces wild. High hand winsSuccess CriteriaThis project will be judged against the following criteria:Users will play the new addition to the Zynga line up.Zynga will successfully increase revenues by users’ chip purchases. Initially free chips will be given out so that users can have the opportunity to try out the game.Zynga will develop Poker Night with zero errors after production. Development will be based on a Cleanroom approach where time an effort will be spent upfront to reduce errors after.Zynga will successfully sell add space to generate additional revenue.Risks, Assumptions and ObstaclesMoney will be available to develop and maintain the project. Addition capital will be need for future additions to the project.That ‘Poker Night’ will generate a profit for ZyngaSystem will be users friendly for the users playing the game‘Poker Night’ will be 100% reliable. Any downtime will cause users to go somewhere else.Work Breakdown Structure (WBS)High Level WBSThe following diagram shows the high-level feature-sets and the incremental functionality to be implemented in successive cycles of development.Mid-Level WBSThe Mid-Level WBS will focus on the Stud Poker feature and its corresponding cycles. The first cycle will be the design cycle and will include the activities to gather high-level requirements and begin designing and refining the product and the system architecture. During requirements in the planning cycle the team will drive out requirements for which functionality is most desired by clients. During the refine architecture activity the client will gain understanding of the specified design and corresponding architecture and provide acceptance to the approach before implementation.During the build cycle the team will put into place the requirements and the architecture design that was defined during the planning cycle. The beginning of the cycle shall be devoted to planning what implementation will look like for that cycle and the client will help to define success through acceptance criteria for the implementation. Testing will be executed as soon as the components are developed and elevated into a region for testing. As system testing is executed the business client will be responsible for signing off that the system works as stated in the requirements and are to clients specification. The business client will be involved throughout the phase to continue to define the solution and redirect the low-level features to be developed as necessary.The client checkpoint cycle will consist of a retrospective about the particular cycle and look into lessons learned. A review of quality tests should be conducted and any additional features should be signed off by the business as necessary. Any low-level features that were not implemented should be re-evaluated to ensure that these features make sense for later cycles. If the client determines these features do not provide the highest business value the subsequent cycle features should be revised. The client should begin prioritizing features for the subsequent sprint and the development team should be briefed on impending development efforts.Detailed Planning and EstimationRequirements Breakdown Structure (RBS)Gantt ChartCycle Plan3 cycles, 30 days eachThe first cycle will enable multi-player 5 card stud and 7 card stud.The second cycle will enable multi-player 5 card draw, Lowball, and High Low Split.The third cycle will enable multi-player Rollercoaster, Harem, and Hurricane.The Low Level Features from our RBS are integrated into our APF project plan’s cycle build phase and consist of a Develop Table Start Component, Develop Betting/Chip control component, and a Develop Play/Show Hand Component.Schedule and Cost EstimationAttached MS Project Plan file shows the project starting on June 13th, and ending on September 19th. The estimated cost for the project is $172,920.Project management and control approachStatus reporting and operations meetingsThe Vice President of Gaming is responsible for overseeing all the virtual gaming games of Zynga. He is at the top of the hierarchy. The Project Manager who will be responsible for leading the team will answer to the VP of Gaming. All team leads will be responsible for reporting to the Project Manager.Mid-Cycle and full-cycle reports will be sent to the entire project team and the VP of Gaming for each cycle within the project. The Mid-Cycle report will contain a summary of mid-level to low-level features to be implemented and the overall project status. The Full-Cycle reports will contain a detailed list of which features were implemented and which features were left out of the product. The full-cycle report will also contain an overview of testing will summarize which tests are passing and which features will need rework in subsequent cycles.Operations meetings will be held after every-other cycle or as needed which the project manager or the VP of gaming shall determine. The goal of this meeting is to determine is any changes to existing operational procedures is necessary. These operational changes or enhancements should be compared against any known change in scope. These meetings need not be long or especially detailed, as these meetings will serve as a checkpoint formality. The business client throughout the agile project lifecycle should continually evaluate the scope.Control MeetingsThe number one control meeting for this adaptive effort is going to be the feature planning and prioritization meeting. This meeting is going to allow the team to place the business priorities in the correct sequence. This meeting will structure time such that the business will be able to appropriately consider the issues and risks involved with the engineering of the business solution.Other control meetings will not be as rigid, keeping in the spirit of an agile effort; only when there is significant detail around risks and issues will an actual meeting be necessary as a control check. Stand-Up MeetingThroughout the cycle the team shall engage in a 15 minute stand-up meeting that will allow each team member to give an update on what they worked on the previous day, what they plan on working on the current day, and if they have any impediments with their work. The stand-up meeting shall limit conversation about the work as the objective is for team members to give their status update and make the team aware of daily progress. The project manager shall be responsible from removing the team’s impediments within one business day. If impediments cannot be removed the impediment should be clearly displayed where the entire team has access to the project status.During the implementation iteration the team shall discuss new major defects with the remaining time in the Stand-Up Meeting. Testers shall also make the developers aware of any issues with testing so that issues can be resolved quickly and the work can progress throughout the sprint.Change ControlChanges in ScopeA scope change is work which the project manager would like added or changed on the current project. The project manager is solely responsible for initiating all change requests and for communicating them to the customer via a Project Change Request (PCR) form. The PCR will include estimates that detail the following:the size of the change in the project cost and resourcesthe impact on the schedulethe impact on the software architecture and work-in-progressThe PCR will be presented to the customer for review and acceptance during the weekly project review meeting. A log of all PCRs and their acceptance (sign-off) will be maintained by the project manager and kept in the project folder.Scope change ProcedureThe procedure for making scope changes is controlled by the PM. However the need for a change can from any external or internal communication. The most common scope change comes from the gaming community and the subject matter experts. These will be typically the highest priority scope changes. Occasionally testing will find deficiencies in the design or requirements that need to be addressed so the software actually addresses the goal of the business. There are many newer, more attractive features that will also be realized during the development effort. For all of these reasons we have put together a process to control these additional requirements.Feature Analyst / ExpertThe feature analyst is a generic term that helps describe a subject matter expert (SME). This can be anyone with enough experience to speak to the highest standards for the application, the user experience or the company benefit. Document coexistence or stand alone with respect to other featuresDescribe feature in accordance with company requirements modelingProject ManagerThis individual ensures the rigor given to the processes within the project is adequate. The PM is overall responsible for ensuring all components of project and company policy are adhered to.Receives a feature change requestIdentifies the scope change factors (Evaluates new RBS)Completes a PCRRequests approval from Project Sponsor for the PCREstimates the time required to research and estimate the PCRRequests the time from the customer to research and estimate the PCRIf the research and estimate time is approved, completes a Prioritization meeting, to deliver the new feature within a business prioritized time frame.Reviews the PCR with the project team for execution and deliveryDefect Change ControlBecause defects are such a large part of the change control process it is important to show the life cycle of a defect. This ensures both that defects have the correct visibility in the feature lifecycle and also how it is introduced to the SDLC if it is new scope.Deployment Change ControlThis process is driven by regular deployment meetings. Deployments to production are driven by what is available each week from the development team. The deployment manager will be responsible for ensuring the correct list of changes weekly are distributed the production servers.Validates code stream updates for individual software games.Ensures all documentation is complete for the code installation.Bundles the final code releases together in the deployment staging server(s)Applies new code to operational ready serversVerifies new code on new operational ready serversTakes the operational system offlineDirects updated servers back to target definitionsApplies new code base to standby serversVerifies operational readinessApplies new code to D&R serversVerifies operational readinessReports completion of change ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download