Agile Modeling (AM)

Revision as of 00:04, 11 April 2023 by User (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied to a software development project in an effective and lightweight manner. Agile Modeling is a supplement to other Agile Methodologies, such as:

  • Extreme Programming
  • Select Perspective
  • SCRUM[1]

The development of agile modeling was led by Scott Ambler starting in the autumn of 2000. It initially was called extreme modeling (XM), but at the suggestion of Robert Cecil Martin was renamed AM in the spring of 2001.[2]

Agile Modeling Core Principles[3]

  • Model with a Purpose: Many developers worry about their work when creating models. What they are not doing is stepping back and asking why they're developing the models and who they are developing them for.
  • Assume Simplicity: Keep models as simple as possible and assume the simplest solution is the best solution. Only model what you need today and trust that you can remodel later if needed.
  • Embrace Change: Change happens on a project as understanding grows. Rather than fight changes to your models, accept them and have the courage to rebuild.
  • Enabling the Next Effort is Your Secondary Goal: Others might need to extend or improve your project after you leave. Leave enough documentation and models to enable the next person or team to improve or change the model.
  • Incremental Change: It is very hard for a model to be complete the first time it's developed. Models change over time as the project develops. Always make small changes to models as required.
  • Maximize Stakeholder Investment: The team must be in it to produce software to maximize return for the customer. The team must strive to develop software that meets the needs of the stakeholders.
  • Multiple Models: There are many ways of modeling solutions; choose the best fit according to the given situation.
  • Quality Work: Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, and the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update. The end users won't like the work because it's likely fragile and/or doesn't meet their expectations.
  • Rapid Feedback: Getting quick feedback on the model will close the loop of understanding the model. The best process is to model a little, show the model for review, and then model again. This ensures the accuracy of the model while increasing the developers' own knowledge.
  • Software is Your Primary Goal: Models are a means to the end; the en is to build software for your customer. Documentation and modeling must directly support the goal of software development.
  • Travel Light: Traveling light means that you have just enough documentation about the models that you are developing. If it's too little documentation, the developing team might lose its way; too much and the developing team will have forgotten that the primary goal is not writing documentation but software and building the right models.

Pros and Cons of Agie Modeling[4]

Pros of the Agile Model

  • Emphasis of Modern Techniques: While a core value of the agile model places emphasis on people over technologies, stepping outside the realm of technologies themselves and into a pure focus on techniques brings about powerful, agile practices such as test-driven development, automated unit testing, refactoring, and iterative development.
  • Highly Adaptive: As one of the fundamental agile values states, a key component to the agile model, and which partially makes it such a good launching pad for the entire software development life cycle, is the capability of the project to rapidly adapt to any necessary changes. Whether this is from rapid iterations informing the changing needs within the code or client feedback forcing a reshaping of the sign-up procedures, a properly Agile project can quickly and effectively change course as needed.
  • Constant Customer Feedback: Although constant communication with customers and clients requires a dedicated team member to take on this responsibility, it is a critical component to ensuring the success of the product from both a development perspective as well as from that of the client.
  • Allows for Iterative Development: Common models like the Iterative Model are based on the fundamentals of the agile model. For good reason: It allows the project to be started with relatively little upfront planning or cost. From these early components, the project can evolve over time as new incremental iterations are made, constantly learning from past iterations and improving on them for future updates.

Cons of the Agile Model

  • Potential for Increased Technical Debt: The concept of technical debt describes the act of implementing a solution that is easier to complete right now in favor of a solution that may be better overall in the long run. Within the scope of the agile model, it is not uncommon for technical debt to begin to run rampant, as rapid development techniques and frequent iterations often mean developers feel hurried and thus forced to implement faster but generally less-than-ideal band-aids. This issue can largely be reduced by ensuring the team properly integrates refactoring, pair programming, and other techniques emphasizing collaboration amongst team members.
  • Difficult to Make Additions Within an Iteration: Often referred to as use cases in other development models, a story in the agile model simply refers to a description of some new project requirements. When actively utilizing the agile model for an ongoing project, it can sometimes be difficult to implement a new story into the current iteration since it forces backtracking and heavy mental overhead on how to implement the new requirements of this story into the existing iteration that has largely already been developed. In such cases, it is often necessary to delay the implementation of the new story until the next iteration comes about.
  • Minimal Emphasis on Documentation: Unlike more traditional models like the Waterfall Model, the agile model largely forgoes initial efforts to heavily design and document the project requirements or scope in favor of getting into the meat of the project and beginning that iterative process. This can be a challenge for some projects, particularly within development teams that may not be accustomed to this style of agile development and which may have more traditional experience instead.

Agile Modeling Best Practices[5]

Another way to look at Agile Modeling is as a collection of best practices.

Agile Modeling
source: Agile Modeling

See Also

Waterfall Model


Further Reading