Here are some:
Which brings me to the second part of your question. Until we reach the limits of what can be accomplished with these technologically simple tools, we won't write (or buy) anything more complicated. When we can't move forward as fast as we want, we'll do something different.
XP isn't explicitly anti- ProjectManagement/CASE tool, but it is pro-simplicity and pro-directness, which rules out all the tools I've seen. It's absolutely amazing what you can do with cards, and until I understand their limits I won't start programming something else.
In XpAtArinc, we use Rational Rose as a sort of computer-based CrcCard session. While pairing, it's common for one of us to be much more familiar with the part of the code the pair is working on. That person will open up Rose when a question comes up and use Rose to quickly sketch a static or dynamic model for the other person. For static sketches, we don't use anything other than the ability to draw a class and connect it to another using inheritance or composition lines. For dynamic sketches, we use the collaboration diagram and again draw objects and composition lines, occasionally adding a couple of methods across a connection to illustrate ordering.
The technique is very successful. Of course, we're using rose in a completely 'unauthorized' fashion, as a sort of dedicated whiteboard, but we like it anyway. (One person on our team saves most of his sketches, as we have a document deliverable that can benefit from finished versions of some of the drawings, but let me stress that the resulting model file is strictly a process output for the team, not the input to any sort of design session other than the in-situ session that generated it.) -- MichaelHill
Couldn't you scribble the diagram on a card faster?
You create an instance variable:
Portfolio p = new Portfolio();then you type:
p.and the next thing you see is a pop-up like this:
p. -------------- | addLoan() | | removeLoan() | | Portfolio() | | toString() | | etc. | --------------This helps me:
* Remember the names of methods * Remember what the class can do * Save time by not having to jump somewhere to lookup methods * Quickly navigate a body of code I don't know wellIn addition, some editors take this a step farther. When you highlight methods in the pop-up, the editor displays the method's JavaDoc comments. And when you do select a method, you are then prompted, via pop-ups again, to input the correct parameters for the method.
A fellow programmer turned me on to VisualSlickEdit, which does everything I mention above, and a whole lot more. It has definitely made me go faster - and it's Code Beautifier is a thing of beauty (use it to implement team CodingConventions). --JoshuaKerievsky
What about Wiki as a project design and discussion tool - including the customer(s)? How should wiki be used with IndexCards, a RefactoringBrowser and ObjectExplorer?. These four I think would satisfy me for a long while - especially if I had the last two in VisualAge for Java. Having said that, in our excitement last year I came to feel we ended up using our Wiki clone a bit too much and losing card and face to face contact more than was best (see KnowingWhenToStop).
What are other people's experience? How much did C3 benefit from the XP discussions on this Wiki? Or was it all cost, for the greater good? IndexCards certainly seem best in the coffee shop.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006