Documentation Advices¶
See also
You are what you document (Monday, May 5, 2014)¶
See also
The number one cause of startup failure is not the product, but the distribution: it doesn’t matter how good the product is if no one uses it.
With software, the documentation is the distribution: it doesn’t matter how good the code is if no one uses it. If it isn’t documented, it doesn’t exist.
Rédaction technique¶
Libérez vos informations de leurs silos¶
Des solutions souples et fiables libèrent vos informations des silos d’information cloisonnés où elles sont emprisonnées et sous-exploitées.
Oubliez MS Word ou FrameMaker pour passer de la maintenance de la documentation à la gestion du cycle de vie des projets documentaires modulaires !
Intégrer la documentation aux processus de développement¶
La documentation fait partie du logiciel. Fournie avec le produit, elle doit :
sortir en même temps,
suivre les mêmes cycles de vie, et
faire l’objet des mêmes processus de production et de contrôle qualité.
Elle doit répondre idéalement aux critères suivants :
pas de vendor lock-in (indépendance du format et de l’éditeur de contenu),
chaînes de publication libres et gratuites,
mise en page totalement automatisée.
Il y a quelques années encore, les seuls outils permettant de fournir des livrables de qualité au format PDF ou HTML reposaient sur des formats binaires et propriétaires qui s’intégraient mal aux systèmes de gestion de versions des équipes de développement.
Résultat : réalisée à part, la documentation technique répondait difficilement aux mêmes exigences de qualité et de délai de mise sur le marché que les produits.
DocBook, puis DITA XML et reStructuredText ont changé la donne : ces formats texte peuvent être modifiés avec tout type de programme, du simple éditeur de texte à l’’IDE graphique, et s’intègrent parfaitement sous Subversion, Git ou tout autre système de gestion de versions.
Docness¶
See also
Consider the documentation as a component of your product, i.e. don’t package it as an external product or as an option.
In software development, your “product” is usually made of the software, which itself is usually based on source code.
Hacking distributed (february 2013)¶
In the beginning, there was no documentation.
These days, infrastructure software has terrible documentation.
Take heed of these commandments, for, among hackers, judgment day is every day.
Agile documentation best practices¶
See also
Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand.
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.
Best practices for increasing the agility of documentation:
- Writing
Prefer executable specifications over static documents Document stable concepts, not speculative ideas Generate system documentation
- Simplification
Keep documentation just simple enough, but not too simple Write the fewest documents with least overlap Put the information in the most appropriate place Display information publicly
- Determining What to Document
Document with a purpose Focus on the needs of the actual customers(s) of the document The customer determines sufficiency
- Determining When to Document
Iterate, iterate, iterate Find better ways to communicate Start with models you actually keep current Update only when it hurts
- General
Treat documentation like a requirement Require people to justify documentation requests Recognize that you need some documentation Get someone with writing experience