I am used to making an architecture plan during the start of the project. In an Agile Process it seems that the architecture are being done or improved during the iterations.
Agilists disagree about planning and architecture. XP tends to advocate no (or little) architecture up-front (i.e., planned design), but people like Martin Fowler say they do planned design maybe 20% of the time. Chapter 14 of XP Explained (Kent Beck) has a nice articulation of the XP design philosophy.
Michael Keeling has a good explanation about why agilists (and others) disagree. He says to pay attention to two dimensions: your knowledge about solutions and your knowledge about problems. When you know lots about solutions in this field (e.g., web systems), then you are more likely to defer planning. But when nobody has ever built a Mars Rover before, you do more planning. To me, this explains why engineers in different situations do different things, yet what each does is rational.
Chapter 3 of my book on software architecture is devoted to answering the question "How much architecture should you do?" In brief, the answer is "Do architecture until risks fall off your radar". If you're not worried about scalability or security, don't bother planning those. But if you're worried about auditability (e.g., regulatory compliance) then work on it until you think you've got it handled, or can handle it using evolutionary design. That chapter is available for free download.
If you're being agile, you should avoid shoving lots of up-front design into an Iteration Zero. Put another way, if your Iteration Zero is three months of design, you are not really very agile.
Your question is specifically about architecture models -- just one of the things that you would do in planned design. Models are a means to an end (the end being a running system). Used well, they can help you reduce risks, but nobody will be happy at the end of the project if you have a great model and no system.
Lately I've been a lot into agile methodologies. Some papers I've read at Martin Fowler's website looked thoroughly unflawed to me to say the least, and I was wondering what agile practices are most suited to game development, particularly for small-budget, small-sized and inexperienced team projects (bold because it's really important).
Concepts such as refactoring look like they could absolutely combine with a small and inexperienced team. The idea of "embracing the change" also combines with inexperienced teams whose ideas twist and turn all the time. But things like TDD are rather problematic.
It's hard and suboptimal to test a class that interacts with Direct3D, for example. It doesn't make much sense.
I'd be most deeply grateful if you could list a bunch of practices that made sense for game development. Ones that aid in the organization of artistic production are a plus. Citations of real-world cases are another plus.
Thanks in advance.
Plus, my team is composed of 3 people: one programmer, one graphics designer and one programmer/graphics designer combomix. We do not have a client, so we must make all decisions alone.
I've read in an article by Fowler that agile sort of depends on developer-client interaction, but he also mentioned that clients unwillingly to adhere to agile could still be well-served by agile development (the article was called New Methodology). How does that apply to my case?
I think questions at StackOverflow can help others too, so I'll try to summarize my thoughts on the subject here.
Through the use of mock objects, even hard-to-test elements such as graphics interfaces and their relationship to client classes might be manageable.
For example, instead of letting every client of the interface truly test its use under many conditions (fullscreen/windowed mode switch, for example, which affects almost everything in the game), they could be tested against a mock that seemingly to them behaves the same as the original class, and additionally test that mock's fidelity to the original object.
That way, the slow part (actually opening the window and stuff) is only done once in checking the mock's fidelity to the implementation, and everything else just run smooth over the mock. [thanks to Cameron]
A BDD mindset aids at easening the paranoid seek for thorough testing of units, "replacing" testing by specification of actual behaviours, not squeezed units which in many cases are better off let untested (or only indirectly tested, if you prefer putting it that way) to avoid too much one-to-one test vs. unit (class, method, variable, etc) parity, which adds to test (now "specification") fragility. [thanks to Kludge]
You definitely want to look at Extreme Programing (XP), take a look at Kent Beck's Extreme Programming Explained: Embrace Change, 2nd Edition
The most useful thing you can do though is to do some research on Behaviour-Driven Development which is basically Test-Driven Development done right. It takes the focus off of tests and back onto specifications. You don't worry about what classes do so much as what behavior your program exhibits.
So saying you aren't going to use TDD, or BDD, is just plain crazy talk. One of the core concepts of Agile development is developing your software from your tests/specs. You have to get out of the mindset that tests/specs are testing your classes. That's not really what they're for. They are for describing the behaviors your application should exhibit then using that test/spec to write the behavior into your application.
You might write something like this
Describe Startup it "should display a welcome screen" do game = Game.new game.start game.output_buffer.should match("Welcome") end end
Then you go write the code to make it happen. You describe the code you want, then you go write it. It allows you to write your code in little, bite sized chunks and best of all when someone else picks up your code they can run the tests and see that everything works. When they want to add new functionality they use the same process so now when you go back to the code you can have faith that their code works too.
Reading the XP book, I have a condtradiction in my mind that I cant address and am wondering if you guys can help.
XP says write stories on index cards, assign those to a developer, have her estimate how long the task would take and then use pair programming to do the coding bit.
So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?
I am preparing a presentation. My topic is innovative software engineering methodologies. Agile is modern and innovative methodology but is the answer just Agile? What are the other innovative and modern methodologies? Are test driven development and behavior driven development also innovative methodologies? And eXtreme Programming is traditional methodology like waterfall?
I am not sure we can categorize these methodologies or frameworks as innovative, traditional or something else.
The choosing for a methodology or framework is completely depend on the product and customer needs. Any of them that meet the product requirements and provide efficiency to your team can be innovative in that scope.
Most of the software development process is developing complex products in complex environments in today's development World. I totally agree that agile methodologies, extreme programming, TDD and BDD are matches very well to the before definition of developing complex products in complex environment. Therefore, most of the agile methodologies are inspection of developing complex products.
The term agile is a really popular term used by software development professionals. There are lots of agile methodologies, frameworks like scrum, kanban or XP. They suggest methods to use to make us agile. The term agile is all covers these methods. Most of them solves the prediction, adaptation, transparency, inspection and empirical processes. All agile methodologies try to solve these problems faces during software development.
Extreme programming focuses on developing qualified software products and adopting to changing requirements and environment. Honestly, I really like XP. It does not suggest only development methodologies. It also suggests some about customer management, cost management etc. It is really basic, but hard to implement. I highly suggest to read the book Extreme Programming Explained by Kent Beck.
See Also :
Scrum is another framework for software development based on empirical process control: transparency, inspection, and adaptation. It is really simple and defines some role and event during software development. The roles are Scrum Master, Product Owner and Development team. The events are Sprint Planing, Daily Scrum, Sprint review and Sprint Retrospective. I suggest to read Scrum guide for further information.
Test Driven Development
Test driven development is a software development process. I can not say that it is an agile methodology itself. It helps software development to be agile. Test driven development support developers to test in the first phase. Test driven development also requires a mind set to think test before every development. It is not only writing unit test.
It is another software development process and emerged from test driven development. It focuses on the cross team like development, management and customer have shared tools and shared processes to have the same understanding of the requirements. BDD suggest that business people, customer and technical teams should have same understanding for the product. Customer requirements, lets sat customer sentences, can be automatically tested by the tools.
The term Agile itself is missing without XP, Scrum, Kanban or any other methodology or framework. Any agile methodology or framework is also missing without TDD, BDD or Continuous integration. Any of these items must be supported by company culture, customer or business people. Every stakeholder in the project should have the mindset for product over project. Otherwise, Agile methodologies may not be helpful.
As a last word, I highly suggest to get well understanding of continuous integration.