#27588
Agile Documentation: Strategies for Agile Software Development
When I initially started work on Agile Modeling (AM) I wanted to focus solely on principles and practices for effective modeling but quickly discovered that this scope was not sufficient, that I also needed to consider the issue of how to be effective at the creation and maintenance of documentation too. Some agile models will 'evolve' into official system documentation, although the vast majority will not, and therefore it is relevant to discuss how to be agile doing so.
Agile Modeling. Articles>Documentation>Agile>Extreme Documentation
#30729
Best Practices for Agile/Lean Documentation
Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation.
Ambler, Scott W. Agile Modeling (2001). Resources>Documentation>Agile
#27602
Agile modeling started out fairly complex and it grew a bit into its current form.
Ambler, Scott W. Agile Modeling (2006). Articles>Project Management>Agile>Collaboration
#27610
Introduction to the Diagrams of UML 2.0
Understanding the thirteen diagrams of UML 2.x is an important part of understanding OO development. Although there is far more to modeling than just the UML the reality is the UML defines the standard modeling artifacts when it comes to object technology.
#27608
Single Source Information: An Agile Practice for Effective Documentation
In agile software development you want to travel as light as possible, and the easiest way to do that is to choose the best artifact to record information. I use the term 'artifact' to refer to any model, document, source code, plan, and so on created during a software development project. Furthermore, you want to record information as few times as possible, ideally only once. For example, if you describe a business rule in a use case, then describe it in detail in a business rule specification, then implement it in code, you have three versions of the same business rule to maintain. It would be far better to record the business rule once, ideally as human-readable but implementable code, and then reference it from any other artifact as appropriate.
Ambler, Scott W. Agile Modeling (2006). Articles>Documentation>Single Sourcing>Agile
#27604
The TAGRI (They Aren't Gonna Read It) Principle
The basic idea is that very little of the documentation which gets created during software development actually gets read by the actual target audience. This article explains the problem and presents advice for addressing it.
Ambler, Scott W. Agile Modeling (2006). Articles>Documentation>Agile>Extreme Documentation
