Software Development
PracticesPresented by Pam
Background
• Large-scale software development & IT projects, plagued with high failure rates:– Product does not meet Customer’s actual need
– Over budget
– Late
– Low quality
• Why? Lots of reasons have been proposed:– High degree of Uncertainty (Tech Platform, Requirements,
Process)
– All aspects of work are “intangible” – from Problem specification, Design, Software solution, Deployment.
– Tendency to Over-engineering / Lose focus
– Integration Problems –incompatible platforms, 3rd party etc.
• Improvements:– New Tools
– New Practices
Is Games Development Similar?
• Yes & No.
• Similarities:
– It's software! (Duh)
• The general phases of development are the same
• Most of the problems are the same
– Estimates are really Guesses
– Changing requirements
• Games tend to be like regular software projects on
steroids
– Very large code bases, large problem domain
– Need many specialists
• There are more differences …
Is Games Development Different?
• Fun is the Primary Goal but hard to pin down
• Serendipitous outcome from collaboration b/w multiple groups
• Inventive nature of the work
• Art & Design components of project
– Creative vision can be challenging to communicate & steer.
– Have different requirements and scheduling needs
– Can be hard to tell if you’re on the right track until Critical Mass
• Add large “content integration” phase missing from other
types of projects
• Games does not fit narrow classifications
– Part embedded system, part real-time multimedia, part database
• Hard deadlines:
– Manufacturing date is set
Code, Design and Art
• A game is really three projects running in parallel
– Cross dependencies can be large & constantly changing
– Work to minimize them
• Designers and artists shouldn't need code work to get new content
into game
• Coders don’t need final art to implement a feature
• Complex & shifting dependencies & bottlenecks
• Having solid design, before starting anything else is
great
– Never happens in practice.
– Studios working on Sequels have solid technology before even
beginning content creation
– Purchase tech
Schools of Thought
• Control the Uncertainty.
– Characterized by:
• Heavy Upfront Design
• Sign offs
• Build to Specification
• Structured customer involvement
• Embrace the Uncertainty.
– Characterized by:
• Iterative & adaptive processes
• People-oriented processes
• Frequent deployment & feedback
• Collaborative customer relations
Waterfall Approach
• Often thought of as a strictly single-pass sequential
process:
– Requirements Analysis
– Specification & Tech Design
– Sign-off
– Plan
– Implement the Plan
• Spend lots of time in Upfront Design
• Typically involves lots of Formal documentation
• Emphasizes controls & sign-offs
Waterfall Approach: Pros & Cons
• Pros:
– Simple
– Big up-front Design makes Team look good (at least initally)
• Cons:
– Large part of Project Risk is Discovered Late
– Rate of Change in validates Initial Design
– Doesn’t account for Unknowns
– Upper Management likes a “well-defined” plan
• Not particularly well-suited for Games
AGILE & ITERATIVE
APPROACHES
Agile Manifesto
Practical Applications
Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile Principles1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Lean Thinking
• Eliminate Waste– E.g. features that aren’t high value
• Increase Feedback
• Delay Commitment– Develop a sense of when a decision is ready to made or needs to
be made
– Wait for key developments to confirm or disprove
– Avoid committing to “speculative” features or unnecessary details upfront
• Deliver Fast
• Build Integrity In
• Empower the Team
• See the Whole
Agile Practices
• Iterative Development– Short Milestones
– Timebox Feature Exploration
– Define & Deliver software features in working increments
• Feature Oriented– Prioritized Feature Backlogs
– Features described from Customer’s perspective
• Iterative Planning – Scope & Reprioritize at Regular Intervals
– Respect planning horizon (Macro vs Micro)
• Emphasize Collaboration & Communication• Frequent Face2Face Touchbase
• Make Project Info public
• Frequent Reviews, Acknowledge successes
• Inspect & Adapt
Scrum Practices
• Team meets daily – 15 mins, standing meetings called
Scrums
• Team is typically multi-disciplinary
• Chickens don’t speak, Pigs do
• Sprints – 2 to 4 weeks long
• Everyone answers 3 questions:
1. What’s have you done since last meeting
2. What will you do between now and next meeting
3. What got in your way
• Not Scrum, but better question for no.2 is :
– “When will you finish Feature X”.
• Scrum Master – responsible for removing impediments
Scrum Cont’d
• Update Scrum Board
Update Burndown Charts
http://blog.brightgreenprojects.com/2009/07/07/what-is-a-burndown-chart/
Make Project Info Visible
• Information Radiator
– One-to-Many communication
– Project Info is placed on Wall in the Team Space
– Big visible & simple
XP Practices
• The whole team work together in a common project room
• Evolutionary deliveries – small & frequent releases
• Simple Design – Do the simplest thing that will work
• Test driven development – write unit tests before or concurrently with feature
• Pair programming – all production code is created by two programmers
• Frequent refactoring – Refactoring is continual effort to simplify the code and the larger design
• Team code ownership – Entire team is collectively responsible for all the code; Peer reviews / Code walkthroughs
• Continuous Integration – Build automation & testing
• Coding Standards – Establish and follow code conventions
• Sustainable pace
Other Iterative Approaches
• Prototyping:
– Throw away
• Use first prototype as a test bed for ideas. Once key ideas are
proven, chuck it
– Evolutionary
• The prototype forms the seed of the product
• Refactor
• Spiral Model
– Variant of Waterfall Method
– Requirements -> Risk assessment -> Prototype -> Evaluate ->
Repeat
– Not very appealing to Management
Hybrid Approach
• Carefully select a set of practices for your team:
– Based on Principles
– Experience of Team, Values of Team
– Needs of Stakeholders
• Conflicting needs of stakeholders
– Publisher
– want Design Details upfront to make $$$ decisions, project sales,
organize Marketing & sales
– want to influence product, suggest changes
– Management – wants predictability
– Team
– wants flexibility in schedule, deferring commitments
- wants to reduce rework
Suggestions for your Project
• Discuss & agree on some a few principles & practices– Keep the List short (3-6?)
– Keep it lightweight
• Inspect & Adapt at regular intervals
• Other Questions to ask Yourselves:– How will you celebrate successes?
– How will you deal with challenges as a Team?
– What is your vision for how team will function?
– What are your goals as a Team?
• Learning Goals
• Have Fun
• Gain real experience
• Become great game developers?
DISCUSSION TIME
The End