Agile modeling: Difference between revisions

Revision as of 04:04, 24 June 2020

Latest revision as of 05:52, 25 May 2025

(17 intermediate revisions by 15 users not shown)

Line 4:

{{Third-party|date=November 2019}}

}}

'''Agile modeling''' ('''AM''') is a methodology for [[Software development process models|modeling]] and [[documentation|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.<ref>[http://www.agilemodeling.com/ Agile modeling (AM) home page, effective practices for modeling and documentation]</ref> It is part of the [[agile software development]] tool kit.

Agile modeling is a supplement to other [[agile development]] methodologies such as [[Scrum (development)|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.<ref>[{{Cite web |url=http://www.versionone.com/state_of_agile_development_survey/2011/ |title=State of Agile Development Survey Results, 2011] |access-date=2014-06-26 |archive-date=2015-07-17 |archive-url=https://web.archive.org/web/20150717120712/http://www.versionone.com/state%5Fof%5Fagile%5Fdevelopment%5Fsurvey/2011/ |url-status=dead }}</ref>

Agile modeling is one form of Agile [[model-driven engineering]] (Agile MDE), which has been adopted in several application areas such as [[web application]] development, finance, and automotive systems <ref>{{cite journal | url=https://kclpure.kcl.ac.uk/portal/en/publications/the-integration-of-agile-development-and-model-driven-development-a-systematic-literature-review(af6a79a4-01a5-4cfd-a8a4-36d11890fc74).html | title=The Integration of Agile Development and Model Driven Development: A Systematic Literature Review | journal=The 5th International Conference on Model-Driven Engineering and Software Development | date=January 2017 | last1=Alfraihi | first1=Hessa Abdulrahman A. | last2=Lano | first2=Kevin Charles | pages=451–458 | doi=10.5220/0006207004510458 | isbn=978-989-758-210-3 | s2cid=11369604 | doi-access=free }}</ref>

==Core practices==

Line 20 ⟶ 22:

# Architecture envisioning. The team performs light-weight, high-level modeling that is just barely good enough (JBGE) at the beginning of a software project so as to explore the architecture strategy that the team believes will work.

# Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive).

# Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look-ahead modeling theythe team may choose to do that exploration during their iteration/sprint planning session. The need to do this is generally seen as a symptom that the team is not doing sufficient look-ahead modeling.

# Just barely good enough (JBGE). All artifactartifacts, including models and documents, should be just sufficient for the task at hand. JBGE is contextual in nature, in the case of the model it is determined by a combination of the complexity of whatever the model describes and the skills of the audience for that model.

# Look-ahead modeling. An agile team will look down their backlog one or more iterations/sprints ahead to ensure that a requirement/work item is ready to be worked on. Also called "backlog grooming" or "backlog refinement" in [[Scrum (software development)|Scrum]].

# Model storming. A short, often impromptu, agile modeling session. Model storming sessions are held to explore the details of a requirement or aspect of your design.

Line 29 ⟶ 31:

==Limitations==

There is significant dependence on personal communication and customer collaboration. Agile modeling disciplines can be difficult to apply <ref>{{cite web Citation needed|websitedate=classicinformatics.comOctober 2016}}:

|url=https://www.classicinformatics.com/blog/getting-started-with-distributed-agile-development

|title=Getting started with Distributed Agile Development}}</ref>:

* 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)