Advices ¶
Voir aussi
You are what you document (Monday, May 5, 2014) ¶
Voir aussi
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.
Doc ¶
13 Things People Hate about Your Open Source Docs ¶
Beautiful docs ¶
Designing Great API Docs (11 Jan 2012) ¶
Docness ¶
Voir aussi
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.
Docness Source code ¶
Voir aussi
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 .
Jacob Kaplan-Moss (November 10, 2009) ¶
Agile documentation best practices ¶
Voir aussi
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