1 / 28

Agile Development

Agile Development. CS 490/590 Wesley Kerr. Agile Game Development. More structured iterative development method Agile Game Development With Scrum Clinton Keith. Brief History. Arcade Games – Hardware expensive Home Consoles (Atari) – Cheap hardware In the beginning…

akina
Télécharger la présentation

Agile Development

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. Agile Development CS 490/590 Wesley Kerr

  2. Agile Game Development • More structured iterative development method • Agile Game Development With Scrum • Clinton Keith

  3. Brief History • Arcade Games – Hardware expensive • Home Consoles (Atari) – Cheap hardware • In the beginning… • Small groups of developers (3-4 people months) • As profits grew, technology got better…. • Large groups of developers (30-40 people months)

  4. Waterfall Method Game Design Document Game Pitch Coding and Asset Creation Source: http://www.mikesmart.com/application_development/waterfall_method.htm

  5. Better Way • In the early stages of the game, we might know what genre of game we are making (e.g. FPS)…. • We don’t all of the different types of guns in the game • We don’t know how many bullets each magazine will hold • … • Many of these features are determined through balancing and testing • The key is to have a working game prototype as quickly as possible • Iterate and find the fun factor for your game

  6. …. Of Course You Want These Things • It’s not enough to simply voice desires… • We need a plan for how to accomplish this • Challenges • Feature creep (emergent requirements) • Overoptimistic schedules • The challenge of production • Enter Agile/Iterative development • Aside: Last year at GDC, all of the studios presenting talks that I attended mentioned that they were using iterative development

  7. Agile Manifesto • We are uncovering better ways of developing software by doing it and helping others do it. • Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • That is, while there is value in the items on the right, we value the items on the left more.

  8. What an Agile Project Looks Like • Series of iterations of development • Each iteration is some short interval of time • Commonly 2 to 4 weeks – we will use two weeks • 4 class periods… • 12 hours worth of work… • During each iteration, developers implement individual features that have value • We’ll call these features stories • Allows us to adjust goals and measure progress

  9. What an Agile Project Looks Like • We iterate over every element of the game development process in each iteration • Concept • Design • Coding • Asset Creation • Debugging • Optimizing • Tuning and Polishing • After each iteration, we review the game • Playable demo in a releasable state

  10. Scrum Workflow

  11. Planning • Meetings at the beginning of each sprint with the stakeholders • This requires two meetings • Sprint prioritization meeting • Spring planning meeting

  12. Sprint Prioritization Meeting • Sprint Prioritization Meeting • Prepares the product backlog and identifies the sprint goal • Each team member needs to understand each PBI • Your opportunity to raise any design questions • Break down PBIs that are too large for a single sprint • Select the top PBIs from the backlog that you can accomplish • You are not committed to anything yet, you’ve only identified the tasks

  13. Sprint Planning Meeting • Next meeting after the prioritization meeting • First identify any constraints affecting the team • Holidays reduce the amount of time available • Potential impacts from other areas, engine change or major unknowns • Estimate hours available to commit to the sprint • Estimate in the ideal number of hours it will take you to complete the task • Discuss design and implementation details for every PBI that is potentially part of the sprint goal • Follow the flow chart…

  14. Product Backlog Start Take the next highest PBI from the backlog Identify and estimate all tasks, needed to complete the PBI Split/return PBI to backlog Do the task hours added to the sprint backlog exceed team capacity Yes No Sprint Backlog Add Tasks to Sprint backlog No Yes Is the Sprint backlog full? Done

  15. Tracking Progress • Communication is key to successfully finishing sprints • Need to be able to identify progress • Need to identify impediments • Number of low-tech practices to share information • Task Cards • Burndown Chart • Daily Sprint Backlog Trend

  16. Task Board User Stories Tasks in Progress Tasks Completed Tasks Not Started Burndown

  17. Daily Scrum Meeting • To synchronize effort among all team members • To commit to the work accomplished in the next day • To identify impediments to be addressed by the team • To ensure that team members are “on the same page” • Everyone hears all problems so that solutions can be addressed in the meeting. • Meeting lasts 15 minutes • Finishes regardless of whether or not everyone gets to speak • No sitting • Answer three questions • What have I done since the previous daily scrum? • What am I going to accomplish between now and the next daily scrum? • What are the problems or impediments slowing me down?

  18. Sprint Review • Meeting on the last day of the sprint • Bring everyone together to discuss the work completed • Starts with a discussion of the goal of the sprint and and the results • If a PBI is dropped, the reasons are discussed here • Live demo of the current iteration of the game • The product owner accepts or rejects the results of the sprint • If a feature is declined, the product owner decides whether the feature goes back on the backlog or it is removed

  19. Retrospective • Allows us to employ “inspect and adapt” • Inspect the progress of the game • Adapt our plans to the value of the emerging game • Answer the following the questions • What things should stop doing? • What should we start doing? • What is working well that we should continue to do?

  20. Recap Sprint Prioritization Meeting Sprint Planning Meeting Sprint Review Retrospective

  21. User Stories • A way of describing the requirements of the game from the point of the view of the user, not the developer. As a <user role>, I want <goal> [so that <reason>]. • User Role: customer of the game or user of the pipeline who benefits from the story • Goal: The goal of the story. This is a feature or function of the game, tool, or pipeline. • Reason: The benefit to the customer of user when this feature or function is used. • Conditions of Satisfaction • Details that let us know we have successfully completed the story. • Must be testable, and must be verified before marking the story as complete.

  22. So what makes a good story? • INVEST (Cohn and Wake 2003) • Independent • Negotiable • Valuable • Estimatable • Sized appropriately • Testable

  23. Development Stages • Concept • Ideas generated, possibly prototyped, and thrown away on a regular basis • Timeboxed to deliver one or more concept development plans • Pre-production • Explore what is fun and how we are going to build assets • Create levels and other assets that represent production quality • Fully iterative and incremental • Production • Create the full game experience using core mechanics discovered during pre-production • Focus on efficiency and incremental improvements • Most of the details have been worked out… jump height, etc. • Post-Production • Polish the game experience

  24. Challenges…from Technology • Uncertainty… • Rather than figure out all of the design problems up front • Iterate and adapt • Too Much Architecture Up Front • Implementing a solution that encompasses all the potential solutions • Issues • Slows the introduction of new features up front • These architectures often still need to be changed

  25. Challenges…from Art • Primary Challenges • Need to know that what you are creating is the right thing and not a wasted effort • Artists need a stable working build • Artists need faster tools and pipelines • Concerns about Agile • Scrum is for programmers • Art production runs on a schedule, therefore we cannot be iterative • Cross-discipline teams don’t work • Overcoming ‘Not yet done’ syndrome

  26. Recap Sprint Prioritization Meeting Sprint Planning Meeting Sprint Review Retrospective

  27. 3rd Person Racing Game Epics Single Player Player Control Tutorial Campaign Camera Controller Weapons Control Player Motion Artificial Intelligence Story Line Player Physics Controller Input Control

  28. Software • Trello • Everyone create an account • One of you create a project board, add your me and your team

More Related