An Introduction To Agile Development

3,884 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,884
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
156
Comments
0
Likes
4
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>
    12.  
    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>
    14.  
    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>
    18.  
    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>
    23.  
    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>
    29.  
    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:// www.gamesfromwithin.com </li></ul></ul><ul><ul><li>Agile Game Development http:// www.agilegamedevelopment.com </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 http://msdn.microsoft.com/directx Game Development MSDN Forums http://forums.microsoft.com/msdn Xbox 360 Central http://xds.xbox.com/ XNA Web site http://www.microsoft.com/xna End Slide August 14-15, 2006

    ×