Agile Modeling (AM) is a PracticesBasedProcess
that describes how to be an effective modeler. Current modeling approaches can often prove dysfunctional. In the one extreme, modeling is non-existent, often resulting in significant rework when the software proves to be poorly thought through. The other extreme is when excessive models and documents are produced, which slows your development efforts down to a snail's pace. AM helps you find the modeling sweet spot, where you have modeled enough to explore and document your system effectively, but not so much that it becomes a burden that slows the project down.
applied to modeling: A model should be as simple as possible, but no simpler.
The techniques of AM can and should be applied by project teams that wish to take an agile approach to software development, in particular those that are following an agile process such as eXtreme Programming (XP), DSDM, SCRUM, or FDD. AM can also be used to improve and often simplify your modeling efforts on projects where you don?t take a purely agile approach.
The extreme-modeling link is no longer available.
New name for ExtremeModeling
plans by ScottAmbler
It's funny, I think that calling ExtremeModeling AgileModeling
would probably help to sell it better. What about AgileProgramming
? OK, maybe not the best, but definitely less controversial than ExtremeProgramming
. (Please note that I don't actually care about these names. I'm just pointing out how changing the name sells the product... silly isn't it?)
is great. It is a wonderful feeling when are new to a client site, have no login, have no access to the net, no access to a copier, but after interviews and code reviews have a good chunk of their system written on CrcCard
s. You know that when you get the administrative nonsense done, then you will hit the ground running.
Is this one of the AgileProcesses by the AgileAlliance?
No, it is not one of the ones originally discussed at the Snowbird meeting. However, the intention of the AgileManifesto
is that more than just the original authors can subscribe to the AgileProcesses
concept and claim to be Agile
. The key is the four values in that manifesto:
individuals and interactions
responding to change
", per se, produce working software ?
It seems to me that AgileModeling
relies on a set of assumptions:
- A change in a model is quicker than a change in code
- Changes in the model can cheaply be implemented in the code
- Simple relationships are more understandable in a figure than in code (possibly: - especially for novices)
- Complex relationships are more understandable in a figure than in code (possibly: - especially for novices)
- Time spent improving (ReFactoring) the code could better be spent drawing models of the code.
I have not seen a set of assumptions like this anywhere, so I don't know how accurate this list is. At any rate: How well does these assumptions match up with observations on real projects? -- JohannesBrodwall
The problem I usually see is that the truly complex interactions that you find in the code are not represented in the model. I find models useful in representing sections of existing code I need to understand, often relationships between classes. I do not find them useful as a planning tool for code. --WayneMack
These seem to be assumptions of modeling in general. An AgileModeling
assumption would be that models are never complete, and hardly ever accurate, so it's better to stick with an incomplete model (that helps understanding the problem), than trying to create a fully detailed (and probably inaccurate model). -- GustavoSousa?
As always, the usual myth put forward that modeling is all about visualising code. Isn't this good evidence of an unhealthy FocusOnCode
I would also contest that it is evidence of an overly complex design or system.
see also TestDrivenAnalysisAndDesign