Together with my teammates, I'm trying to self-learn XP and apply its principles.We're successfully working in TDD and happily refactoring our code and design. However we're having problems with the overall view of the design of the project.Lately we were wondering what would be the good practices for an effective continuous design of the code. We're not strictly seeking the right model, like CRC cards, communication diagrams, etc., instead we're looking for a technique to constantly collaborate on the high level view of the system (not too high though).I'll try to explain myself better: I'm actually interested in the way CRC cards are used to brainstorm a model and I would mix them with some very rough UML diagrams (that we already use). However, what we're looking for are some principles for deciding when, how and how much to model during our iterations.Have you any suggestion on this matter? For example, when your teammates and you know you need a design session and how your meetings work?
What modelling technique do you use for your continuous design?
design;agile;uml;extreme programming;modeling
We call a design session whenever any of us feels uncertain about how to implement a new feature / refactoring. Or even if we feel we clearly have a (rough) idea, but the problem is complex enough so that we don't fully oversee the whole of it.In the first case, it is obvious that we benefit from discussing the problem together and getting thoughts, suggestions and criticism from others. In the second case it is still true that the more eyes there are to check the rough design, the better. But even if the design turns out to be perfect (which practically never happens in real life), it is still beneficial to share the common understanding about the specific problem and its solution within the team. This helps keeping the architectural vision consistent across the whole team.We use rough UML sketches, but no CRC cards btw.