Agile modeling
Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast changing environment.[1] It is part of the Agile software development tool kit.
Agile modeling is a supplement to other agile methodologies such as Scrum, extreme programming (XP), and Rational Unified Process (RUP). It is explicitly included as part of the disciplined agile delivery (DAD) framework. As per 2011 stats, agile modeling accounted for 1% of all agile software development.[2]
Best practices
There are several best practices:
Modeling
- Just barely good enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more. This is an application of the KISS principle.
- Architecture envisioning. At the beginning of an agile project, high-level architectural modeling is done to identify a viable technical strategy.
- Lookahead modeling is used to reduce overall risk.
- Multiple models can be used. Each type of model has its strengths and weaknesses. Effective developers have 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.
- Active stakeholder participation. Stakeholders are important for funding the process and accepting the results, that is why they are involved as soon as possible. Stakeholders provide information in a timely manner, make decisions in a timely manner, and are as actively involved in the development process as possible.
- Requirements envisioning. At the beginning of an agile project, time is invested to identify the scope of the project and to create the initial prioritized stack of requirements.
- Prioritized requirements. Requirements are implemented in priority order, as defined by their stakeholders, so as to provide the greatest return on investment possible. Collecting the low hanging fruit.
- Iteration modeling. At the beginning of each iteration, a bit of modeling is done as part of the iteration planning activities.
- Test-driven development (TDD). Requirements are written like a test. Tests are performed and then just enough code is made to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.
- Model storming. Throughout an iteration a brainstorming session can be held, called "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.
Documentation
- Document continuously. Documentation is made throughout the life-cycle, in parallel to the creation of the rest of the solution.
- Document late. Documentation is made as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
- Executable specifications. Requirements are specified in the form of executable "customer tests", instead of non-executable "static" documentation.
- Single-source information. Information (models, documentation, software), is stored in one place and one place only, to prevent questions about what the "correct" version / information is.
History
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 [3] was published in 2002 by John Wiley Press. Work on the methodology continues at The Agile Modeling Home Page.
Limitations
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.
See also
References
- ↑ Agile modeling (AM) home page, effective practices for modeling and documentation
- ↑ State of Agile Development Survey Results, 2011
- ↑ Agile Modeling: Effective Practices for Extreme Programming and Unified Process