This post originated from an RSS feed registered with Java Buzz
by Weiqi Gao.
Original Post: How Many XP Practices Do You Follow?
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
A spontaneous discussion about eXtreme Programming broke out yesterday at OCI North.
We all agreed that we are pretty agile, but we are not strictly XP. We agreed that we do the XP thing when it made sense (to us) and that we are not fanatical about XP. For most of us, this is the most agile project we've ever been involved with.
Here's what I think we measure up against the XP practices:
Code Practice 1: Code and Design Simply
I think we are merciless in this regard. "Take it out!" is the most often heard phrase on this project. "If all the getter is doing is to return the attribute, get rid of the getter and make the attribute public," said Jonathan to me once.
Code Practice 2: Refactor Mercilessly
We do quite a bit of refactoring to our code, usually right after all the tests pass. "I don't feel comfortable with the code" is reason enough for a bout of refactoring. What I have learned is that reducing code duplication should not be the only criterion. There are places where we pay the price of code duplication to make out intentions clear.
At any moment, we have a list of incomplete features and bugs, the "broken windows" list, and a list of working but smelly codes, the "dirty windows" list. We had a few "window cleaning days," days dedicated to work on "dirty windows."
Code Practice 3: Develop Coding Standards
I don't believe we have a coding standard written down somewhere. But we code "as if" there is a standard, and it shows.
Code Practice 4: Develop a Common Vocabulary
Again, it's a naturally emerging thing. We learn from the customer pretty quickly. "If the user click the Foo button, a Bar message should be sent to the processing engine. I don't know what Foo or Bar mean, but that's what should happen, because Mark told us so."
Developer Practice 1: Adopt Test-Driven Development
We write lots of tests. But I can't say tests drive our design. Functionalities are hashed out in meetings around the round table. We write design documents in AFT now. (Jonathan came on board the AFT train yesterday.) For most of the new classes, I know how the class should be at the start. I do write unit tests to "lock the class down" before I commit. I think we write tests first more often when we do bug fixes.
Rob noticing that the number of unit tests has grown to close to 200 started the impromptu XP chat.
Developer Practice 2: Practice Pair Programming
We don't do pair programming. We do shout out questions to each other. We can see each other by just turning around. I don't know if two developers looking at the same file on their respective computers and talking with each other count as pair programming.
Developer Practice 3: Adopt Collective Code Ownership
Quite the contrary, we adopted individual code ownership. When something goes wrong, say at line 147 of Foo.cpp, we use "cvs annotate" to find out the revision number and the committer of the problematic code and then look up the commit comment and the ChangeLog entry for that change. The committer usually can recall the rationale of the change.
The ChangeLog, I think, is something that should be promoted as a "Good Idea." Prior to this project, I only used ChangeLogs when sending in patches for Open Source projects. Most of the projects I worked on require a commit comment. But having all of those comments in one file makes things that much easier.
Developer Practice 4: Integrate Continuously
We do it with cron and a shell script. The build is hourly, and the 6:00pm build always send out an email. The other builds send out an email only if the build fails. No fancy web pages, not red and green lava lamps. But it works.
Business Practice 1: Add a Customer to the Team
We are on the phone with them all the time. They can also email bugs to our request tracking system. We have seen some major requirement drifts. But since the communication happens on a daily basis, both sides have a realistic view of both the feature set and the schedule, especially for the short term.
Business Practice 2: Play the Planning Game
I'm not involved in the planning part. But at any moment, I have one and only one priority that I devote all my time to. Once that is done, the next priority arrives. Somebody is doing the planning, and is doing a darn good job at it.
Business Practice 3: Release Regularly
We tag the repo on major milestones. And the cvs head is always in good shape. And they do pull from cvs head.
Business Practice 4: Work at a Sustainable Pace
I was never asked to do overtime in the last seven months. And our phase 1 code is in production! We celebrated today.
All in all, we follow the XP practices pretty closely, with the exception of pair programming, collective code ownership, and maybe the spirit of test-driven design.
We did not set out to do the project in XP. Actually, I didn't even remember what the 12 practices are until I started this blog entry. Most of the things that we do we do naturally.
How do your project meature up against the XP practices?
Previous Topic
