Agile development smart agility Series II: Do you want to write or not write a document?

This is the second article about agile development and smart agility. (One, two, three, four, five, six)

 

Origin

"Our product has been completed. The customer said that we should add the requirement document, but we only have user stories. Should this document be written ?"

"Can customers accept this document without it ?"

"No, the customer has to hold a Project Review Meeting. This is one of the materials of the review meeting ."

Do you want to write this document? Write, why? Don't write. Why? How to write? Don't write, why don't you write?

Why not write documents with agility?

First, let's say nothing. Agility means not writing documents. Why not write the document?

To reduce waste.

Agility considers all intermediate products, requirements, plans, designs, test cases ...... All lack of customer value. The value that the customer wants most is undoubtedly the final software that can run. Therefore, all intermediate documents should be omitted and omitted until they are not written.

It does not waste time on anything that has no value to customers. This is the true meaning of agile document writing.

In practice, the most time-consuming documents are useless documents. But if the document is useful and even an important part of the customer's value, everything will change.

How to write this requirement document?

As far as this document is concerned, it is used for acceptance and has nothing to do with development (developed), and later maintenance.

So how to write? This question is not answered. Of course, it is written in the form of acceptance.

Therefore, all documents are written differently in each enterprise. You should not ask "How to Write XX documents in Agile development ?", Instead, you should ask "How should I write the document above ?", If you can ask questions like this, the answer is clear.

Common practices of "writing without writing documents"

Although there are many common documents, the following dimensions almost always exist. A specific document has different processing methods through analysis of several dimensions:

Documents with long-term or short-term information

Long-term effectiveness, such as competitor analysis documents, architecture design documents, requirement management documents (user stories), product roadmap ......

Long-term documents are suitable for detailed descriptions. the term should be complete (that is, the way word is written), and even graphic and modeling tools can be used.

Short-term effectiveness, such as problems found during review and the content explained by the Po at the Planning Meeting.

Short-term documents are suitable for rough descriptions. Typical examples are to use paper or word to describe key content in disorder. They do not need to be saved for a long time and are useless at the end of the month.

Documents that cannot/can be replaced by "executable software"

In the document above, competitors, architecture design, user stories, and Roadmap cannotCodeIt is suitable for docalization. In addition, some scientific formulas and complex designs also fall into this column.

The interface design, database table structure design, flowcharts, and pseudo code are easy to see in the runable software once the software is ready.

If you feel that the latter is in an embarrassing situation where "no software is available, but the software is useless", you should adopt a lightweight design.