* DougBlaszczak
	* ManojJha
	* GregJones
	* LeonKing
	* DrewNorris

----
This is how we got into ExtremeProgramming. First, our team just wanted to get an 'out of control' project under control. To do this, we had to discover:
	* what the process was
	* the requirement document that was being used was not detailed.
	* there was no design phase, design as you code

We started with the requirements. We create a requirements document that would be detailed enough to be used effectively during our design phase. We met with a group of users in a set of JAD session and created a UseCaseScenario document.

Having completed UseCaseScenario document, we created the requirements using Rational RequisitePro. This gave us the ability to give the Management team an rough estimated completion date. The did NOT like the dates. So they told us the dates they wanted and we had to meet those dates (notice that the management team reacted to the rough estimated dates without letting us even complete the true detailed design so we could give actual educated estimated dates of completion). I suggested that we break things down into 'groups of functionality', complete design and then give them dates based on a priority list of what the users thought was important. My manager didn't believe this would help but I finally asked him in a whining kid-like voice '''Would you just let us do our job and we will give you what you need!'''. He reluctantly agreed.

We used Rational Rose to model the requirements using UML. We just created the UseCases and SequenceDiagrams. This was enough for us to go off and create a '''group of functionality''' estimate and a pretty good look at the system.

So when we calculated the time to complete the new code plus add in the time to refactor the old stuff, we where still off by 30 days. We needed 3.5 months but where only given 1.5 months. So, we had to chop off some features. The user agreed with it and we got the schedule to task all programmers at 100%. At least it wasn't 110% or 150%.

The next hurdle was to prevent the new code from adding additional bugs into the system that would case UAT to on forever. This is when the ExtremeProgramming book '... Explained' was discovered. Since we already had a story like environment, and a small group we tried to implement the mind set and the unit testing in the current release. Due to this happening, we were able to scrap the schedule for refactoring all together. 

The plan:
	* Implement UnitTest''''''s into the code.
	* Test the code
	* What breaks, refactor
	* Update the project when a task is completed, add a task when refactoring is needed.
	* Those that are done with their assigned tasks before the release date will pick-up the slack of others due to new refactoring tasks being added. (No one owns any code, since our team is a group of senior developers, no problem.)
	* Check daily on the release date, if it slides, cut something out. Goal: ReleaseProductOnTime.

'''Current Status of our implementation:'''
	* Refactored more than originally planned
	* Completed more than originally scheduled
	* Team is happier than they expected to be at this place in development.
	* Management is receiving realistic metrics, They like it.
	* Team is excited :)

See OasisProjectBugList.
----
''Last updated 2000/10/01 - any more news? This looks really interesting and exciting.''
----
CategoryProject