[Javacavemaps-developers] TEAM

[Larry G. <jav...@ya...>]

TEAM  (Together Everyone Achieves More)

1. A desire to work together.
2. A game plan for success.
3. We will talk about the plan.
4. Mutual goals, common source of motivation.

1. Means working together on various levels and various roles.  The military has a teaching that once a leader makes a decision he sticks by that until the smoke clears. Then he can next time choose an alternate decision if he saw that it was a mistake the first time.  This is to prevent indecisiveness based on emotion.
Anyway as a person who has the final say in this project, I feel I must make some decisions and stick to my guns so to speak.  We have several levels of working together based on experience or mileage.  Programmer Role with Developer Role with Architect role.  Developer with Admin role or Editor roles.  In basket ball you have guards and various other positions, same in football, quarterback, linemen etc.  Why should it be different in TEAM programming.  But like Sean said, we have the sandbox  area the javacavemaps.sf_id.case1  .. case2 ..case3   In this area you may place any source related to the project and free form at that. Try to figure out where you might fit in best. For example if you feel you are best at hacking method logic but not much more, then hey the developers can make work for you.

2. I mostly have set the game plan as XP style development of the project.  I utterly feel this can work out if we just say, "it probably won't  work but we are going to do it anyway, we will try to make it work." I feel more strongly about it than that however.  Especially the limiting scope/scale/granularity. Its tough to do, I've been that cowboy coder so much myself.  Software is developed meaning it grows and it doesnt grow so fast that it needs total rewrites. Communication via rapid firing of emails will be the main way to make this XP style work out. With the 2 to 4 week iterative development cycle we need to stay in close contact if you have been assigned a task in the task manager. Any situational changed that develop which would limit your ability to complete the task means we need to drop the task, reduct its scale/scope or split it up or assign it to someone else.. Simple as that. This means no preasure at all really. If we have to it will
 just get done on a later iteration. Also this would mean sticking to the XP principle of collective code ownership. Meaning if we have to split the task, or assign it to someone else and no one should have hurt feelings. I still expect notes in source to be made if someone makes some edit, they can claim it's their edit with a comment. Or if you create a class  the by all means fill out the author tags. Also make notes in the main Javadoc for the class if you author some part of it but didn't create it intially. 

3. Tell me your gripes and then tell me you'll help out according to the plan anyway. I'm not toally inflexible. Input is apreciated. It will help me to be better able to define the plan as well.

4. Mutial goals of playing or learning when it comes to hacking source, designing classes, interfaces, enumerations and pacakages. Playing and learning when it comes to software design and development. Playing and learning when it comes to managing a software project. Playing and learning when it comes to dealing with end-users. Playing and learning when it comes to using tools such as junit, ant, eclipse, jedit, xalan or whatever.



 Larry Gray
la...@ar...