Software documentation-discard or inherit

Document is an indispensable part of all software development processes. It is not perfect to refuse to write documents under the guise of "agility, in addition, this is no different from those that tolerate more than a dozen different documents in the product without thinking about it, and claim to be the "ultimate regression of the development process. Writing documents, like other software activities, also requires a balance of ROI. We only write a document when it is really necessary. At the same time, the benefits of writing a document should also be worth the effort.

Agile Methods require two types of documents: Requirement documents and design documents. All other types of documents are optional. But it is not optional.

1. Requirement document. In Agile Methods, Requirement documents are often carried out in an iteration. It is often prior to other development processes, but the content must be complete at the beginning of the iteration of the development process. It will also be used for automated acceptance testing. Other types of Requirement documents, such as narrative, workflow, and image documents, may also be used as appropriate.
2. Design document. In Agile Methods, design documents are often composed of unit tests guided by the test priority method. These unit tests are examples of how to use each part of the code. Other types of design documents, such as class diagrams, InterAction diagrams, state diagrams, and erdiagrams, may also be used as appropriate.

The document is created by the development team when necessary. It is as simple as writing it when they feel they need it. In addition, documents are not required in the development process of the development team. They are often determined by the customer or market. The development team uses the material card to estimate, plan, and determine the specific completion time. If a clip is not included in the iteration process, it must be of no value to the customer or the market. If you join the development plan, it must be because the customer or the market thinks they are important enough.

:

User material, original user stories. Index card: the original index card. To plan a project, you must know the content related to the project requirements, but you do not need to know too much. The specific details of a requirement may change over time. Therefore, the specific details of a requirement are captured very early before the actual implementation, it is likely to cause useless work and immature demands. In XP, we are more willing to write some words that we agree on the index card. These words can remind us to join in this conversation. User materials are the supporting notes for ongoing demand conversations. It is a planning tool that customers can use and arrange the time to implement the requirement based on its priority and estimated cost.

 

(Original URL: http://www.butunclebob.com/articles.unclebob.ondocumentation; Robert C. Martin's english blog: http://www.butunclebob.com/ArticleS.UncleBob)

Author profile: Robert C. Martin is the president of object mentor and a senior consultant in the field of Object design, pattern, UML, Agile Methodology and extreme programming. He is not only the author of Jolt's award-winning book Agile Software Development: Principles, models and practices (Chinese version) (Agile Software Development (English version, or the author of the bestselling book Designing object-oriented C ++ applications using the booch method. Martin is the editor of pattern development ages of Program Design 3 and more C ++ gems, and has co-authored XP in practice with James Newkirk. He is a well-known speaker at the international conference of programmers and has been an editor of C ++ report for four years.