At Channel One in Hamburg, Germany, we're developing a shrink-wrapped intranet application suite.  Our project underwent some dramatic productivity improvements when we started to adopt XP.  Since September 99 we have the complete set of recommended practices, as we understand them, in place.

Our main team consists of a dozen developers, one Web designer, and a full-time customer.  We're working together in one large room, facing the beautiful docks of Hamburg.  Team spirit is very high, people enjoy working this way.

We've shipped in February, in June, and we've done a gorgeous version 2.0 in September.  We're still doing XP, better and better...

-- FrankWestphal

----

I'll try to keep reporting on the remainder of this page about what we've learned about several practices.

'''Conducting methodology-tuning workshops'''

	* At the end of the iteration, our team comes together in what AlistairCockburn calls a methodology-tuning workshop.

	* During this workshop, team members (even the customer) answer the following questions:

		1. What worked well?
		1. What problems were encountered?
		1. What are areas for future improvement?

	* After discussion, we decide how to change and adapt.

'''Engaging an XP coach'''

	* XP requires teams to unlearn some old ways and acceptance of new ways to gain all the benefits from XP.  TransitioningToExtremeProgramming is certainly not something to take lightly.

	* Since the XP practices support each other to the greatest possible degree, the whole process can be very fragile.

	* Therefore, have a dedicated coach to help and notice when the team is deviating from its process.  Don't try to adopt XP without a coach.

'''Testing private methods'''

	* We've found that UnitTestingNonPublicMemberFunctions seems to be of CodeSmell''''''s.  Testing private methods smells of debugging.  Testing private methods also prevents us from being able to RefactorMercilessly.

	* If you ListenToTheCode, you'll learn that MethodsShouldBePublic.

	* Therefore, execute the ExtractClass refactoring, have all the former private methods be publicly accessible, and test them ruthlessly.

	* You may end up with a reusable abstraction whose responsibilities will grow over time.  It's a roadmap to lots of little pieces which is a GoodThing.

'''Writing AcceptanceTest''''''s for Web applications'''

	* In general, have a layer representing workflow or business processes, so that you can write most of your AcceptanceTest''''''s against this facade.

	* Make the mediating layer between the ApplicationFacades and your dynamic HTML pages as thin as you can afford.  That means really thin, so that you don't have to have extra tests for your servlets.

	* If need arises, have the dynamic aspects of your web pages output some trace info embedded into HTML comments that you can parse and check for in debug mode.

	* Don't try to compare raw HTML data streams.  Actual and expected HTML data will likely differ, since the web designer on your team is practicing CollectiveCodeOwnership, too.

	* Adhere strictly to the OnceAndOnlyOnce rule to code URLs, style sheet classes, client-side scripts, etc.

	* We've found the costs for testing JavaScript interactions not to be worth the risk.  If you find a nice solution, please let me know.

''More to be posted in the days to come...''

-----

I second Frank's comments about the beautiful view from their rooms into the docks. I love this city with all of my heart and rooms like this are just great.  -- MarkoSchulz

----

''Is there a more recent news? The last update to this page was November 2000 ...''

----
CategoryCompany