Agile development: tips

Agile Modeling (AM) is a set of concepts, principles and techniques (practices) that allow you to quickly and easily perform modeling and documentation in software development projects.

AM describes a modeling style that will improve quality and reduce time. AM is not a technological process. This is not a detailed design instruction, it does not contain descriptions of how to build diagrams in UML. AM is focused on effective modeling and documentation. It does not cover programming and testing, although it talks about checking the model by code and considers the testability of models. AM also does not include issues of project management, deployment and maintenance of the system.

AM should be considered as an addition to existing methods, and not an independent technology. This method should be used to increase the efficiency of developers using eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), or RUP processes.

The AM is intended for the average developer, not for retraining experienced ones. Most of the principles and rules of AM are simple and clear, in many ways similar to those that were used by developers earlier. They do not require any extra effort and are available to a novice developer.

The AM declares the maximum participation of interested parties, the creation of models and documents that are accessible for understanding by interested parties. Documentation should be extremely simple and concise. It should correspond to the main purpose – the description of the designed system and be understandable to interested parties. It is allowed to use any tools that simplify and accelerate the design.

Agile Modeling Goals

To show how to put into practice a set of concepts, principles and techniques that make it easy and simple to perform modeling. AM is not focused on the technique of constructing specific diagrams, but on how to use them.

To show how to use well-known modeling techniques (XP, DSDM, RUP, etc.) in a flexible approach to project development.

To increase the efficiency of modeling in projects at different stages (business analysis, requirements formation, analysis and design).

The basic principles of Agile Modeling

The keys to the success of the project are effective interaction between its participants; the desire to apply the simplest solutions that meet the requirements; using feedback as often as possible and starting from the early stages; critical evaluation of their own decisions; understanding that all project participants can make a significant contribution to the project.

Prefer simplicity. Consider a simple solution the best. Do not enter additional properties that are not required today. Strive to make the model as simple as possible. It is necessary to model based on existing requirements, and revise the model if the requirements change in the future.

Consider the changes. The requirements for the system are evolving, the views of stakeholders and the criteria for their evaluation of your results are changing. This must be taken into account in the project.

Provide future work. It is important to ensure that the following software releases can be supported and released. To do this, you need to create the necessary documentation for the software product and its support. It is necessary to determine whether the software development team will participate in the next release, the essence of the next work, the importance of the next release for your organization. That is, we should not close our eyes to the future.

Make changes sequentially. One should not strive for the absolute correctness of the model right from the very beginning. It is unlikely that it will be possible to achieve this even at the cost of super-efforts. Instead, you should first build a small high-level model and further develop it incrementally (or delete it if it is not necessary).

Attract more interested parties. It is most effective to include representatives of interested parties (customer users) in the team.

Define modeling goals. Modeling should help to better understand the system. The model may be needed in order to justify the project to management, it may need to be included in the documentation for users or those who will perform support. If you can’t determine for whom and why a model is being created, why do it at all? The first step should be to determine the exact purpose of the model and for whom it is intended. Then, based on this, a model is built with the degree of detail that is required for the goal. After that, the construction of this model ends and you can move on to other work, for example, writing code that shows how the model works. This principle also applies when making changes to an existing model. There must be a substantial reason for making changes (for example, the introduction of a new requirement or the need for clarification). You need to clearly know who the model is intended for and what this consumer needs (for example, a programmer).

Use many models. For software development, it is necessary to build many models, each of which describes some aspect of the problem. It is necessary to have a set of design techniques based on the selected tool. It is important to note that it is not always necessary to build the entire set of models for any system. Depending on the nature of the software, one or another subset of a possible set of models is created.

Ensure quality. There should be no sloppily made works. The results of such work are difficult to understand, let alone update them. Poor-quality code is hard to understand and difficult to maintain.

Provide quick feedback. Usually you work on the model together with other people, that is, the process of split modeling is carried out. Quick feedback is important here. Using collaborative modeling techniques, you get an instant response to your ideas. If we are talking about the customer, it is important to ensure a quick and correct understanding of the requirements and analysis of the user interface.

PO is the main goal. The main task is to create software that effectively meets the needs of the customer and other interested parties. Avoid creating unnecessary documentation or models. No activity that is not directly related to the main task should be performed.

Minimize the number of documents you create. Each artifact created must be maintained in the future. If you use several models, then when making changes, you need to evaluate their impact on all these models and make changes to them. The more artifacts supported, the more difficult it is to make changes. Similarly, it is more difficult to maintain more detailed models. If you decide to support a certain model, you lose speed, but you get the opportunity to provide additional information for developers. Do not underestimate the seriousness of the loss of time. By supporting many models, you may notice that a large amount of time is required to update these documents, and not to write codes.

Additional principles

Content is more important than representativeness. Each model can be represented in many ways. The model does not have to be an output document. A complex set of diagrams constructed with the help of tools can be considered as source data for other artifacts, for example, source code and not be official documentation. Thus, you can take advantage of modeling without wasting time and resources on documentation.

Learn from each other. Programming technologies are changing rapidly, for example, Java. The modeling technology is changing more slowly, but it is also changing. Teamwork makes it possible to exchange knowledge, techniques and skills.

Know your models. To use models effectively, it is important to know their strengths and weaknesses.

Know the tools. You should know modeling tools well, their properties and how to apply them in practice.

Adaptation to the features. The approach to software development should take into account the specifics of the developer’s organization, the persons interested in the project and the type of the project itself. It is necessary to have modeling techniques, the use of tools, a description of the process (technology).

Open interaction. Everyone should be able to express their opinions and suggestions on modeling, requirements, deadlines, etc. This allows you to choose the best solutions based on more accurate, high-quality information.

Use your intuition. If someone feels that some things in the project are not coordinated, then in most cases it is. If it seems to you that the requirement does not make sense, you should carefully investigate it with the user. The same should be done when choosing architectural solutions. Of the two equivalent options, choose the one that your intuition tells you.

Flexible modeling techniques 

AM offers a set of working methods (called practices) that meet the formulated principles:

Active participation of stakeholders. It is necessary to have direct communication with users who have the right and opportunity to provide information relevant to the system and make decisions regarding requirements and their priorities. Such people include direct users, management, operators, and support service.

Use suitable artifacts. Each artifact has its own application. For example, UML activity diagrams are useful for describing business processes, while a static database structure better represents physical data. You need to know the advantages and disadvantages of each type of presentation in order to determine when what is needed or not needed.

Collective ownership. Each project participant should be able to work with any model or other artifact.

Consider testability. When modeling, it is advisable to periodically ask the question “How to test this?”, since it is impossible to create untested applications. Testing and quality assurance processes should cover the entire lifecycle.

Parallel modeling. Since each type of model has its advantages and disadvantages, one model is not enough. For example, when identifying requirements, you can create use cases or custom descriptions, a prototype UI, and business rules. Simultaneous work with several models gives a greater effect due to the influence on other artifacts (see the following rule).

Transition to another artifact. If you are stuck working on some artifact (use case, CRC map, sequence diagram, etc.), switch to another one for a while. In this case, you can go further by working on another artifact. Moreover, by changing the way you look at the system, you can understand what failed in the first case.

Simplicity. The semantic content of the models – requirements, architectural, analytical, etc. – should be as simple and understandable as possible for all interested parties. Do not add unnecessary aspects to the model if it is not justified. If, for example, you do not have a requirement to implement control functions in the system, do not add them to the model.

Use a simple notation. A simple model shows key properties, such as class responsibilities and their relationships, so a small subset of expressive means is usually used for each type of diagram. You should not waste time on models that will not be required for further work. It is unlikely that you will need to create a model for the entire code.

The general availability of the model. All models should be available to all interested parties. Organize easy access to all models. They can be placed on the board, create a website for presentation in electronic form, etc.

Incremental development of models. Consistent development of models allows you to transfer to the customer faster (from 2 weeks to one or two months).

Group modeling. Modeling serves to understand something, to spread ideas for everyone, to develop a common point of view, a common vision of the project. The model allows you to coordinate the points of view of the members of the development team through discussion, to combine their ideas in the simplest way.

Checking the model by code. A model is an abstraction, it should accurately reflect aspects of what you are creating. It is necessary to check the model with a code. Thumbnails of user interface pages should be shown to interested parties. Having built a business fragment model, write tests and program code and run the tests to make sure everything is correct. Do not forget that for most projects modeling is only one of the types of work performed.

Use the simplest means. Most models can be built on paper or a blackboard, because later they become unnecessary anyway. Building a model serves for understanding. The tools are used only if the model needs to be presented to interested parties or there is a need for it during programming (automatic code generation).

Additional rules

Use the modeling standard. UML and coding standards are applied for the names of attributes, methods, and relationships.

Use design templates with caution. If you think that the design template (pattern) can be used in such a way as to implement the minimum volume reflecting the current state during modeling, and then make improvements, then this is the best way. In other words, don’t overload the model with unnecessary details.

Get rid of temporary models. Most of the models in the project are temporary. They have done their job and do not contribute anything new further. Many of them quickly cease to conform to the code. They either need to be updated or simply deleted, especially when the loss of time to update the model does not pay off with its value for the project.

Formalize contract models. Contract models are required when the information resources required by the system are provided from the outside (DB, legacy application, information service). The contract model must be agreed with both parties and, if necessary, changed jointly. These models are almost always created and maintained using tools. As in the case of a regular contract, resources should be allocated to develop and support the contract model. The number of such models should be minimized.

The model is used for communication. The model is used to communicate with people external to the development team. Since these people are usually geographically separated, tools are used for this.

The model serves for understanding. An important application of the model is an explanation of the problem area, an analysis of system requirements, a comparison of possible alternatives in order to choose the simplest solution.

Reuse. This refers to the possibility of using existing models, if any.

Update only if necessary. It is necessary to update the model only when there is an urgent need, when the loss of time for updating is less painful than using an outdated model. Using this rule, you will find that you will have to update much fewer models than actually created.