Agile modeling

<h2 id="core-practices">Core practices</h2>
<p>There are several core practices:
</p>
<h3>Documentation</h3>
<ol><li>Document continuously. Documentation is made throughout the life-cycle, in parallel to the creation of the rest of the solution.</li>
<li>Document late. Documentation is made as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.</li>
<li>Executable specifications. Requirements are specified in the form of executable "customer tests", instead of non-executable "static" documentation.</li>
<li>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.</li></ol>
<h3>Modeling</h3>
<ol><li>Active stakeholder participation. Stakeholders of the solution/software being modeled should be actively involved with doing so.  This is an extension of the on-site customer practice from <a href="/facts/Extreme_Programming/UCeJIvhQ">Extreme Programming</a>.</li>
<li>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.</li>
<li>Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive).</li>
<li>Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look-ahead modeling the 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.</li>
<li>Just barely good enough (JBGE). All artifacts, 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.</li>
<li>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 <a href="/facts/Scrum_(software_development)/Ih3ufnVB">Scrum</a>.</li>
<li>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.</li>
<li>Multiple models. Agile modelers should know how to create a range of model types (such as user stories, story maps, data models, <a href="/facts/Unified_Modeling_Language/3tlNS0tH">Unified Modeling Language</a> (UML) diagrams, and more) so as to apply the best model for the situation at hand.</li>
<li>Prioritized requirements. Requirements should be worked on in priority order.</li>
<li>Requirements envisioning. The team performs light-weight, high-level modeling that is JBGE at the beginning of a software project to explore the stakeholder requirements.</li></ol>
<h2 id="limitations">Limitations</h2>
<p>There is significant dependence on personal communication and customer collaboration. Agile modeling disciplines can be difficult to apply :
</p>
<ul><li>On large teams (say 30 or more) without adequate tooling support</li>
<li>Where team members are unable to share and collaborate on models (which would make <a href="/facts/Agile_software_development/LDaISBAW">agile software development</a> in general difficult)</li>
<li>When modeling skills are weak or lacking.</li></ul>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Story-driven_modelling/HCD8Dmbp">Story-driven modelling</a></li>
<li><a href="/facts/Agile_software_development/LDaISBAW">Agile software development</a></li>
<li><a href="/facts/Robustness_diagram/STjxoh9T">Robustness diagram</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www.AgileModeling.com/">The Agile Modeling Home Page</a></li>
<li><a href="http://www.agileModeling.com/essays/amdd.htm">Agile Model Driven Development (AMDD)</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Agile modeling (AM) home page, effective practices for modeling and documentation <a href="http://www.agilemodeling.com/" target="_blank">http://www.agilemodeling.com/</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>"State of Agile Development Survey Results, 2011". Archived from the original on 2015-07-17. Retrieved 2014-06-26. <a href="https://web.archive.org/web/20150717120712/http://www.versionone.com/state%5Fof%5Fagile%5Fdevelopment%5Fsurvey/2011/" target="_blank">https://web.archive.org/web/20150717120712/http://www.versionone.com/state%5Fof%5Fagile%5Fdevelopment%5Fsurvey/2011/</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Alfraihi, Hessa Abdulrahman A.; Lano, Kevin Charles (January 2017). "The Integration of Agile Development and Model Driven Development: A Systematic Literature Review". The 5th International Conference on Model-Driven Engineering and Software Development: 451–458. doi:10.5220/0006207004510458. ISBN 978-989-758-210-3. S2CID 11369604. <a href="978-989-758-210-3" target="_blank">978-989-758-210-3</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
</ol>

Agile modeling open-in-new

Agile modeling