Agile Practice (1)-does agile require documentation?

There are two common scenarios in the Agile manifesto that say "working software is better than detailed documentation" and it seems that the documentation is redundant in the work:

1, complete a summary of the design, but the development process, this design is not enough to guide the programming work, it is better to directly ask PO to direct, communication between each other smooth. Finally this outline design becomes the decoration, no one looks.

2, complete a detailed design, but the development process, found that there are many details did not take into account, some parts need to change, the final realization of the content and detailed design has a lot of discrepancies, others read the document is easy to misunderstand, everyone exclaimed this document is poison

The two scenarios described above are very common in the workplace, including the agile coaches I've come into contact with and ask, "will anyone read this document?" Will anyone maintain this document? ”。 As a result, most people will feel that "it seems that communication is more important in the workplace, and the documentation seems useless"

My view of this is "adapting to local conditions".

1, the front also said, I do is the industry software, this category of software needs is very clear, so generally will not change too often (I am also in touch with the Internet software, the demand changes in this is too fast).

2, the industry software quality requirements are very high, often require accurate management.

3, for the new system, I am not a qualified po, for the grasp of demand, can not be convincing. And I'm not allowed to trust my team members.

3rd, if not, the team is not efficient, so I need a detailed document to prove to my client (leadership team, research and development team, Test team, maintenance team, marketing team).

I finally finished a detailed design document that I thought was good, and shared this document's Drifting adventures:

1, spent one months of time, I and design, testing, maintenance, marketing and other multi-party frequent communication, at the same time to research the existing code, the final completion of the detailed design document. (Detailed design starts one months before project start, no need for personnel at this time)

2, according to this document, I and the leadership team to communicate repeatedly, to determine the staffing, schedule management, risk assessment and other pre-project work, and finally to prove that the assessment based on this document is very consistent with the actual situation, my client (leadership team) is very satisfied with the effect of communication

3, this document is maintained and the market affirmation, because they know that the demand has landed

4, in the development process, I encourage the research and development team members to communicate with me, if it is the design of the question, I will come up with detailed design documentation and communication (with reference, communication efficiency will be greatly improved, and the effectiveness of communication can be determined to implement the document). At the same time, I will encourage members to think "What do you think you should do?" "If the members of the idea is reasonable, I encourage them to modify the document, the United States its name said:" We can not spend a lifetime as a yard, we have to learn to design ~. " In fact, this kind of communication effect is very good, I found two influential members of the league, another two members of the growth is very fast, these four people work very high, above average more than one times. For these four people, they formed the habit of thinking about documents and implementing them into documents, and the changes were confirmed by the PO, and they did not have to focus on the rest of the communication (the rest of the PO was done), so the work inertia would not be interrupted. The final document has been repeatedly modified (not very influential), but it is constantly strengthening the team's communication effect. The purpose of my approach is to make the document function as a catalyst for communication, not as a device.

5, for the Test team, is generally not concerned about the development of written code. The design use case is based on the design document and the past test cases, for refactoring, it is best to use the existing test examples directly covered. But I'm not satisfied with this (because the three test colleagues I joined are new employees, eh), I encourage the three test colleagues to write new use cases based on past use cases and design documents (each week, based on the number of new use cases and the number of problems found, the full staff is notified). In fact, my goal is to encourage test colleagues to communicate with me, on the one hand, from the point of view of testing design documentation flaws, on the other hand, the progress of the test is more controllable. Finally, the results of the three test colleagues were very significant, and I leng three people for the test department (^_^ a little bit)

The above share, actually want to express my view "The role of the document is also local to the individual," the above share may not be suitable for Internet software (documents must not be changed to death), but for the industry software, it is a gradual accumulation of the process (not every time to push to the back), the document plays the role of inheritance, The effect cannot be neglected.

Agile Practice (1)-does agile require documentation?