||This article contains instructions, advice, or how-to content. (May 2013)|
Agile Modeling (AM) is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods.
Agile Modeling is a supplement to other agile methodologies, in which Agile Modeling is used to describe how to approach modeling and documentation. Examples of other agile methodologies include Extreme Programming (XP), Disciplined Agile Delivery, and Scrum.
There are several modeling-oriented best practices:
- Active stakeholder participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.
- Architecture envisioning. At the beginning of an agile project, the team will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.
- Iteration modeling. At the beginning of each iteration, you will do a bit of modeling as part of your iteration planning activities.
- Just barely good enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more.
- Lookahead modeling. Sometimes required so as to reduce overall risk.
- Model storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.
- Multiple models. Each type of model has its strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.
- Prioritized requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.
- Requirements envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.
- Test-driven development (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.
- Document continuously. Write deliverable documentation throughout the life-cycle in parallel to the creation of the rest of the solution.
- Document late. Write deliverable documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
- Executable specifications. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation.
- Single-source information. Strive to capture information in one place and one place only.
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 to AM in the spring of 2001. The book Agile Modeling  was published in 2002 by John Wiley Press. Work on the methodology continues at The Agile Modeling Home Page.
There is significant dependence on personal communication and customer collaboration. Agile Modeling disciplines can be difficult to apply:
- On large teams (say 30 or more) without adequate tooling support
- Where team members are unable to share and collaborate on models (which would make Agile Software Development in general difficult)
- When modeling skills are weak or lacking.
- Agile Modeling (AM) Home Page, Effective Practices for Modeling and Documentation
- Agile Modeling: Effective Practices for Extreme Programming and Unified Process
|This software engineering-related article is a stub. You can help Wikipedia by expanding it.|