Agile development and documentation update


Taking into account the second premise of the agile manifesto:

" Software in operation more than comprehensive documentation"

According to the agile practices, scrum, XP, etc ..., if during development, after having done the UML design of the classes, we verify the need to create a new attribute for one of the classes we must program the attribute in our class and database after and updated the UML? Or do we leave the UML drawing behind and continue to plan the iterations?

Remembering that agile methodologies do not discard documentation, but would like to know how far we work with it.

asked by anonymous 19.08.2014 / 19:31

3 answers


The question is ...


When your team has a meeting or do you discuss some functionality with a fellow developer, do you use the diagrams?

In case of affirmative , then use must be daily, so it is rewarding to keep documentation up to date.

Negative case, diagrams were probably only meant for initial understanding or to meet customer or management expectation, not worth it ; work is more than the benefit harvested.


If the source file of the diagrams is versioned along with the source code, then it is easy for any team member to update the diagram and synchronize the project with SCM.

On the other hand, if the team usually works with printed documents, simply scratch the document in pencil and it will be enough to use in the next sprints (provided, of course, that no one plays basketball with papers and a wastebasket).

UML diagrams need not be a 100% accurate reflection of the code. In many cases, I avoid placing attributes in classes so as not to compromise the internal structure.

But what often happens is to use the UML to represent the system database model. I do not really agree with that. There are more appropriate tools that allow you to do an MER (Entity-Relationship Model) and already synchronize the diagram with the database.

19.08.2014 / 20:08

The easiest (and cheapest) way would be to make class changes (software running first) and then reverse engineer it to generate class diagrams and the like. There are several tools on the market that do this for you.

I think that it is necessary here to point something to reflection that has already been described in several articles, that UML is not documentation .

19.08.2014 / 19:40

In the concept of "agile" development documentation is a mere aid in the process (user story is a great example).

If you are in the "agile" the idea is that the documentation is collaborative, that is, it grows according to the need and with the collaboration of all after team scrums (eg daily scrum or sprint planing).

The important thing is to deliver value to the customer. If the documentation is an artifact to be delivered too, you will inevitably have to update it, but not necessarily at the exact moment a change was identified.

If the change will impact the next sprints, then it is worthwhile to update the documentation.

Now, if the documentation is not a deliverable artifact and if the changes do not impact what will still be developed, I suggest taking it just as a lesson learned.

Remember that the focus on agile methodology is delivering value to the customer. So they do not approach documentation, although documentation can be a deliverable that generates value.

Make your own judgment.

25.09.2017 / 12:38