Project's documentation when dealing with lots of business-logic rules. How to organize it?

Question

I'm working on quite complicated project, in terms of business-logic quantity and quantity of components.

Each developer mostly works on "his own" component. I understand that this isn't very cross-functional, but it is impossible to know every components' details.

Team sostav changes from time to time. So we have situations when one person have to work on "other person's component". And this can be on periodic basement, so you can come back to the issue a month later - in that moments you can ask component business-logic's owner the same questions again and again, because you simply can forget some tiny but important details a month later.

This situation is annoying sometimes.

We have daily stand-up meetings, when person tells about what he has done and going to do. We have project's wiki F.A.Q. page - we extract the most frequently asked questions.

What do you think about the problem?

And how would you recommend us to solve it?

Answer 1

given the component nature I'd go with:

1.) A framework document specifying the applications purpose, setup, requirements etc. 2.) Module documents for each component in a common format and indexed by name.

Look at the http://docs.python.org for a good example of general docs and http://docs.python.org/modindex.html for a good example of module/component docs

Oh, and daily meetings are generally bad, they take up a lot of time and answers get forgotten. Newcomers or sick people miss the meetings and have to be re-briefed. It's 100x better to write it all down and keep a paper/email trail unless discussion/feedback is required.