#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
#27601
Why do we bother with models or documentation? They don't execute, and our customers pay us for working code, not pretty pictures. We bother with models to communicate. The idea is that a graphical object model can show how objects fit together more clearly than looking at the source, an interaction diagram can show a collaboration better than figuring out the call path from several class definitions. But so often the design documentation fails in this, and leaves me puzzled on my sofa.
Fowler, Martin. MartinFowler.com (1997). Articles>Documentation>Agile>Extreme Documentation
#27590
With limited staff, a rapidly changing IT environment, and increasing complexity, my own inflexible documentation practices had to be updated to reflect more dynamic environments.
Dickerson, Chad. InfoWorld (2004). Articles>Documentation>Agile>Extreme Documentation
#19666
A revolution is under way in software development, revolving around agile methodologies that allow more room for design changes based on input from customers during development. One popular agile methodology is eXtreme Programming (XP).
Nuckols, Carl E. Intercom (2003). Articles>Documentation>Agile>Extreme Documentation
#27572
eXtreme Documentation and Design
What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code!
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Documentation>Agile>Extreme Documentation
#27586
Extreme Programming (or XP) is a popular software development process that encourages a return to the days of little or no documentation, Design After First Testing, and Constant Refactoring After Programming. Despite its popularity, not everyone thinks XP is a good idea.
Software Reality (2005). Articles>Collaboration>Agile>Extreme Documentation
#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
#27609
When it comes to getting work done, replace written documentation with more efficient forms of communication. To guide future work, create documents at the end of the project, when everything is complete, well understood, and easy to document.
Shore, James. JamesShore.com (2006). Articles>Documentation>Agile>Extreme Documentation
#27587
USDP-Distilled eXtreme Documentation
This is a description of a simple software-internals documentation format and process. It is derived from the Unified Software Development Process, simplified towards eXtreme Programming compatibility, and arranged for realisation in a plain text file.
Ainsworth, Harrison. HXA7241 (2004). Articles>Documentation>Agile>Extreme Documentation
#27591
Using Design Rationales for Agile Documentation 
Recently, Agile Software Processes have been discussed as flexible and light-weight alternatives to established Software Engineering approaches, in order to overcome the obstacles created by the cost of producing and maintaining documents on higher abstraction levels. Depending on requirements and needs on the documents itself, Agile Documentation becomes a key issue and brings up questions on how to create, maintain and distribute documents among the team members without creating unnecessary or unjustifiable cost. This paper describes a technique allowing to produce documentation automatically, by conducting analysis on the series of development steps taken during project planning and enactment.
Sauer, Thomas. IEEE Digital Library (2004). Articles>Documentation>Agile>Extreme Documentation
#27585
A broader awareness of how changes can impact other things, including schedule commitments and work outside of the immediate area of change, is beneficial in terms of assessing trade-offs and benefits.
Ferlazzo, Ellen Lawson. XProgramming.com (2002). Articles>Documentation>Agile>Extreme Documentation
