Agile Development Best Practices: Model Storming

Guide:
A new article: VB.net and C # comparison | Old one: MFC Hyperlink control classes
Original English: Http://www.agilemodeling.com/essays/modelStorming.htm
　　
Model storming is a real-time modeling approach: You find a problem to solve, you immediately grab a handful of teams that can help your colleagues, the team work together to solve the problem, and then everyone will continue working like just now. This is a common thing for agile projects. Use extreme Programming to call this a stand-up design meeting (stand-up) or a customer's question and answer session (Customer Q&a sessions), and is also common in traditional projects. It's time we started discussing model storm, and we can find some way to make this process better.
My experience is that most modeling meetings should have only a small number of people involved, typically 2 to 3 people who discuss the problem and sketch the grass on a paper or whiteboard. These model storming sessions are basically an impromptu thing, a project team member to let another person to model with him, in general, about 5-10 minutes (model storm almost rarely more than 30 minutes). People are working around shared modeling tools (such as whiteboards) to explore until they are satisfied with the problem, and then they continue to work (often coding).
　　 Analysis Model Storming
You will use model storm to analyze the requirements. For example, a project-related person may tell you that the system you are building must be able to edit the student's information (translator: a vulgar example). Set up a sketch with the team members and see Figure 1 on the screen. A lot of examples have been drawn until you understand what you need to build. This sketch is a inclusive models because you use simple tools and modeling techniques that will allow project-related people to participate in agile modeling practices.
　　 Figure 1. Screen sketches.
　　
　　
　　
　　 Design Model Storming
Agile developers, including Xper. When they have chosen a need to complete, generally do not directly to encode (and the agile development of the detractors tell you the contrary, translation: foreigners also infighting). This is because model storming is also used for architecture and design. Java programmers often sketch a UML sequence diagram before writing complex code (see Figure 2), Xper will establish CRC cards (Class responsibility collaborator) on the index card (see figure 3 to reveal some details of structural design, VB programmers may choose to draw a flowchart (flow charts) to model a complex business rule (see Figure 4). No matter what model you build, you've been modeling storming.
　　 Figure 2. Service-level sequence diagram.
　　
　　
　　
　　 Figure 3. Hand-drawn CRC Cards. Figure 3. Hand-drawn CRC Cards.
　　
　　
　　
　　
　　 Figure 4. Flowchart for enrolling in the University.
　　
　　
It's important to understand that model Storm doesn't have to be on a whiteboard, you just need a shared, inclusive tool (inclusive tool) that makes it easy to work together. For example, the CRC card (Figure 3) is written on the index card rather than on the whiteboard.
　　 Why dose this Work? (Why do you do this)
Why model storming this kind of real time work better than trying to design everything beforehand (model everything up front)?
There are many reasons:
1. Whether we like it or not, the requirements are always changing throughout the project.
2. Wait until you need to analyze the details, and you have more domain knowledge than you did at the beginning of the project. For example, if a requirement is to be added to the project and implemented within three months, the details of the study of some requirements if you have three months of domain knowledge will be more than the beginning of the project, so you can ask more intelligent questions.
3. If you have a regular delivery of your software, the project stakeholders will have three months experience in the use of the system. In other words, they can give you better advice.
4. Prior design details often result in a huge waste of money. Yes, although in agile development, in the No. 0 iteration you want to do some conjecture of initialization requirements and some assumptions about initialization architecture, they don't mean you need to jump into the details of the swamp.
That being said, when modeling complex requirements or modeling legacy systems (Legacy), you sometimes need to implement some design beforehand. This rarely happens (regardless of what the traditional modeler might expect from this sort of thing), but occasionally. (This is actually a rare occurrence, regardless of what traditional/May modelers for, hope it but does happen so every En.)
　　 adopting Model storming
How to recommend model storming in your work environment? First of all, the more whiteboard space the better. Some companies are reluctant to go to the whiteboard, and apparently they are more concerned with interior décor, such as an attractive printed thing on the wall, which is more important to them than the more efficient work of another software development team. My advice is not only to have a lot of whiteboard available for people to use, but also to determine if they can see it when they turn their backs to the workspace, which makes it easier for them to work with the Whiteboard.
You may need to make a protocol for using the whiteboard, especially if you want to erase something. Your team culture also has an important role to play in your success, and the team must be able to accept other people asking for help and be able to model with others. You need to realize that this is normal and effective working methods. I can't remember the project when we didn't use model storm, nor did I remember reading or writing a lot of details about the technology. Wouldn't it be more exciting if the IT industry started talking about what we actually did in practice instead of thinking we should do something?
　　
The level of translation is very limited, there are improper places please correct me, reproduced please specify the translator: Li Xin
　　

This article turns from
Http://blog.csdn.net/smalllixin/archive/2007/11/16/1888049.aspx