Design documentation when working with many business logic rules. How to organize it?
I am working on a rather complex project in terms of the amount and amount of business logic.
Each developer mainly works with "his" component. I realize this is not very cross functional, but it is impossible to know the details of each component.
The sostav command changes from time to time. Thus, we have situations where one person has to work on "another person's component". And it might be on a periodic basement, so you can come back to the problem a month later - at times like this, you can ask the component business logic owners over and over again, because you might just forget some tiny but important details a month later.
This situation is sometimes annoying.
We have daily standby meetings , when a person talks about what he has done and is going to do. We have a project wiki FAQ page - we extract the most frequently asked questions.
What do you think about the problem?
And how would you recommend us to solve it?
a source to share
given the nature of the component I would go with:
1.) A framework document defining the purpose, setting, requirements, etc. 2.) Module documents for each component in a common format and indexed by name.
Have a look at http://docs.python.org for a good example of common docs and http://docs.python.org/modindex.html for a good example of modules / components docs
Oh, and daily meetings are usually bad, they take a long time and the answers are forgotten. Newcomers or sick people miss appointments and should be re-instructed. It's 100x better to write it all down and keep a paper / email trail if no discussion / feedback is needed.
a source to share