An Introduction To Agile Development


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 08/03/06 22:27 ©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
  • An Introduction To Agile Development

    1. August 14-15, 2006 “ WALK IN” SLIDE
    2. Agile Game Development: Tales from the Trenches <ul><ul><li>Noel Llopis </li></ul></ul><ul><ul><li>Senior Architect High Moon Studios </li></ul></ul>Presentation/Presenter Title Slide
    3. Coming up <ul><li>Agile Development </li></ul><ul><li>Organization Agile Techniques </li></ul><ul><li>Programming Agile Techniques </li></ul><ul><li>Lessons Learned </li></ul>
    4. PART 1: Agile Development
    5. Motivation <ul><li>Unknown technical constraints </li></ul><ul><li>Changing requirements </li></ul><ul><li>Finding the fun factor </li></ul>
    6. What is Agile Development? <ul><li>Maximize work not done </li></ul><ul><li>Just-in-time decisions </li></ul><ul><li>Adapt to change </li></ul>
    7. Scrum
    8. Extreme Programming (XP)
    9. Others <ul><li>Evo </li></ul><ul><li>RUP </li></ul><ul><li>... </li></ul>
    10. PART 2: Organization Agile Techniques
    11. Short Iterations <ul><li>Scrum suggests 30 days; XP 2 weeks. </li></ul><ul><li>We tried both, and we're doing 2-week iterations. </li></ul><ul><li>Each iteration attempts to create a true vertical slice . </li></ul><ul><li>Use results to feed into next iteration. </li></ul><ul><li>Yes, you can do a lot of work in 2 weeks (hard to believe at first). </li></ul>
    13. Scheduling <ul><li>Customer == Person who cares about the ultimate outcome of what the team produces. </li></ul><ul><li>Customers come up with priorities. </li></ul><ul><li>Team estimates how long things will take and signs up for most important tasks in available time. </li></ul><ul><li>Conversation between customer and team. </li></ul>
    15. Team Composition <ul><li>Small teams (8-12 people). </li></ul><ul><li>Collocated in open work environment. This is huge for quick discussions and communication. </li></ul><ul><li>Originally only programmers; now, totally cross-functional. </li></ul><ul><li>Scrum of scrums to scale to larger team sizes. </li></ul>
    16. Who Does What <ul><li>Tasks are created and estimated by team </li></ul><ul><li>People pick whatever task they want to work on </li></ul><ul><li>Great for morale and spreading knowledge </li></ul><ul><li>Careful how to deal with domain experts </li></ul>
    17. Long-Term View <ul><li>We create working software instead of documents. </li></ul><ul><li>Important to be in total agreement with publisher. </li></ul><ul><li>Try your publisher. They may resist change at first, but then they realize they get to have more say in your project. </li></ul><ul><li>Backlog </li></ul><ul><li>Long-term planning; three-month release cycles. </li></ul>
    19. PART 3: Programming Agile Techniques
    20. Pair Programming
    21. Pair Programming <ul><li>Is output 2× of what one programmer can do? Not quite. </li></ul><ul><li>It's a bit less (1.6 - 1.8×), but it also has other huge benefits: </li></ul><ul><ul><li>Much higher quality </li></ul></ul><ul><ul><li>Spreads knowledge & philosophy </li></ul></ul><ul><ul><li>Promotes team spirit </li></ul></ul><ul><li>In the long term, it is a huge win </li></ul>
    22. Pair Programming <ul><li>Not everybody likes it, but a very large number of programmers do. </li></ul><ul><li>Some teams use it almost all the time; some other teams not as much. </li></ul><ul><li>Another benefit: Intensity and concentration. You never have low moments, little breaks, or anything. You work 8 hours and you end up exhausted! </li></ul>
    24. Test-Driven Development Check in Check in Write test Write code Refactor
    25. Test-Driven Development <ul><li>Quick idea: test-code-refactor cycle </li></ul><ul><li>All code unit-tested; written by programmers </li></ul><ul><li>Design methodology </li></ul><ul><li>Much easier to refactor/optimize </li></ul>
    26. Test-Driven Development <ul><li>Unit tests are: </li></ul><ul><ul><li>Small </li></ul></ul><ul><ul><li>Self-contained </li></ul></ul><ul><ul><li>Fast </li></ul></ul><ul><li>Code doesn't have to be written with the future in mind. </li></ul><ul><li>Instead, we can change when/if the time comes. Huge win! </li></ul><ul><li>Never refactor for its own sake; always because we want to do something. </li></ul>
    27. Test-Driven Development <ul><li>Get a unit-test framework (UnitTest++) </li></ul><ul><li>Running on the Xbox 360 is a bit more challenging, but do-able. </li></ul><ul><li>Need to be able to run a program, capture its output, and return code. </li></ul><ul><li>Xbrun should really do it. </li></ul>
    28. Continuous Integration <ul><li>Many small, very frequent check-ins (maybe every 3-5 minutes) </li></ul><ul><li>As soon as any code is checked-in, build is triggered </li></ul><ul><li>People are notified right away of any failed builds </li></ul><ul><li>Unit tests are very useful for keeping things stable </li></ul><ul><li>We use CruiseControl.Net—it's great! </li></ul>
    30. Continuous Integration <ul><li>House rule: Nobody leaves without making sure his last check-in resulted in a successful build. </li></ul><ul><li>The faster your builds, the better; so, pay attention to logical and physical dependencies (feedback time for normal checkins is around 10-20 seconds). </li></ul><ul><li>Much slower for Unreal projects. </li></ul>
    31. Collective Code Ownership <ul><li>Really means collective code ownership, not &quot;no code ownership&quot;. </li></ul><ul><li>Anybody is free to modify any code as long as it's because they're working on it. </li></ul><ul><li>Really relies on unit tests and shared knowledge. </li></ul>
    32. Sustainable Pace <ul><li>What's one of the big problems in the industry? Crunch time. </li></ul><ul><li>Work as hard as you can, thinking of the long term. That means about 40-hour work weeks. Intense 40 hours, though! </li></ul><ul><li>People come back refreshed and ready to do work. </li></ul><ul><li>They also have the time to learn things outside of work and feed that knowledge back into work. </li></ul>
    33. Automated Tests <ul><li>Unit tests from TDD are huge, but only part of all the automated tests. </li></ul><ul><li>Functional tests: Test whole program or parts of it. </li></ul><ul><li>Fully automated. Run them on the build server at least once a day. (We have them running every couple of hours.) </li></ul><ul><li>Run them on your target platforms as well. </li></ul><ul><li>Great for testing systems involving multiple threads </li></ul>
    34. PART 4: Lessons Learned
    35. How Is It Working? <ul><li>We're discovering the important stuff first </li></ul><ul><li>Much-improved code quality </li></ul><ul><li>More robust builds </li></ul><ul><li>People are really happy </li></ul>
    36. What Can Be Improved? <ul><li>Team composition </li></ul><ul><ul><li>How many resources are shared </li></ul></ul><ul><ul><li>How to fully integrate people with different ways of working and thinking (programmers, artists, designers) </li></ul></ul>
    37. What Can Be Improved? <ul><li>Team self-organization </li></ul><ul><ul><li>Big goal of scrum. We’ve made lot of progress, but it can be taken a step beyond. </li></ul></ul><ul><ul><li>Team needs to realize they're empowered to do whatever it takes to get their tasks done. </li></ul></ul><ul><ul><li>Sometimes some leadership will still be needed </li></ul></ul>
    38. What Can be Improved? <ul><li>Non-productive time </li></ul><ul><ul><li>Scrum recommends 1 day for reviews and 1 day for planning. </li></ul></ul><ul><ul><li>That's 2 days out of 10 “wasted”; even worse with multiple teams. </li></ul></ul><ul><ul><li>We recently changed things to minimize down time, and we do reviews and planning on the same day. </li></ul></ul>
    39. Adopting Agile Development <ul><li>We have customized a lot of the standard scrum rules to fit game development. </li></ul><ul><li>However, it's best to start with the default rules, try them in earnest, and go from there. </li></ul><ul><li>Tweaking too many rules from the start can lead to wasted time and failed attempts. </li></ul><ul><li>XP was easy to adopt without any major changes. </li></ul>
    40. Resources <ul><ul><li>Games from Within </li></ul></ul><ul><ul><li>http:// </li></ul></ul><ul><ul><li>Agile Game Development http:// </li></ul></ul>Questions?
    41. © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. DirectX Developer Center Game Development MSDN Forums Xbox 360 Central XNA Web site End Slide August 14-15, 2006