Model storming: an agile Best Practice

Document directory

• Analysis Model storming
• Design Model storming
• Why does this work?
• Adopting model storming

Model storming is just in time (JIT) Modeling: You identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group names es the issue, and then everyone continues on as before. it usually common on agile projects, EXtreme programmers (xpers)Call it a stand-up design session or a customer Q & A session, and it implements clearly common on traditional projects as well. everyone model storms at some point and I think that it uses about time we started talking about it so we can find ways to get even better at it.

My experience is that the vast majority of modeling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These modify odel storming sessions? Are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (it usually rare to Model Storm for more than thirty minutes ). the people get together, gather around a shared modeling tool (e.g. the Whiteboard), emerge e the issue until their satisfied that they understand it, then they continue on (often coding ).

 

Analysis Model storming

You will model storm to analyze requirements. for example, a stakeholder may tell you that the system you need E building must be able to edit student information. together you create a sketch of what the screen will look like, seeFigure 1, Drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this areInclusive modelsBecause you need E using simple tools and modeling techniques, this enabling the agile modeling (AM) PracticeActive stakeholder participant. Note that you may also have created a model such as this as part of yourIteration ModelingEfforts, the "Rules" aren't carved in stone.

 

Figure 1. Screen sketches.

 

 

Design Model storming

Agile developers, including xpers, don't need always go straight to code once they has e chosen to work on a requirement (contrary to what detractors of agile development will tell you ). this is because model storming is also very common for architecture and design. java programmers will often work through complex code by sketching a quickUML sequence di.pdf(SeeFigure 2), Xpers will createClass responsibility collaborator (CRC) cardsOn standard index cards (seeFigure 3) To implement e detailed structural design problems, and Visual Basic programmers may choose to drawFlow ChartsTo model a complex business rule (seeFigure 4). Regardless of the model (s) that you need to create, you're still model storming.

 

Figure 2. Service-level sequence digoal.

 

 

Figure 3. hand-drawn CRC cards.

 

Figure 4. flowchart for enrolling in the university.

It's important to understand that you don't require a whiteboard to model storm, you just need a shared,Comprehensive ToolThat people can work with easily. For example, the CRC cardsFigure 3Are written on index cards, not drawn on a whiteboard.

 

Why does this work?

Why does model storming on a JIT basis work much better than tryingModel everything up front? For several reasons:

1. TheRequirements are going to changeThroughout the project, like it or not.

2. By waiting to analyze the details JIT, you have much more domain knowledge than if you had done so at the beginning of a project. for example, if a requirement is to be implemented three months into a project, if you need e the details of that requirement at that point you have three months more domain knowledge than if you had done so at the beginning of the project, therefore you can ask more intelligent questions.

3. If you 've been delivering working software on a regular basis your stakeholders now have three months worth of experience with the system that you 've ve built. in other words, they can give you better answers.

4. Modeling everything up front in detail appears to result in significant wastage. Yes, during iteration 0 you'll want to do someInitial requirements envisioningAnd someInitial architecture envisioningBut that doesn't mean you need to dive deep into the details.

Having said that, sometimes you'll need to model complex requirements, orModel legacy assets,A bit ahead of actually implementing them. This is actually a rare occurrence, regardless of what traditional modelers may hope, but it does happen every so often.

Adopting model storming

How do you support model storming within your environment? First, the more whiteboard space the better. some companies are reluctant to put up whiteboards, apparently interior decorating concerns such as having attractive prints on the wall is far more important to them than making software development teams valid tive. my advice is to not only have a lot of whiteboard space available to people, you also need to ensure that it should be visible to people once they should e back at their workstations so that they can easily work from them.

You need l need to develop a protocol for working onWhiteboards, Maid it needed OK to erase something. your team culture is also critical to your success, it must be acceptable to ask people for help and in turn to be asked to model with others. you need to recognize that this is a normal and valid tive way to work. I can fetch remember a project where we didn modeling Model Storm, yet I also can fetch remember reading a book or article which talked about this technique I N any great detail. Wouldn should it be nice if the IT industry cocould start talking about what we actually do in practice, instead of what we think we shoshould be doing?

 

This article from: http://www.agilemodeling.com/essays/modelStorming.htm