Agile agile modeling ideology
Lin Xing (reprinted from Agile China Site) September 15, 2003
Agile modeling ideas are composed of the following series of articles:
1 Agile Modeling Value 2 Agile Modeling Principles 3 Agile Modeling Practice 4 Agility Modeling is (not)? 5 When is the model agile? 6 Are you in agile modeling? 7 When is agile modeling? How is the Practice of 8 AM? 9, do you want to be an agile modeling? 10 modeling misunderstandings
Agile modeling values
The value of AM includes four values of XP: communication, simple, feedback, courage, and, in addition, the fifth value: humility. Communication. Modeling not only promotes communication between developers within your team, but also promotes your team and your Project Stakeholder communication.
Simple. Draw one two charts instead of tens or even hundred lines of code, through this method, modeling into the key to simplifying software and software (development) processes. This is very important for developers - it is simple, easy to find new ideas, and it can be easily improved as you (on software) understanding.
Feedback. Kent Beck is very good in Extreme Programming Explained: "Optimism is a professional disease. Feedback is its prescription." Through the chart to communicate your thoughts, you can quickly get feedback, and can act in accordance with the recommendations .
Courage. The courage is very important. When your decision has proved to be inappropriate, you need to make a major decision, give up or refactor your work, fix your direction.
Humility. The best developers have modest virtues, they can always realize that they are not ignorant. In fact, whether developers or customers, and even all Project Stakeholds have their own professional fields, they can contribute to the project. An effective approach is to assume that everyone who participates in the project has the same value and should be respected.
Principle of agile modeling
Agile Modeling (AM) defines a series of core principles and auxiliary principles, which laid the cornerstone for modeling practice in software development projects. Some of these principles are drawn from XP, and they have their detailed description in Extreme Programming Explading. Some of the principles in XP are also known from well-known software engineering. The idea of multiplex is everywhere! Basically, this document describes how these principles focus on how they affect modeling work; this, for these principles of XP, we can look at another angle.
Core principle:
It is easy to advocate. When working in development, you should advocate the easiest solution is the best solution. Don't overcome overbuild. The use of AM is that if you don't need this additional function now, don't add it in the model. There is such courage: You don't have to model this system, as long as it is modeled based on existing needs, the future demand is changed, and then refactoring this system. The model is as simple as possible.
Hug changes. Demand is changed, and people's understanding is also changed. In the project, Project Stakehold may change, there will be newcomers to join, and the old people will leave. Project Stakeholder's views may also change, and your efforts and success standards may also change. This means that as the project progresses, the project environment is constantly changing, so your development method must be able to reflect this reality. Your second goal is sustainability. Even if your team has delivered a system to users, your project may also fail - to implement the demand for Project Stakeholder, including your system should There is enough robust to adapt to future expansion. Just like Alistair Cockburn, when you are developing a software development, your second goal is to prepare the next game. Sustainability may refer to the system's next primary release, or the operation and support of the system you are building. To do this, you don't just build high quality software, but also create enough documents and support materials to ensure that the next game can be effectively carried out. You have to consider a lot of factors, including your existing teams that you can also participate in the next game, the next game environment, the next game is important to your organization. Simply put, you have to imagine the future when you are developing.
Increasing changes. An important concept related to modeling is that you don't have to prepare everything at the beginning. In fact, you don't want to do this. Moreover, you don't have to include all the details in the model, you will be enough for your details. There is no need to try to build a model that encompasses all the models at the beginning, you only need to develop a small model, or a profile model, let a foundation, then slowly improve the model, or discard this model when it is not required. This is the incremental idea.
To maximize Stakeholder. Your Project Stakeholder needs to invest time, money, equipment and other resources in order to develop software that meet yours. Stakeholder should choose the best way to invest, or ask your team to not waste resources. Also, they have the final say, decide how much resources have to be invested. If these resources are yourself, do you want your resource to be misuse?
It is a purposeful modeling. For your own Artifact, such as models, source code, documentation, many developers are not worried about whether they are enough, is worried whether they are too detailed, or worry about whether they are enough. You shouldn't model meaningless, you should ask first, why do you want to build this artifact, who is to build it. And modeling, maybe you should learn more about the software, maybe in order to ensure the smooth progress of the project, you need to communicate your way with the senior manager. Maybe you need to create a document describing the system, so that others can operate , Maintenance, improvement system. If you have modeled, it is unclear for who is modeling. Why do you have to continue trouble? First, you have to determine the purpose of modeling and the audience of the model. On this basis, the model is guaranteed to be correct and detailed enough. Once a model implements the target, you can end the current work, transfer energy to other work, such as writing code to verify the operation of the model. The principle can also be applied to changing existing models: If you want to make some changes, you may be a well-known mode, you should have the right reason to make changes (may be to support a new need, or for weight Structure to ensure concise). An important suggestion about the principle is that you should know your audience, even if the audience is the same. For example, if you build a model for maintenance personnel, what do they need? Is the detailed documentation of the thickness of 500 pages is enough, or the total work of 10 pages is enough? Are you unclear? Go to talk to them, find out what you want. A variety of models. Developing software requires a variety of models, because each model can only describe the single aspect of the software, "What kind of model we need to develop now?" Taking into account the complexity of today's software, Your modeling toolbox should have a lot of useful techniques (About Artifact list, you can refer to the modeling artifact of AM). One thing is important, you don't have to develop all the models for a system, but should choose a part of the model for the specific situation of the system. Different systems use different parts of the model. For example, like the repair of the home, each job is not required to use each tool in the toolbox, but use a piece of tool. For example, you may like some tools, like, you will prefer a model. How much modeling artifact is available, if you want to know more details in this area, I list the relevant part of the UML in the Be Realistic About The UML. If you want to do a further understanding, please refer to White Paper The Object Primer - An Introduction To Techniques for agile model.
High quality work. No one likes to work. People who do this work don't like it because they don't have a sense of accomplishment; if you are responsible for reconstructing this work (for some reason) doesn't like it, it is because it is difficult to understand, it is difficult to update; end users don't like it, because it It's too fragile, it is easy to make mistakes, nor does it meet their expectations.
Quick feedback. From the beginning of action, the feedback between the action is taken, and the time between the two is critical. And other people develop models, your ideas can get feedback immediately, especially when your work uses shared modeling technology, such as basic modeling materials such as whiteboard, CRC card or instant posts. Work closely with your customers, understand their needs, analyze these needs, or develop user interfaces that meet their needs, so you will provide quick feedback opportunities. Software is your main goal. The main goal of software development is to create software that meets Project Stakeholder needs in a valid manner, rather than manufacturing unrelated documents, irrelevant artifact, or even unrelated models. Any activity (Activity), if it does not meet this principle, it is not contributing to the target, and should be reviewed and even canceled.
Lightly move forward. You build an Artifact and then decide to keep it, and these Artifacts need to be maintained over time. If you decide to retain 7 models, whenever, once there is a change occurred (new demand, the original demand update, the team accepted a new method, adopted a new technology ...), you need to consider Changes affect the effects of these seven models and take corresponding measures. And if you want to keep only 3 models, it is obvious that you have a lot of effort to make the same change, your flexibility is enhanced, because you are in a lightweight. Similarly, your model is more complicated, the more detailed, the change in challenge is poor, the harder it is, and each model is more "heavy", so the burden of maintenance is great). Every time you have to decide to keep a model, you have to trade out how much the information contained in the model is much beneficial to the team (so you need to strengthen the communication between the team, the team and the Project Stakeholder). Don't underestimate the seriousness of weighing. One person wants to think about the desert, he will take a map, hat, quality shoes, kettle. If he brought hundreds of gallons of water, he can imagine all the survival tools, a lot of books related to the desert, can he have to go to the desert? The same reason, a development team decided to develop and maintain a detailed demand document, a set of detailed analysis models, plus a set of detailed architectural models, and a set of detailed design models, then they will soon It is found that most of their time is not spent on the write source code, but spend on the update document. Supplementary Principles: Content ratio is more important. A model has many representations. For example, a user interface specification (basic / low precision prototype) can be created by placing instant post on a piece of paper. Its performance can be a sketch on paper or whiteboard, which can be established and conventional prototypes using prototype tools or programming tools, or a formal document including visual interfaces and text descriptions. One thing is interesting, a model is not necessarily a document. They usually use other Artifact inputs, such as source code, but do not have to handle them as formal documents, even the complex chart established using the Case tool, is the same. To realize a little, you should use the advantages of modeling, not to take energy on the creation and maintenance of documents.
Three people must have my teacher. You can't be completely proficient in a technology, you always have the opportunity to learn new knowledge and expand the field of knowledge. Grasp this opportunity, work with others, learn from others, try new ways to do things, think about what to do, what should not do. The change in technology is very fast, and existing techniques (such as Java) are improved in incredible speeds, new technologies (such as C # and .NET) are also regular generation. The improvement of existing development technologies is relatively slow, but it is also in sustained improvement - the computer industry is industrial, we have mastered the basic principles of the test, but we are still working, constantly practical, constantly improved Learn about it. We work in a change in the industry, we must work through training, education, thinking, reading, and with others to seize every opportunity to learn new things. Understand your model. Because you want to use a variety of models, you need to understand their advantages and disadvantages, so they can use them.
Know your tools. Software (such as mapping tools, modeling tools) has a variety of features. If you plan to use a modeling tool, you should know when it is suitable for use, when it is not suitable for it.
Local adjustment. Your software development method is capable of reflecting your environment, this environment includes organizational features, the features of Project Stakeholder, and the features of the project itself. Problems that may be affected include: You use modeling technology (maybe your users insist on see a detail user interface, not initial sketches or basic prototypes); you use tools (probably no digital camera Budget, or you already have a license of a CASE tool; you follow the software process (your organization uses XP development process, or RUP, or its own process). So you will adjust your method, this adjustment may be for the project, or it may be for your personal. For example, some developers tend to use a certain type of tool, some are not available. Some people are spending great effort in the code, basically do not moderate, and some will be in modeling more time in modeling.
Open honest communication. People need to be able to make recommendations, and people should also feel that they are free. It is recommended to be related to the model: Maybe some people put forward a new design method, or a new understanding of a requirement; it may also be some bad news, such as progress delays; or just simple work Status report. Open honest communication is a better decision, because information as a decision-making basis will be more accurate.
Using good people's intuition. Sometimes you will feel that there is a problem, or if you feel inconsistent, or something is not very right. In fact, this feeling is likely to be the fact. As your software development has increased, your intuition will become more ker, your intuitive consciousness tells you, it is likely to be the key to your work. If your intuition tells you that a need is meaningless, then you don't have to put a lot of energy and users discuss this problem. If your intuition tells you that some architecture can't meet your needs, you need to establish a fast technology prototype to verify your theory. If your intuition tells the design method A to be better than design method B, and there is no powerful reason to support you to select a method, then although the method A is selected. The value of courage has already told you that if your intuition is wrong in the future, you have the ability to save this situation. You should have this kind of confidence, it is important.
Agile modeling practice
Agile Modeling (AM) defines a set of core practices and supplementary practices on the basis of the principle of AM, some of which is already in extreme programming (XP) and in the Extreme Programming Explained book. With detailed discussion, like the principle of AM, we will focus on modeling process when describing this group, so that you can observe these or XP materials from another angle. Core practice:
The active participation of Stakeholder. We made an expansion of the on-site customer's concept: developers need to maintain their lives on site; the users must have sufficient permissions and capabilities to provide current construction System-related information; timely, pertinent decisions related to demand; and decide their priority. AM extension XP's "Live Customers" practice to "Positive Participation in Project Stakeholder", this Project Stakeholder concept includes direct users, their manager, senior manager, operator, support staff. This participation includes: Senior Manager Timely Resource Arrangement Decision, Senior Manager's public and private support, demand development phase operators and support staff, and their related models in their respective fields.
Use Artifact correctly. Each Artifact has their own applicable. For example, a UML activity map is suitable for describing a business process, in turn, the static structure of your database, it is best to use physical data or data model (Persistence Model). In many cases, a chart is more likely to play, a picture is better than a thousand words, and a model is much more useful than 1K source code, the premise is to use it (here the vocabulary in Karl Wieger's Software Requirements ). Because you are studying design, you can discuss with your companions and draw some charts on a whiteboard, or you can sit down to develop some code samples, and the former method is much more effective. . what does this mean? You need to understand the strengths and shortcomings of each Artifact, when you have a lot of models to choose, you can do this is not so easy.
Collective ownership. As long as there is a need, everyone can use, modify any model in the project, any artifact.
Testability thinking. When you are building a model, you will continue to ask yourself. "How do I test it?" If you can't test the software being developed, you should not develop it at all. During modern software, Quality Assurance activities run through the life cycle of the entire project, and some processes have put forward the concept of "writing test before writing software (this is a practical practice of XP" : "Test priority").
Create a model in parallel. Since each model has its strengths and weaknesses, no model can fully meet the needs of modeling. For example, when you collect demand, you need to develop some basic use cases or user materials, a basic user interface prototype, and some business rules. Combined with practice to switch to another Artifact, the agile modeling will discover the development of multiple models at all times, and more efficiently is more efficient than a model.
Create a simple content. You should make your model (demand, analysis, architecture, design) as simple as possible, prerequisites you can meet your Project Stakeholder needs. This means that unless there is a sufficient reason, you should not draw snakes on the model - if you don't have systematic authentication on your hand, you should not add such a function to your model. To have such courage, once you are asked to add this feature, you can do it immediately. This is the same as XP's practice of "simple design". Simply model. When you consider all the chart you can use (UML diagram, user interface diagram, data model, etc.), you will soon discover that most of you only need part of these chart symbols. A simple model can demonstrate the main features you want to understand, for example, a class diagram, as long as the relationship between the main responsibilities and classes of the class is already enough. Nice, the coding standard tells you to join the frame code in the model, such as all GET and SET operations, this is not wrong, but how much value can this provide? I am afraid I have little.
Open display model. You should display your model, the model of the model is called "Modeling Wall" or "Wall of Wonder". This approach can create an open honest communication between your team, you and your Project Stakeholder, because all models currently have a hand to them, you did not hide what they hide. You put your model to the wall of modeling, all developers and Project Stakeholder can look at the model of modeling walls, the wall of modeling may be objective, maybe a piece of architecture map for you. The whiteboard, or a print output of the physical data model, the wall of modeling may also be virtual, such as a Internet page of a picture that stores a scanned picture. If you want to know more about some related information, you can look at the Specifying Requirements with A Wall of Wonder of Ellen Gottesdiener.
Switch to another Artifact. When you develop an artifact (such as use case, CRC card, sequence diagram, even source), you will find your card case, this time you should consider temporarily switch to another Artifact. Every artifact has its own strengths and shortcomings, each artifact is suitable for a type of work. Whenever you find that you have a casing on an artifact, there is no way to continue, indicating that you should switch to another Artifact. For example, if you are making basic use cases, you have encountered difficulties when describing business rules, you should try to transfer your attention to other artifacts, maybe the basic user interface prototype, CRC model, may be Business rules, system usage, or change cases. After switching to another Artifact, you may not immediately stop the casing because you can continue working on another artifact. Moreover, by changing your perspective, you often find the reason why you originally enable your casing.
Small incremental modeling. In the way in incremental development, you can divide the big workload into small pieces that can be released, and each incremental control has prompted you faster within a few weeks or two months. Deliver the software to your users, add your agility.
It is modeled with others. When you have a purpose modeling, you will find that you can model something, it may be to communicate your thoughts with others, or build a common vision in your project. . This is a group activity, a activity that needs to work together to work together. You find that your development team must work together to build a set of core models, which is critical to your project. For example, in order to establish a system's image and architecture, you need to build all people agree with the same group, while maintaining its simplicity as much as possible. Most of the time, the best way is to discuss this problem with others. Use code to verify. Model is an abstraction, an abstraction that correctly reflects an aspect of the system you are building. But can it run? To know the results, you should use the code to verify your model. Have you already created a sketch for accepting payment address information in some HTML pages? Encoding it, showing your users to the final user interface and get feedback. Have you done a UML sequence diagram that represents a complex business rule logic? Write the test code, business code, and run the test to ensure that you are doing. Don't forget to develop software with iterative methods (this is the standard practice of most projects), and don't forget to model one of many tasks. Do a while to model, do coding for a while, and test (in other activities).
Use the simplest tool. Most models can be drawn on a whiteboard, on the back of paper, or even the paper towel. If you want to save these icons, you can take them with digital cameras, or just simply transcribed them into paper. This is because most charts can be thrown away. They only have valuable when you draw models and think about a problem. Once this problem is solved, they will no longer make sense. In this way, the whiteboard and tags tend to be the best choice for your modeling tool: use the drawing tool to create the chart, give you an important Project Stakeholder. Modeling tools are used only when modeling tools can provide our programming work (such as code automatically generated). You can think about: If you are creating a simple model, these models can be abandoned. The purpose of your modeling is to understand. Once you understand the problem, the model does not exist, so the model can be discarded, so that you don't have to use a complex modeling tool at all.
Supplementary practice:
Use modeling standard. This practice is to rename the encoding standard from XP. The basic concept is that developers should agree and abide by a common modeling standard in a software project. Compliance with common coding practices can produce value: Comply with your choice of code guidelines to write clean code, easy to understand, this is much better than the code that doesn't make it. Similarly, compliance with common modeling standards also have similar value. There are many currently available modeling standards, including the Unified Modeling Language (UML) developed by the Object Management Organization (OMG), which defines symbols and semantics to general-oriented models. UML opened a good head, but it was not sufficient - just like you see in Be Realistic About The UML, UML did not cover all possible modeling artifact. Moreover, it does not provide any modeling style guidelines on the establishment of a clear graphic chart. So where is the difference between style guides and standards. For source code, a standard may be that the specified attribute name must be in the format of AttributeName, and the style guide may truthfully in a single control structure (an IF statement, a cycle) code indent. For models, a standard may be modeling a rectangular pair type, a style guide may be below the parent class.
Entariance model. Efficient modeling will learn universal architectural mode, design patterns, and analysis mode, and apply them in the model. However, as Martin Fowler pointed out in Is Design dead, developers should easily use patterns, gradually apply mode. This reflects a simple values. In other words, if you guess a mode may apply, you should model this way: first realize the minimum range you need, but you have to leave a film for future reconstruction. In this way, you have realized a fever mode in a possible simplest way. That is, don't exceed your model. To give an example, in your design, you find that there is a place to use the GOF Strategy mode, but at this time you have only two algorithms to be implemented. The simplest method is too much to encapsulate the algorithm into a separate class, and establish an operation, and can select the corresponding algorithm and transfer the relevant inputs for the algorithm. This is a partial implementation of the Strategy mode, but you have buried a volk, if you have more algorithms in the future, you can refactor your design. It is not necessary to establish all frames because the Strategy mode needs to be established. This approach allows you to easily usage. Discard the temporary model. Most models of your creation are temporary models - design sketches, low precision prototypes, index cards, possible architectural / design, and more - you can't provide it after they have completed their purpose More value. The model will become unable to synchronize with the code, which is normal. You need to make a decision: If the "Synchronous Update Model" is able to add value to your project, then you will update the model; or, if you update their input will offset all the values you can provide (ie negative benefits), Then discard them.
The contract model is officially official. In your system, the information resources needed for external organizations, such as databases, old systems, and information services, you need a contract model. One contract model requires both parties to agree, according to time, the need to change each other as needed. Examples of the contract model include the details of the API, store form description, XML DTD, or a physical data model describing the shared database. As a legal contract, the contract model usually requires you to invest important resources to develop and maintain to ensure its correct, detail. Your goal is to try to make your system's contract model. This is consistent with the principle of XP. Note that you almost always need electronic tools to establish a contract model because this model is ready to maintain.
For communication modeling. The secondary reason for modeling is to communicate or establish a contract model for people outside of the team. Because some models give customers outside of the team, you need to invest time, use Case tools such as text processors, drawing toolkits, and even those "advertised to blow the sky" to beautify the model.
To understand modeling. The most important application of modeling is to explore problem space to identify and analyze the needs of the system, or compare and control possible design selection methods to identify, the easiest solution that may meet demand. According to this practice, you don't have to establish a small, simple chart, such as the lifecycle map, or screen order, which is usually discarded after you complete the purpose (understand) after you complete the purpose (understand).
Reuse existing resources. This is the information wealth that agile modeling can be utilized. For example, perhaps some analysis and design patterns are suitable for applications, maybe you can profit from existing models, such as corporate demand models, business process models, physical data models, and even how to deploy system in your user group. Model. However, although you often search for some correct models, it is true that in most organizations, these models don't exist, or they have expired. It is not until you have to update. You should update the model when you do need it, that is, when you don't update the price of the model exceeds the price paid by the update model. Using this method, you will find that the number of models you update is much less than before, because the truth is not that perfect model to provide value. My hometown's street map has been used for 5 years, and I have not changed the position in my own street in 5 years, so this map is still useful for me. Yes, I can buy a new map, the map is once every year, but why is it so troublesome? The lack of some streets did not let me suffer, I have to invest in a new map. Simply put, when the map is also used, there is no meaning to spend money to buy a new map every year. In order to maintain the synchronization between the model, the document and the source code, too much time and money have been wasted, and synchronization is unlikely. Isn't it better to invest in new software? Sure good idea:
The following practices are not included in the AM, but can be used as a supplement to AM:
Reconstruction. This is a code practice. Reconstruction is through small changes, allowing your code to support new features, or make your design as simple as possible. From AM's point of view, this practice ensures that you are clean and clear when you are encoding. Reconstruction is an important part of XP.
Test priority design. This is a development practice. Before you start writing your business code, you must first consider and write your test case. From the perspective of AM, this practice is forced to consider your design before writing code, so you no longer need detail design modeling. Test priority design is an important part of XP.
Agile modeling is (not)?
I firmly believe that when you describe things, you need to explain what it is, it is nothing. No matter what you talk about the system or the AM in the case. Here is my view of the scope of AM:
AM is an attitude rather than a descriptive process. AM is the values of agile models, and agile modeling, the principle of agile modeling, and the collection of agile modeling practices. AM describes a model of modeling. When it is applied to agile environments, it is possible to improve the quality and speed of development, while avoiding excessive simplification and unrealistic expectations. AM is not a "recipe", if you are looking for some details, such as establishing a UML sequence map or draw a user interface flow map, you can see many modeling books listed in Modifacts, I especially recommend my book The Object Primer 2 / E (although this is fair).
AM is a supplement to an existing method, not a complete methodology. The main focus of AM is in modeling, followed by documents. That is, the AM technology can improve the modeling effect on your team with agile methods (such as Extreme Programming, Dynamic Systems Development Method (DSDM), CRYSTAL CLEAR). AM can also be used in those traditional processes (such as unified process), although lower agility this process makes AM will not succeed.
AM is a way to work together to meet the needs of Project Stakeholder. Agile developers and Project Stakeholder team collaborate, they turned directly, active roles in system development. There is no "I" word in the "agile" dictionary. AM is effective and has started valid. When you learn more AM knowledge, there is something that may be bad for you, and AM is nearly ruthless attention to effectiveness. AM tells you: To maximize your investment in your Project Stakeholder; when there is a clear purpose, you need to establish a model or document when you need to solve the needs of the audience; use the appropriate workpiece to record your hand; no matter when you are as possible Create a simple model.
AM is from practice instead of ivory tower. AM's goal is to describe the technology modeling technology in an effective attitude, it is effective, enough for your work. I and my colleagues in Ronin International (http://www.ronin-intl.com) have applied a lot of AM technology to practice for many years. We ponder these technologies applied to a very broad customer, they are spread all over Industrial field. Moreover, from February 2001, hundreds of modeling experts have fully checked these technologies through the "http://www.agilemodeling.com/feedback.agilemodeling.com/feedback.htm). discuss.
AM is not a panacea. Agile modeling is an effective technique for improving many expert software development results. It's not a lot of money, you can solve all the problems you develop. If you work hard; if you focus on it; if you accept its values in your eyes, its principles, its practice; you can improve you as a developer.
AM is a general developer, but it is not to exclude people who have the ability. AM's values, principles and practices are simple and easy to understand, many of which may have been used or expected for many years. Applying AM technology is not going to practice water, but you need some basic software development skills. The most difficult AM is that it is forced to learn more wide modeling technology, which is a long-term, persistent event. Learning modeling may be difficult at the beginning, but you can try to learn the same techniques to complete your study. AM is not going against documents. Creation and maintenance of documents will increase investment in projects. Agile documents are as simple as possible, as small as possible, the purpose is only focused on the needs of the current system with the current system, fully understand the needs of the audience.
AM is not to oppose the Case tool. Agile modeling uses those tools that help developers improve their effects and improve value. Moreover, they also try to use the easiest tools that can be competent.
AM is not suitable for everyone. This will be discussed further in the articles listed below.
When is the model agile?
To learn about AM, you need to understand the difference between the model and the agile model. The model is an abstract concept that describes one or more aspects of a problem, or to process this problem possible solution. In the traditional sense, the model is considered to be a chart plus the corresponding document. However, it is not an intuitive Artifact, or it can be considered a model, such as a text description of the CRC card set, a single or multiple business rules, or a structured English description of the business process. A agile model is a model just enough. But how do you know when the model is just good enough? When the agile model shows the following characteristics, it is just good:
The agile model implements their purpose. Sometimes you model for communication, maybe you need to tell the senior manager range for your work; sometimes you model it, perhaps you need to determine a design strategy and implement a group of Java classes. Whether a agile model is good enough, to see if it satisfies the original intention of creating it.
Agile model is understandable. Agile models can be able to understand their expectations. Using the business language that users can understand, describe the demand model, in turn, technical architectural models require technical terms familiar to developers. The modeling symbol you use will affect the understandability - if your user does not understand the meaning of the symbol in the UML, the use case map does not have any value. In this case, either use another method, or teach users to learn modeling technology. Style problems also affect easy-to-understandability, such as avoiding cross wires. The messy chart is difficult to understand than a clear chart. The extent of the model (see below), which will also affect the understandability, because a more detailed model is difficult to understand because compared a non-detailed model. Simple (see below) is also a factor affecting understandability. The agile model is enough. The model usually does not require 100% correct, as long as it is enough. For example, if a street map is drawn, it is a street, or it indicates that a street is passing, but you find that it has closed repairs, then you will throw away your map to start in the city Crime? Not too possible. You will consider updating your map, you might take out the pen to make a modification or go to the local store to buy a new version of the map (your original expiration). Maybe you still accept the map that is not perfectly used, because it is already good enough for you. You can still use this map to turn around, because it is still a correct model, marking the location of most streets. When you find this map is incorrect, you didn't throw it away, because you didn't care about whether it was perfect. Similarly, when you find errors in the data model, you will choose to update or accept - although it is not perfect but is already good enough. Some project members can tolerate this incorrect and some can't: depending on the characteristics of the project, the characteristics of each team member, the organization's characteristics. Fully correctness is related to both the audience of the model, and is also related to the issues you have to handle.
When I was teen, I started working in a restaurant, and I started to wash the dish, and I came to get to get. When I made it, I have to learn how to check the store. One of the most important things in the store is to check the money cabinet. Teach me the store manager to determine that every penny of the money cabinet will be clear, if there is an entry, if the number of sales is going, it is necessary to repeat. Because not only you have to click on the banknotes, you have to clear the coins, so it takes average time for 20 minutes every night. A few months later, she transferred to another store and changed a new storeman. One night we went to the store, he saw me in a single coin, he was very surprised. He immediately demonstrated how the coin he was taking the same kind of coin, he looked at it, guess a value, as long as their total value is within a few dollars, he continues such a point. The 20-minute time was compressed to 5 minutes, because he thought that the number was approaching, and it did not need to be very accurate. He can go home 15 minutes a day, according to 6 nights a week, 50 weeks a year, he saves 75 hours a year, and his career has been 30 years.
The agile model is consistent. A agile model does not need to remain completely consistent with yourself (or other useful artifact). If an exemplary is explicitly called another case in its step, the corresponding example diagram needs to mark the relationship between the two use cases with the UML << include >> version. However, you look at the chart and find that they have not done this, God! The use case and the figure are inconsistent! Danger! Too dangerous! Red alert! Quick escape! Wait, your use case model is inconsistent, but it has not yet to the end of the world. Yes, Ideally, all of your Artifact is best consistent, but this is usually impossible. When I develop a simple commercial system, I usually can tolerate the inconsistency. But sometimes I can't tolerate this inconsistency. The most powerful agreement is a precise measurement system when NASA launches Mars Space Detectors in 1999. To establish a point of view, the agile model is just enough, you usually don't need to use such perfect models. Regarding the correctness and consistency, it is obvious to consider the problem. If you want to maintain an artifact (we call it "keeping"), with the passage of time, you need to put resources to update it. Otherwise it will expire, it is useless to you. For example, I can tolerate a mapped or two streets, but I am absolutely unable to tolerate three quarters of the streets in a map. This needs to be trade-off, carrying enough efforts to ensure that Artifact is enough. Excessive unnecessary efforts will slow down the progress of the project, and there is no way to ensure the effectiveness of Artifact.
Agile model has enough details. A route map does not need to mark each house on each street. That will have too many details, making the map difficult to use. However, when repairing the way, I want to build a detailed map of this street, including enough details of each building, sewer, wire box, etc., such a map is useful. But this map does not have to marke out each yard and the route to them. Because it is too cumbersome. Sufficient details and audiences are related to the purpose of their model - the driver needs to show the road to the road, the construction personnel need a map showing the details of civil engineering.
Consider an architecture model, possibly a group of pictures on the whiteboard is enough - the project is updated in progress, maybe you need to use the CASE tool to generate some charts, maybe these charts need to have a detailed documentation, this dependence Environment. Different projects have different needs. In every example, you are actually developing, maintaining a architecture model with enough details, just this "enough detail" concept and environment.
The agile model can provide positive value. Any Artifact in the project is that a basic requirement is that they can provide positive value. Is the value brought by an architecture model to your project to exceed the development of it, maintain it (optional) total cost? A architecture model can firmly strengthen your team's vision, so it is of course valuable. However, if its cost exceeds this value, that is, it can't provide positive value. Invested by $ 100,000 to develop a detailed, heavyweight documentation architecture model, and its utility, only some drawings on the whiteboard can be reached, these pictures need to spend $ 5,000, see, how is this? Overseas practice.
Agile models are as simple as possible. As long as you can achieve your purpose, you should try to keep your model as simple as possible. The extent of the model will affect the simplicity, while the symbol range used also affects the simplicity. For example, the class diagram of the UML includes countless symbols, including object constraint language OCLs, but most maps can be done in part of the symbol. So you often don't need to use all symbols, you can limit your use of symbols, of course, this subset is enough to let you work. So, the definition of a agile model is a model that implements it. It does not have a model of snakes; the model understands the model for your expectations; simple model; enough, enough, enough, detailed model; create and maintain its Investment can provide the project to provide a front value model. A universal philosophical problem is that the source code is a model, more important, it is not a agile model. If you ask me outside of our article, I will answer, yes, the source code is a model, although it is a highly detailed model because it is an abstraction of the software. At the same time, I also believe that excellent code is a agile model. But here, I also need to distinguish between the two, source code and agility models still distinguish - agile model helps you get source code.
Are you in agile modeling?
The biggest challenge faced by agile development methods is that developers claim to follow this method, and actually they don't do this. When they run a problem, they will blame the way, but they don't really follow these methods at all. There is such an example in extreme programming, some programming madly claim that they fully follow all principles of XP, but actually just what they have heard about XP's small part of the content, if you don't need so many documents . Their products are either poor, or they can't meet the actual user needs, but they will assassinate all the failures in XP, really unfair!
I really want to avoid such problems in AM, but this is just an ideal. In reality, I can only point out what the situation can be modeled in agility, nothing. Under what is agile modeling? Your customer / user can actively participate in demand modeling, analyze modeling work. Accept the changes in demand and follow the changed demand - there is no "freeze". According to the priority order set by Project Stakeholder, first solve the highest priority demand; in subsequent working progress, the maximum risk of risk is set. You use iteration, increment method modeling. Your energy is mainly focused on the development of software, not a document or model itself. Pay attention to the spirit of team collaboration, welcome anyone to make comments or suggestions. Simple as much as possible - using the simplest tool you can get; use the easiest way to be competent. With the development of development, most of your (not all) models will be discarded (not for formal documentation). Customer / Business Organization has the right to business decisions and developers have technical decision. Everyone consistently believes that the content of the model is much more important than the format / expressions of the content. When you model you, a key question that needs to be considered is how you should test the content described in this model. Under what circumstances, you are not in agile modeling? Your purpose is to generate documents, such as demand documents, and these documents require one or several Project Stakeholder signs recognized. You use the CASE tool for software architecture to build and design, but there is no further production of some or all of the code on this basis. Your customer / user works with you very limited. For example, they joined the initial development stage of the project demand, but the time is very limited, just answer some questions; then will withdraw; then participate in one or several receiving reviews for you. You only focus on a model at a time. The most common example is "Modeling Conference", "Types of Modeling Conference" or "Data Modeling Conference". The most fundamental reason for this problem is "single Artifact Developer." For example, a person specializing in data modeling, a person specializing in user interface modeling. In AM, everyone is multi-faceted and can compete for this job. The way you work is to do a model and then do the next model. That is, you are taking a "serial" method work. Your team is only responsible for the writing of model design or documentation. After completing these models or documents, it will be delivered to another group to perform the next development. In other words, you are working in a "SERIAL" to "Handing Off" your work. When is agile modeling?
When is AM operation?
But this is not my situation ...
When isn't the AM operation?
When is agile modeling to suit you?
Agile modeling is not universal, it is not suitable for everyone, every situation. Even if your conditions are very suitable for AM, you can't guarantee that it can work well - you can also make mistakes when you implement AM within your organization. My experience is that when the following conditions are met, AM is very likely to play its effectiveness:
Software development uses agile methods. AM is not a complete methodology, it is just part of a software development process. To successfully apply AM, the concept of development processes you have adopted must match the concept of AM (the translation: XP matches the AM, and the CMM does not match the AM). Otherwise, you are just a few techniques used in the AM, not the true configuration of AM.
Using iterative, incremental development methods. As AM's two practices, effective communication and feedback require software development to adopt iterations and gradual methods.
Demand is uncertain or unstable. Martin Fowler pointed out in his new method, if your project is like a natural adventure (most projects), the best choice is to use agile methods to develop software. When demand is unknown or volatile, you should adopt a development method that can adapt to this situation. AM hug changes, it uses incremental development methods to seek quick feedback, and consistently adhere to the active participation of Project Stakeholder, which is a magazine against demand variations. Using AM, you can quickly and effectively find the needs of our customers. Development software is your main goal. This is one of the core principles of AM, but for many projects, this is not their goal. For example, sometimes a main goal of a project team is from the customer's circle (there is an occurrence in external procurement), or a simple formulation system specification, because the system is to be delivered to another team. Worse, some projects are only for political considerations, and its purpose is to let others feel that they are doing this, but what is going on, but there is no consideration. The goal of software development should be to produce a valid software system that meets customer needs - if your goal is not like this, AM is not suitable for you.
You need to have active support and participation in Stakeholder. Fowler also believes that agile software development work should be successful, you need to have positive support and participation in Project Stakeholder. Project Stakeholder is a person who is developing and / or deploying a potential impact by software projects. Other systems, including direct users, non-direct users, managers, senior managers, operators, supporters, testers, and this system (integrated or interactive), and maintenance personnel. AM wants to succeed, you need to know who your Project Stakeholder is, you have to keep daily contact with StakeHolder, Stakeholder can provide you with information, make decisions. In addition, there should be strong support for management.
The development team can self decide. Agile software development, especially agile modeling, for most organizations are new things. It is a difficult thing to accept the agile method to most of the organization, because it is a new way to most people. If you want to succeed, my experience is that no matter whether it is successful or fail, give them an opportunity according to the advantages of the project team. Encourage them to try new technologies to give them resources (including time), let them start learning. Try to eliminate the phenomenon of playing, which means that the management and some departments have to change the original approach.
There is a real AM fighter. Whenever, accepting new things will always face challenges. People are reluctant to change, they like, they are also used to the previous way of cumbersome slow rhythm. They are different from what you look at, you want to introduce agile methods to solve the problem, and they don't think that is a problem. Maybe they will improve their favorite development methods, but these methods and AM are not in. Perhaps, AM threatens to allocate power within the organization. Even if these conditions are not considered, there will be some people resistance. To change the change, you must have a real AM fighter. They support AM, struggle for AM, they are willing to collect Project Stakeholder support, they are willing to promote AM ideas, let AM can survive in tissue. These fighters are trying time.
You need responsible, active developers. Fowler pointed out that agile software developed to emphasize developer discipline, requiring developers to work together to develop high quality software. This means that you need a healthy team environment, people can trust each other, help each other, and move together to success. And those who are agile development methods tell you completely the opposite, people you need are not one by one to enter the ground. According to my experience, your requirements are very simple: willing to complete the work, have a spirit of cooperation, and work effectively. You need enough resources. You now know that agile modeling needs people's close cooperation. That is to say, you need "Space, developed," In addition, you need enough modeling tools such as whiteboard, index card, tag, and other must-have Case tools. I have seen the lack of basic resources (decent chairs, tables, food, drinks, and high-end workstations), making the development of software development have hindered. If your project team leads to failure because of these 锱 事, I want to ask you that this project is really important to your organization. If not, then Cancel, put your energy into other more valuable projects. But this is not my situation .... So, what should you do when there is one or some conditions on it and your current situation? Try to change your current situation. Lack of AM supporters? Then you can become an advocator. It is not allowed to work in an iterative and incremental way, and talk to your bosses, let them believe this is a better way to work, ask them to give you a chance to prove. Is there a sufficient resource? And your head illustrates their importance. If you have tried to change all the circumstances, there are still some conditions that you can't force, you can try the following choices:
Partially accepts AM. You can accept the principles and practices in AM as much as possible, although you will not realize AM, but you are very likely to be high efficiency developers. Once your organization finds that this is a good way to develop a software development, it may take the initiative to change some necessary elements, thus fully accepting AM. One words, the step-by-step implementation of AM.
Give up your organization accept AM. From my personal point of perspective, I don't like this choice, but I have to admit that it is a correct way. This is the case, AM is not suitable for everyone, maybe your organization is indeed not suitable for accepting AM.
Switch. Looking at the world outside, there are still many organizations expect to win from the competition developed, they hope to have a proactive software developer to join.
When is the agile modeling? I guess agile modeling when I encounter the following circumstances, you will fall into trouble:
Not satisfied with one or more conditions listed above.
Your organizational culture is suitable for use of traditional development processes. Many organizations have no interest in developing methods with agile software, and they feel good about the current situation. This is mainly those governments, large companies (bank, insurance companies, telecommunications companies), and consulting companies specializing in these organizations. This is not to say that AM is implemented in this type of organization, but it is necessary to pay more extraordinary efforts.
Your team is large, distributed around. Only those teams collaborate in the same work area can be well modeled, especially when developers work together in a public studio (usually we call "Tiger Team" room). You can try to apply agile methods in a large or scattered team, I discussed this situation in architecture, but you will soon find that you need to challenge the communication problem brought by this way. I don't agree to apply agility methods to life-friendly systems, such as aeronautical control systems or medical monitoring systems, because I have no relevant project experience, I can't study how AM should be applied to these systems. Similarly, I don't have the relevant experience of embedded systems, so I have no opportunity to apply AM technology to this type of project. I am very suspected whether AM can try to develop in embedded software, this is part of my research. I am looking forward to telling me related experience in the mailing list of agile modeling. (For details, please visit http://www.agilemodeling.com/feedback.htm] how to combine
AM's practice is mutually promoted because they support each other and inspired each other. In order to make AM more efficiently, you need to understand how it is combined. Figure 1 shows the relationship between AM's practice, which is divided into seven categories. AM's core practice focuses on the four categories - verification, iteration, and increment, teamwork, and simple, you need to fully accept them to really understand agile modeling. Then, the three categories of documents, motivations, and productivity belonging to the auxiliary practice are taken. We discuss the relationship between the various types of practices in the core practice, then we will study the relationship between all kinds of practices in the three categories of assist practices, and finally we discuss the category relationship.
Figure 1. How is the practice of AM combination.
Core practice
There are four practices in the team collaborative category - the active participation of Stakeholder, modeling, publicly showing models, and collective ownership. The active participation of Stakeholder is critical to your success, because you are for these Project Stakeholder development systems, just to understand and implement their needs. In other words, you need to work closely with your Party, which naturally thinks with others - this "others" also includes your StakeHolder. When your modeling works, there are many people attend (at least one Project Stakeholder and a developer except your own developers), you need to work together with everyone, promote each other, and make a long-term addition. A person who is good at agile modeling definitions defined by business process modeling and business rules, a person who is proficient in structured modeling techniques (such as UML class maps or data models) is very likely to see. The same truth, the information of the direct user of the system gives you the information provided by the senior manager. Therefore, there must be such views: You have to create a positive atmosphere in the project Party A and the development team, only in this way can you collect a variety of views and experience. The collective ownership can enhance the collaboration, because one is a separate modeling work, he will soon encounter bottlenecks, and if everyone can give advice for modeling work, then you can become a team, easy Solve the problem. The public display model enables people to "look forward to the previous" to improve the information conveyed by the model, thereby improving the team's cooperative. Of course, we are assumed that the model is within the sight of everyone, or these models are currently being developed or related. This topic I have a detailed discussion in Organizing An Agile Modeling Room.
The iterative and incremental categories include using the appropriate Artifact, parallel creation model, switching to other Artifact, small incremental modeling. Regardless of Artifact, it has its strengths and weaknesses, and any single model is insufficient to fully describe the major aspects of your project (such as demand, architecture). For example, you will find that you can use the needs of the system, often need to use cases, business rules definitions, and technical requirements definitions. Can you tell you all the needs of all by using the use case to tell you all the needs of all the use of the Project Stakeholder? This is impossible. You can try for Artifact, such as business rules, to capture all of their business policies, replace Artifact, such as technical needs, to capture their non-functional needs. Otherwise, they will try to tell you what, will return to discuss the details of the previous previous, and even change their original ideas. Your demand recognition is usually a dynamic process, analysis, architecture, design work. I believe that the material is pointed out in this way, and the way we think is obviously messy. Agile modeling must recognize that people are thinking in a dynamic approach, especially when people are in group behavior, in order to make a countermeasure. Agile modeling is parallel to create a model to collect information most widely. This practice is supported by practical switching to additional Artifact and small increment model - you may be using the case to capture information about the needs of use, and when StakeHold is discussed to discuss their requirements for editing screens, you It is best to record these needs using the basic user interface origin or a traditional user interface prototype. You need to come back and forth between different artifacts, each artifact is best needed to verify, this way can be implemented by small incremental modeling practices - the most typical way is to do it on this artifact Work, change another artifact, so on. Simple This category includes the creation of simple content, simply modeling, using the simplest tools in these core practices. Creating a simple content and simply modeling these two practices focus on the simplicity of the model, which in the modeling process is inseparable. Centralize the energy to be briefly described, modelers often find some ways to make your hand's model. For example, I have participated in a storage layer software development, the concept of software is similar to the EJB's persistence Container, encapsulated some storage operations of the domain object. As a result, our architecture and design is very complicated. We tried to find a way: establish a simple chart to help developers understand how to use the storage layer. We also found that reconstruction enables us to understand. Practical use of the easiest tool makes it easy. The easier the tool is, the easier it is, which reduces the threshold for others in your model, and adds the opportunity to do this in the actual person to do this, which also includes your Project Stakeholder. By using the simplest tool, the simply description model has become more natural. In addition, when you use some simple / low-precision tools, such as index cards, instant stickers, whiteboards, you can experience these simple tools, you have strengthened some concepts, the easiest The solution can actually be very effective, and the system you are developing is a simple design.
The verification category contains two core practices: testive thinking and code authentication. There is a philosophy, I often benefit: "If you can't test it, you should not build it, and everything you build should be tested." This makes me tested the test when system modeling, and makes me active Go to get feedback from my model - In fact, I will summarize the philosophy in "consider all Artifact you created, and verify all kinds of Artifact." But this is not limited to AM within. Through this testability, I can build a test model when I model it, and actively verify the model through coding, so that I can confirm that my model is really tested as soon as possible. Auxiliary practice
The document category includes three auxiliary practices: discarding temporary models, contract models must be official, not to update. In the progress, demand, understanding of requirements, and understanding of possible solutions, are constantly changing (recall the principle hug changes). In order to reflect this change, you need to synchronize most of your project artifact, including models and documents. As in agile documentation discussions, a better way is that you must not update your model and documentation, this approach is just a agile method. Follow this practice if you find a model if you need to update, that is, this model has no value for your team, a model without value can be considered a temporary model, you can discard it. However, pay attention to the contract model. It defines the interface between your systems and other systems, it is unlikely to change often because their importance is not doubtful. One words, if you have a non-contract model, it is no longer updated, it means it is already useless.
It belongs to the motivation category for communication modeling and to understand the model. In fact, these two practices have nothing to contact, and sometimes you create a model is to study and understand problems, sometimes your purpose is to communicate your ideas with others, sometimes your purpose includes The above is. Just as you can see in Figure 1, these two practices often lead to the other two types of practice, which is the subject matter to be discussed below.
Finally, the productivity category includes using modeling standards, gradually applied patterns, and reuses existing resources. Re-use the existing resources, this practice requires you to use the results of others and benefit from it, this has many kinds of thinking directions: one is an application model, according to experience, I think it is the most efficient way in all reuse methods, because You reused all other developers' proven solutions (Ambler, 1999); the other is to follow modeling standards and guides, in fact, whether it is standard or guidance, you can improve your work consistency. Yes, you can write a guide yourself, sometimes you have to do this, because there will be some special situations in your actual environment. But you only need to search for a lot of development guides on the Internet. For example, you can find JavaCodingstandards to find Java development guidelines.
Category connection
Let us consider teamwork categories. Practice in the simple category enhances the effect of practicing the active participation of Stakeholder, because the participation of generations is eliminated. Practice in iterations and incremental categories also makes participation becomes possible, especially in parallel, because it increases the opportunity to participate in StakeHold. Practices in motivation categories can increase the effect of collective ownership and the effects of modeling together, understanding and communication on problems typically inspire people's collaboration, simple categories, practices, also pitted to stimulate collaboration effect, because it reduces participation threshold. The effectiveness of the public display model can be improved through the practice of productivity categories. Follow the standards, application mode, can increase consistency and readability, and reuse existing resources (such as universal architectures), give others a good head, so that others can continue on your model. The practice of iteration and incrementation can support the implementation of collective ownership, especially in parallel creation models and switching to additional Artifact, which make people develop together on the appropriate model. The practice of simple categories is assisted by another type of practice. Both practices using modeling standards and gradual application patterns support the same modeling language (models that use standards and easy understanding), which supports practical modeling. The practice of document category can also support the simple category of practice - only the model is only updated, so that you will not add unnecessary information to the model. It is possible to create simple content and simply model. Now iterate and increment categories now. Obviously, the practice of team collaboration supports the practice of this class. Due to the participation of the team, the opportunity to choose the correct Artifact is increasing, you can switch to use different Artifact as needed. Verification class practices can give you the courage to use the increment method, especially when you use code to verify. Ensure that you think about it, you have more manual to operate multiple Artifacts and switch between them, because test issues require you to look at it from multiple aspects. Document class practices can also promote incremental methods, especially if they are not updated. But the contract model must formally inhibit the application of the increment method, because you always want to build and other interface standards as soon as possible. Switching to another Artifact and discard the temporary model can also generate a positive effect, because a model is switched to another model after the purpose is completed. Simple class practice is also very important to this category. By using the simplest tool, you will become easier to switch between different artifacts, you save the time of familiarity, just concentrate on simple content and description On, you can easily remember the information to be conveyed. Finally, motivation practice can make you simultaneously moderately work, because for complex systems, you need to communicate from multiple aspects, understand, so you need to turn back and forth in the appropriate Artifact, so that you can do effectively To this.
Verification class practices can be supported by simple classes - Creating simple content and simply modeling can make you easier testive thinking. Iterative and extraction practice can also improve the verification practice. For example, when you switch to another Artifact, you may switch to source code so you can see that the model can actually run.
Simple class practices can promote productivity practice. When you use simple models, gradually apply mode easier; when you simply model, use modeling standards will be easier, and the model is simple, easy to understand, will make you more easy reuse now Some resources such as enterprise demand models or universal architectural models. Simple classes and iterative and increasing practice can support document practice. The more you use the details, the easier it is to use - if your document is easy to understand, you have to make you unable to update your document, because you know this is very simple; if the document is very complicated, your project risk is very big. , Because there is no need to be able to update when the document is required. Obviously, the operational environment that is not updated and discarding the temporary model can be improved in other practices, such as switching to additional Artifact, small incremental modeling. So, do you want to be a agile modeling?
Personal passage or special?
Agile modeling personality
Alistair cockburn pointed out that many methodologies define the roles of the developers in the software development project, but also define the tasks performed by each role, although they do not define the most suitable candidates for these characters. One person wants to succeed as a role, he should adapt to it - although this does not need people to master all skills, people must be slowly familiar with these technologies. My experience tells me that it is necessary to be a successful agile modeling. The following list is necessary: the first point in the team competition, the most important point, the agile modeling is always actively seeking cooperation, because They realize that they are not all between all things, they need different views, so that they can do it. Software development is not swimming, it is very dangerous. There is no "me" in a agile dictionary. Exhaus messenger models have good communication skills - they can express their ideas, listening, able to take the initiative to get feedback, and write it needs. The down-to-earth agile monger moderator should work hard. Their energy is concentrated on the needs of users, they will not draw snakes in the model, even if the feet are good. They are satisfied with the easiest way to provide possible programs, of course, premise is to work. Curious agile modeling workers are learning questions and solve problems. Everyone asked why agile modeling is never as for the surface, but will break the casserole. They never think about a product or a technique, and they will try it with them. Seeking truth from facts is very humble, they never think that they are a hundred things, so they will use the code to carefully prove the correct model after establishing a good model. The courageous agile modeling should be willing to plan an idea, then make a model, then find ways to use code to verify. If the results are not ideal, they will rework, check their methods, or give up the original idea. Tell your companion, then verify its correct, this is a great courage. It is willing to try new methods based on experimental agile modeling, such as a new (or existing) modeling technology. In general, they will also accept agile modeling development technology. If necessary, in order to verify the idea, they are willing to struggle with traditional ideas, such as reducing the number of documents in a project. It is disciplined to perseverely follow the practice of agile modeling. For you, you may say inadvertently, "Plus this feature, no harm." Or, "I know more than Project Stakeholder." I don't want to deviate from the direction on the road of AM, it is necessary to have certain Disciplined. If you don't have all the individuals listed above, what should I do, do you still want to be a agile modeling? Don't worry, you only need a small amount of effort to be competent. Believe me, I have no way to do 100% of the down-to-earth and truth from facts, I often encounter communication problems. No one can have all personality, most people can only have some personality. Everyone has a different point, and these differences are the source of agile team power. Some people may be curious, and other people's work can be relatively strong. People have not made it. Tourism or special?
When you want to increase team members, a crucial problem to be processed is the ratio of talents and specialization you want to maintain. To answer this question, you need to consider the modern software development environment. Figure 1 is the lifecycle of the Enterprise Unified Process EUP. (Translation: This pair is not provided in the original text. According to my guess, it should be the life cycle map of RUP, but because there is no authorization of the Ruori Company, I have been temporarily inconvenient to quote this picture. You can refer to RUP information.) The workflow of the EUP on the left suggests that the software development is complex - you need business modeling, collection requirements, analysis, and design systems, etc. - and this is just a horn of the iceberg. As listed in the figure, from the various phases of the product, indicate that different time needs you to concentrate in different places during the project, it requires different skills. There is a point of view that software development is very complicated, and any work requires superb skills and extensive experience. First, I have to realize that this complexity is software development and the shape, not the EUP, even if your team uses XP methods, or DSDM (StApleton, 1997) method, or Scrum (Beedle & Schwaber, 2001) Method, this complexity also exists. Although the life cycle of these methods seems to be complicated as EUP, they still need to configure management activities, require management activities, etc., just that they have different attitudes. Many organizations' first response to this is to build a special team. The most basic meaning of the specialization refers to those who are particularly proficient in a certain task, so their efficiency is also particularly high. Such a team, to make the efficient operation, you need to combine these specialties, let each person are responsible for a task, and then pass the work of the hand to another after solving. This concept is similar to the "pipeline" idea. If you are in a large number of production cars, this way is very effective, but in my experience, this way is not too suitable in handmade software. Moreover, this way requires a large team support - if there are different tasks in software development, you at least n-digit is required to meet this method. But how big is N? 20? 50? 100? It depends on your level of detailed details, right? If you tend to handle only one Artifact, you need more than 20 professionals in Modeling Artifacts Essay, listed in Modeling Artifacts Essay. If you tend to be responsible for each developer only responsible for a role, then the role in 11 in an EUP can also do all workflows. Experts usually work hard to work together, they lack the quality of humility, and consciously add the special skills of other people to add value to his work. They also consciously have troubles that they may cause follow-up work. Maybe they need to rework, maybe their current efforts will be in vain. Another question about the specialization is that even in the fields they are good at, their skills may not be so familiar. The technology high changes in the IT industry has led to new technologies for developers for several months. They have begun to familiarize it, claiming that they are already in this area, because he has not much experience with him with the same level of experience. It is also a significant problem to build a team that consists of a special context.
So what will I establish a team that is only a leader? Everyone has a good understanding of software development, but it is lacking enough necessary knowledge and can't do it. The project requires those who are very familiar with techniques and techniques used in the stages. If you are using Enterprise JavaBeans (EJB), you need someone who is proficient in Java, and needs to develop proficient in EJB. A team that uses Oracle, there must be an Oracle database management expert behind the scenes. A team of developing broker business software requires a person who can understand the fine difference between stocks and bonds.
My experience is that the two extreme ways are not advisable, and you should take their intermediate points. One way is that some people in the team are talents, and some people are special. The role of the team's linker can pay attention to the vision, pay attention to the specific difficulties of the project. The benefits of doing this are the strengths of the generals to make up for the shortcomings of the specialty, and it is the same, because this balance, the generals and specialists can play a great advantage. A better way is that the team is mainly passing, only one or two talents. For example, I think I should be a pass, I good at the cooperation between various skills in the project, and also master the business application modeling, and object storage and Java programming. Another colleague is also a talent, especially specializing in modeling, EJB development, and testing. There is also a common colleague who is refined by network communication and Java programming. Such a team consists of pass, but there is a team of stunts, the advantage is obvious, they can quickly find a common point, because they are all talents after all, and they have a complementary complement between them. Its disadvantage is that this kind of talent is generally relatively scarce, and it takes 10 years or even 20 years to cultivate this passage. It is hard to get. If there are some people in your team, then your luck is so good. It is important to realize that novices are special. Software developed a lot of knowledge that needs to be digested, often do not know what it is, this is normal. At the beginning, most people will focus on the development of two aspects, perhaps Java programming, perhaps to obtain user needs, and then in this regard, gradually expand the coverage of knowledge. Over time, experience is constantly accumulating, they will slowly improve their skill trees, and they will work more about how the skills in software development will be more understanding, and they are also good at one and two stings. There is also a little important, we must understand that many developers have harmed these people. Due to the complexity of software development, developers often fall into a trap named a single Artifact developer, they are positioned to work in just a development of Artifact, such as code, use case model, Or data model; a trap name that developers may also encounter is a single role developer, and their positioning is a person who is engaged in a work, such as modeling, testing, or encoding. In other words, these people are specially designed in a role, which is particularly remarkable in some large-scale organizations using traditional processes, and the problem occurs, and the field of perspective of these traps is often too narrow, it is difficult to use agile methods. High productivity in software development projects. Of course, if they are originally extended to expand their vision, this problem is easily resolved. Translation: If you want to see the domestic programmers, you will be very happy. After all, China's programmers have always been self-sealing. However, it is important to note that this article is for foreign programmers, because foreign programmers are only focused on their own field, such as the database's experts are very familiar with the database, but he may not test the test . But they understand the understanding of their own fields. But China's programmers are generally all gold oil, where there is, where there is my colorful. As long as it is the software field, it is omnipotent. But people's energy is limited, it is impossible to be proficient. The sample is essential, that is, the same thing. This truth is necessary to understand. Many of the domestic programmers are not tenth, but can only be considered. This sentence may not be good, but the truth is. If you can realize this, ok, I think you are not a mediocrity, but in the way forward.
It was not intended to translate this article, because I was worried that some people will break down after watching it, but it has become a sin. However, many of this article is worth learning, plus in order to ensure the integrity of translation, and finally translate it, and add a nonsense, remind everyone to pay attention. Finally, I sincerely hope that China's programmers can become the one mentioned in the article is both passing talents, and a special person. Modeling misunderstanding
Going out of general design misunderstandings, moving towards success
English Original copyright owned by Scott W. Ambler Original Text Is CopyRighted by Scott W. Ambler
Translator: Gao Jirong | Original Source: www.agilemodeling.com
Whether you follow the weight-level approach, such as Enterprise Unified Process (EUP), or a lightweight development process, such as Extreme Programming (XP), modeling is indispensable in software development. But unfortunately, it is full of falsehoods and ingles. This comes from all aspects, there is a research from the theor's wrong, decades, cultural deposits in the field of information technology, software tool developers, a semi-market propaganda and the standard of Object Management Group (OMG) and IEEE. This month, I want to reveal the misunderstanding in the model, pointing out the truth of its corresponding facts.
Misunderstanding 1: Modeling is equal to writing documents
This is likely to be one of the most destructive pieces, because developers can this be excused to give up modeling. Many excellent software developers will say they don't want to waste time on these "useless" documents. They indulge in the code and make some fragile and inferior systems. In addition, even many developers who are responsible now think that modeling is an annoying thing, but unwilling to learn the corresponding modeling technology.
Fact Analysis: "Model" and "Document" These two concepts are conceptually. You can have a model that is not a document and a model of the model. A design graph is a model, regardless of drawn on the back of a napkin, or writes on a whiteboard, or in the Class Responsibility Collaboration (CRC) card, or based on the flowchart recorded on the newspaper and cascading paper A rough user interface prototype. Although these can't be said to be a document, they are all valuable models.
Modeling is like a plan: the value of the plan is in the process of planning, rather than planned itself; value is reflected in modeling, not model itself. In fact, the model is not a formal document in your system, and can be lost after completing their mission. You will find that there is only a few models worth retaining, and it must be very perfect.
Misunderstanding 2: From the beginning of the stage you can consider all everything
This kind of saying is popular in the early 1970s to the early 1980s, many managers today have developed software developed at that time. The superstition of this will lead to a considerable time in the previous period to make all everything to get correct, trying to "frozen" all the needs (see misunderstanding) before the start of the coding (see the misunderstanding) "Analyzing period paralysis" - After the model is very perfect, dare to advance. Based on this point, the project team has developed a large number of documents, not what they really want - developed to meet the needs of the needs.
Fact analysis: How can I get out of this misunderstanding? First, you have to realize that you can't take into account all the sub-branches. Second, I realize that the coder may do not act if the work of the model is not as good as (this is possible, the work of the fact that the work "works only in the actual value only), they may say that the model does not respond the truth is. Third, I realize how good your original specification manual is, but the destined code will lose synchronization with it, even if you use your own code. A basic truth is that the code will only be consistent with the code. Fourth, recognize the iterative method (small scale modeling, compiling some code, do some tests, may also make a small work version) is the guidelines for software development. It is a modern heavyweight software development process (such as EUP), as well as the basic principle of lightweight (such as XP). Misunderstanding 3: Modeling means a heavyweight software development process
Project groups walking into this misunderstanding (often associated with the misunderstanding) are often completely abandoned, and it should be too complicated to them for such software development processes. This is no more than a natural disaster.
Fact analysis: You can replace it with an agile way. For more details on simply modeling with simple tools, see Agile Modeling (AM). Moreover, you can discard your model When you finish, you can also model it in a very basic manner (for example, starting from the work desk, starting to make a sketch before the whiteboard). As long as you like, you can easily model it.
Misunderstanding 4: Must "freeze" demand
This requirement is often from a senior manager, and they want to know what they can get from this project group. Such a benefit is that the needs of the development cycle will be exactly what is what is what is what is what is the thing is; the disadvantage is that they may not get actually needed (incomplete or wrong demand, translator).
Fact analysis: Change will eventually occur. Due to the changes in priority and gradually understand the system, there will be changes in demand. Contrary to freezing demand, estimating the risk of success, trying to accept changes and take action accordingly, just like XP recommended.
Misunderstanding 5: Design is not changeable
As the misunderstanding four, each developer must strictly comply with "design", causing developers to make a wrong thing in order to meet the "design" or correct things in the wrong way. Or simply ignore the design, denying the benefits of all design possible. Frozen design, you can't get further benefit from learning in the project process. Another big trend is to develop a large number of documents instead of practical software, using a document-oriented CASE tool instead of bringing the project-oriented tool for the project.
Fact analysis: In fact, the design will often modify according to the developer and database administrator, because they are people closest to practical applications, usually their understanding of the technical environment is better than modeling. We must face such a fact: people have not finished, and their work is impossible. Do you really want to fix an imperfect design without modifying the mistake? In addition, if the demand is not frozen, it means that you can't freeze your design, because any demand modification is bound to affect the design. For the correct attitude: As long as your code is still changing, it is not finished.
Misunderstanding 6: Must use the Case tool
Modeling is often considered a complex work, so it is necessary to use the Case tool assistant.
Fact analysis: Yes, modeling can be complicated. But you can fully establish a valid and simple model to express the key information, not some insignificant details.
For example, I often use the UML to build a model to represent classes, their properties and some key business operations, but do not draw access operations (GET and SET), and the frame code for maintaining with other class relations, or other Some trivial achievements. I use the model to find a solution to the problem, let me continue to implement this model with my colleagues. In this flexible way, most cases I don't need a CASE tool to support modeling work, a whiteboard, or a digital camera is enough. In this way, I don't have to take time to evaluate the Case tool, don't have to discuss the license without going to the tool supplier, eliminating the training overhead. The CASE tool is only worth buying when it can reflect the best cost performance (for your own situation). In most cases, I can reach the goal (complete modeling). I often use tools with together / j (http://www.togethersoft.com/) - because it produces a visual Java frame code; there is Erwin (http://www.cai.com/) - Because it can plan the database. These two tools really helped me achieve the purpose of software development - manufacturing software that meets user requirements. But most of my modeling work is still using simple tools, not Case tools. Misunderstanding Seven: Modeling is Waste Time
Many newcomers think so, this is mainly because the education they receive is limited to how to write code, and have a fresh contact for a complete development process. And their experience is only limited to how to implement code, just like a primary programmer. They abandoned opportunities to improve efficiency and learning skills, which allowed them to easily adapt to different projects or organizations. They should be ashamed for this.
Fact analysis: In most cases, draw a sketch before starting the encoding, develop a rod-up prototype or make some index cards to improve your production efficiency. Efficient developers have to model work before encoding. In addition, modeling is a good communication path between project team members and project leaders. You can explore questions in this process, thus getting better understanding, involving each member in the project, can also get a part of a score for the project.
Misunderstanding 8: Data Model (Data Model) is everything
Many organizations are based on the data model to start new development work. Perhaps as your organization: IT department has a very strict provision for data, controlling your development project; or your previous database is a mess, don't choose.
Fact analysis: Data model is an important but not most important modeling, it is best to build on additional models. (See "Extreme Modeling", Thinking Objectively, Nov.2000). This is also the case even in items such as data warehouses. If there is no good understanding of how the user uses this data warehouse (not shown in the data model), these projects often ended with a sad failure. You can use a lot of models - using cases, business rules, Activity Diagrams, Class Diagrams, COMPONENT DIAGRAMS, User Interface Flowchart (User Interface Flow Diagrams) and CRC, etc. . The data model is only one of them. Each model has its strengths and shortcomings, which should be used correctly.
Misunderstanding Nine: All developers know how to model
We are now facing such a serious problem: many people who are not developers, including senior managers and users, do not know how software is built. As a result, they are unable to distinguish the skilled developers and the general programmers (of course, they can't deliver advanced programmers and general programmers). They want to identify all developers to develop the entire system from head to tail. . Fact analysis: This is definitely incorrect. Modeling skills, only when a developer can learn it and have long-term practices. Some very smart programmers often believe that they are all, after all, they are only programmers. Because of such arrogant, some of their tasks is that they don't have the corresponding skills at all. Software development is so complicated, single one is difficult to have all skills to successfully develop, and even impossible to configure a certain complexity system. Developing this should have a self-known understanding, understand their own weaknesses, and learn without end. Through each other, the modeling can learn the specific details of a technology from the programmer, and the programmer can also learn the technique of valuable design and architecture from the model. I personally think everyone, including myself, is a newbie.
Agile model
By understanding and avoiding the modeling misunderstanding, you can have yourself, your project group and your organization have more efficient software development. In the process of revealing these generally existing misunderstandings, many of the principles of Agile Modeling (AM) have been expressed. Agile model is called Extreme Modeling (XM). I hope that I have given you a spiritual food.
Here I would like to thank the Doug Smith, EvaNetics (http://www.evanetics.com/) of Blueprint Technologies (http://www.evanetics.com/), and list in the Agile Modeling Mail (Access HTTP) People who contribute to this article in //www.agilemodeling.com/ Add). I also want to thank Martin Fowler, Ron Jeffries and other members of the XP community, because I think I have already integrated their views.
Modeling ten principles
Only data models are not enough for modern software.
Receive changes and allow your model to improve over time. You can't freeze them, and then look forward to success.
The model is not necessarily a document, and the document is not necessarily a model.
Most models may also be discarded.
Only the code can keep real synchronization with the code.
Some simple tools, such as whiteboards, completely enough to cope with most modeling work.
Reflections, then encode.
You can always learn something from others.
Modeling can be used in a light way.
It is not completed until the code is released.
