A directory of resources inthe field of technical communication.

Ambler, Scott W.

6 found.

About this Site | Advanced Search | Localization | Site Maps
 

 

1.
#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

2.
#29359

Calculating Documentation Cruft

It's easy to describe documentation cruft, and often easy to identify it once you see it, but it's hard to estimate how 'crufty' a document actually is. Furthermore, it's often hard to convince the creators of a document that 'their baby' isn't as beatiful as they believe it to be.

Ambler, Scott W. Dr. Dobb's (2007). Articles>Documentation>Assessment>Minimalism

3.
#27602

Easing Into Agile Modeling

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

4.
#28728

Introduction to Agile Usability, User Experience Activities on Agile Development Projects: Part II

What would happen when usability community meets agile community? How to adopt usability practice by agilists?

Ambler, Scott W. uiGarden (2007). Articles>Usability>Agile

5.
#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

6.
#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

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon