>Hi,
>
>I'm working in a really big team, all VFP and only VFP (actually in the bank there are others teams that works with others tools, but mine is working only with VFP). We are something like 25 (developers, business analyst, testers, support, etc).
>
>I'd like to share some experience with people working in a big VFP team like us. Is there someone that can share some experience with me?

The most important thing as Hilmar already mentioned, is Source Control. If you are not accessing a single location (that old source safe shadow), consider giving somebody the role of code librarian. But infinitely better is to invest into another product, possibly web-based. Make sure a "runable" version can always be had: either mark milestones where everybody has to check-in a clean version or get into the habit of everybody getting current sources on tuesday and finding incompatibilities early in the process. Also add a stable automatic beautify step before check-in so that diffing is still possible even if a developer has persaonal preferences on how his code has to look.

If the nature of your Apps makes it possible to spilt into different .app's, do so, even if if you have to stretch a bit to call up routines / classes in other apps. vfp9 makes such things possible which did not work in older versions, like having application specific base classes in different parts of the app. Don't build one 50 - 80 megabyte exe. Try NOT to depend too much on inheritance alone, but aggregate smaller objects, perhaps with a simple factory pattern to make changes quick and painless.

Make sure every programmer KNOWS the wrath of god will decend on him if code is duplicated instead of put into a function/method. Take the time to formulate a sheet of coding practices anybody has to adhere to.

Distribute different parts of the app to different programmers (each with a backup of course) so everybody can feel responsible for "his" code. BUT ALSO implement regular code reviews, where everybody gets his turn of having his code scrutinized.

Testing:
Try to create a good contact between developers and testers: let the developer decide if a module is ready for testing. If I know big parts will be changed, I flag those modules so no effort is wasted on the test team and then by me explaining why this is no "error". OTOH I sometimes flag new modules I was not able to test as rigorously as usual, but which will not be altered later, so any remaining bugs are flashed out early. Smack any developer who tries to hide "problematic" modules just to get the next release out of testing.

Make sure the person responsible for building and pre-testing is METHODICAL and motivated. He can filter out problems early eliminating unneccessary work later. This person can ruin any budget if lousy versions are forwarded to the test team.

Build or buy a tool to get documentation from the source.

Get everybody together once or twice a month *during work time* for a couple of bottles of sparkling wine and crackers.

regards

thomas