Universidad del Valle de Guatemala
DZBall Development
WITH EXTREME PROGRAMMING AGILE
PROCESS METHODOLOGY
Team Members:
Luis Carlos Aldana 08261
David Hsieh 08225
Eduardo Mejicano 08058
17/03/2009
DZBALL DEVELOPMENT WITH EXTREME PROGRAMMING (XP)
AGILE PROCESS METHODOLOGY
The project DZBall a mobile phone java based game, is being developed with the Agile
Process methodology eXtreme Programming (XP), since it covers all our needs, our
limited resources and small team meets the requirements, and it’s the most efficient
methodology we reviewed for game development.
Whole Team
Since our team is made up of three people, the whole team factor of the XP
methodology fits best, because every member works in a whole team, every single
member has the same picture or idea about the project, which satisfies the communication
aspect. There will also be a member who plays the customer role; in most cases it’s a
business representative who will define the features, priorities, tests and requirements of
the product. This “customer” will communicate with the developers and the rest of the
team, so that they can all develop and work in base of a customer needs.
Test-Driven Development
Every software has at least a bug and more when it’s still on development, and these
bugs are more noticeable on games, which is our case. Test-Driven Development means
that during our development, our developers must make a test just after writing a
feature’s code, so that the developers have a feedback on their and whole project’s
progress.
Small Releases & Customer Tests
Because DZBall will be a videogame, it’s exposed to not visible bugs by the team coders
and testers, but also we don’t know if people will like the game. To take care of these
problems, there methodology suggests making not few releases, but a small release in
each single feature or set of small features developed and implemented on the
application, in this case would be the game. Since there will be a release in each
implemented feature, the customer will be able to try each new feature of the
application, so the not seen by the team bugs would be reported, and also we will know
what the customer thinks about the new feature.
PROJECT PLANNING
Task Start End Duration
Project Modeling 16/March 2009 01/April 2009 13 days
Code development * 02/April 2009 05/May 2009 24 days
Unit tests 06/May 2009 18/May 2009 9 days
Installation and 19/May 2009 26/May 2009 6 days
testing on mobile
device
Application testing 27/May 2009 08/June 2009 8 days
and bug corrections
Final project 08/June 2009 08/June 2009 1 day
presentation
*There will be a code test during the code development after making each feature.
This planning may be modified according to development changes.