Does agile development require documentation?

In the product development process often need to write a lot of documents, such as: Requirements documents, design documents, API documents, acceptance documents and so on. Team members have to spend a lot of effort to maintain a large number of documents, even have "brother, I write code for you, you write documents for me" frustration.

Agile Development Manifesto
* Individuals and interactions are better than processes and tools
* Working software is better than detailed documentation
* Customer cooperation is better than contract negotiation
* Responding to changes is better than following plans

The second article of the Agile Manifesto, "working software is better than exhaustive documentation," many people understand that agile development does not attach importance to documentation, and even avoids writing documents as an excuse. Similarly, there is a similar extreme view of the question of whether agile development requires architectural design.

The Agile manifesto does not give any rigid guidelines on what documents to write and how to write, so how do we write documents in Agile managed projects?

First, we need to understand the ideas behind the Agile manifesto.
The Agile 4 Manifesto is focused on the concept of "value", "Fast Delivery value" and "Delivering value to customers". In other words, research and development teams need to focus on where they can bring value to their customers, and avoid wasting time on tasks that do not generate value or ROI (return on investment).

Second, we want to understand what the document does. Documents are used to accurately convey information, to help understand things, and to precipitate knowledge.

Based on this understanding, you can answer two questions to determine if there is a more efficient way to deliver information than writing a document when you encounter questions about whether you want to write a document. Whether the rough documents meet your needs.

From the reader of the document to divide

The reader is a person outside the project group
Such documents are often written and not "abbreviated". Examples: User manuals, acceptance documents, API documentation, and more.

The reader is a group of people in the project
This kind of document can save the province, can contributors Jane. If you can communicate at the station every day, you can not write. Recommended high-level system frame composition, internal API documentation can be abbreviated.
If the project leader information that can be queried by a management tool like EASYPM, it can be abbreviated or even omitted in the weekly report.

For documents that can be "abbreviated", consider using the markdown format.

Markdown is an easy-to-use markup language that allows users to generate highly expressive documents at minimal input cost using these marker symbols.

EASYPM's document editor uses markdown syntax and saves/previews in real time, supports code highlighting, document reviews, and full-text search. Versioning is supported manually and automatically for version management. Document reviews also support the @ feature, which allows for efficient review of documents.