Update on our eXtreme Programming (XP) project...
Category Software Development
I thought it might be of interest to share some on-going experiences with our application project using the XP methodology at work...
We spent the first week or so getting acquainted with the project lead, as well as reviewing the requirements from user interviews and learning a bit about XP. While some of the techniques of XP seem to be intuitive (like user stories for requirements), some aren't quite as comfortable at first glance (like pair programming). And while you can take bits and pieces of XP and apply them with some success, it's best to use all the methods in order to experience the "synergy" of XP. Alex and I are committed to giving it a fair try, so we're trying to do everything "by the book".
Last week was "user story" time. User stories are short two to three line descriptions of what the user needs to be able to do in a single task. This (at least for us) took the form of "As a [role, such as Customer], I need to be able to approve an invoice that has been submitted." In addition to this, there's a business reason as to why the user needs to be able to do this, and what a successful test of this would be. Since Alex and I are users as well as developers of this system, we played the role of the users and wrote the stories. Once those stories got finished, we placed them into high/medium/low categories and concentrated on listing the development tasks involved for the high priority stories. The final outcome of that process ended yesterday, when we came up with estimates as to how long it would take to develop each story.
The next step is tomorrow, when we have a planning session to determine what stories will constitute phase 1 of the system, and what stories will make up the first iteration. Iterations should be short (one to two weeks), so that feedback as to the direction of the system is constant. It also means that there is always a workable version of the system with some level of functionality being delivered every week or so. It definitely beats the "analyze for six months, code for six months, and end up with a system after a year that doesn't meet the new business environment when delivered" situation... The short iterations also allow for the system to change direction rapidly based on what the user sees and experiences. If after an iteration the user senses a new direction, then you write up new user stories, estimate them, prioritize them, and plan the next iteration cycle...
Now comes the confession... Alex and I cheated a little today... We started some pair programming and unit testing based on what we've come up with so far. We wanted to get started with one of the more unusual aspects of XP. XP states that you should devise your tests before you code, and then you should do pair programming to write the system. Pair programming is two developers sharing a single keyboard and screen. What sounds wasteful on the surface actually has some merit. While one person codes, the other is thinking about the direction that the code is taken. You have two minds solving the same problem, with the result being more solid code that isn't likely to end up in dead ends. We were both a little hesitant about this activity, as we both are more comfortable working alone. But after two hours of programming today, we are quickly becoming sold on it. A lot of good discussion came out of it, and we actually have tested, functional code to build on now.
The other part was unit testing... XP is built on the belief of "test early, test often". You are supposed to have automated tests that will run repeatedly so that you know all the code is functioning as designed. This testing allows you to refactor your code whenever necessary without fear of breaking code. If you refactor and the code still tests out OK, you're good to go. The most common tool is JUnit, which integrates into Websphere Studio Application Developer (WSAD) VERY nicely. We built tests to prove the connection classes, and it was great to get the "green bar" showing all tests ran successful. We're both pretty stoked that the combo of this type of testing linked with pair programming will lead to a very solid design.
OK... I've rambled on a lot here. I plan on updating the learning experiences here as we go along, so that you can get an idea as to how XP might work in the real world. Now that we've actually done some of the techie parts of XP, we're thinking this is gonna be fun!
I thought it might be of interest to share some on-going experiences with our application project using the XP methodology at work...
We spent the first week or so getting acquainted with the project lead, as well as reviewing the requirements from user interviews and learning a bit about XP. While some of the techniques of XP seem to be intuitive (like user stories for requirements), some aren't quite as comfortable at first glance (like pair programming). And while you can take bits and pieces of XP and apply them with some success, it's best to use all the methods in order to experience the "synergy" of XP. Alex and I are committed to giving it a fair try, so we're trying to do everything "by the book".
Last week was "user story" time. User stories are short two to three line descriptions of what the user needs to be able to do in a single task. This (at least for us) took the form of "As a [role, such as Customer], I need to be able to approve an invoice that has been submitted." In addition to this, there's a business reason as to why the user needs to be able to do this, and what a successful test of this would be. Since Alex and I are users as well as developers of this system, we played the role of the users and wrote the stories. Once those stories got finished, we placed them into high/medium/low categories and concentrated on listing the development tasks involved for the high priority stories. The final outcome of that process ended yesterday, when we came up with estimates as to how long it would take to develop each story.
The next step is tomorrow, when we have a planning session to determine what stories will constitute phase 1 of the system, and what stories will make up the first iteration. Iterations should be short (one to two weeks), so that feedback as to the direction of the system is constant. It also means that there is always a workable version of the system with some level of functionality being delivered every week or so. It definitely beats the "analyze for six months, code for six months, and end up with a system after a year that doesn't meet the new business environment when delivered" situation... The short iterations also allow for the system to change direction rapidly based on what the user sees and experiences. If after an iteration the user senses a new direction, then you write up new user stories, estimate them, prioritize them, and plan the next iteration cycle...
Now comes the confession... Alex and I cheated a little today... We started some pair programming and unit testing based on what we've come up with so far. We wanted to get started with one of the more unusual aspects of XP. XP states that you should devise your tests before you code, and then you should do pair programming to write the system. Pair programming is two developers sharing a single keyboard and screen. What sounds wasteful on the surface actually has some merit. While one person codes, the other is thinking about the direction that the code is taken. You have two minds solving the same problem, with the result being more solid code that isn't likely to end up in dead ends. We were both a little hesitant about this activity, as we both are more comfortable working alone. But after two hours of programming today, we are quickly becoming sold on it. A lot of good discussion came out of it, and we actually have tested, functional code to build on now.
The other part was unit testing... XP is built on the belief of "test early, test often". You are supposed to have automated tests that will run repeatedly so that you know all the code is functioning as designed. This testing allows you to refactor your code whenever necessary without fear of breaking code. If you refactor and the code still tests out OK, you're good to go. The most common tool is JUnit, which integrates into Websphere Studio Application Developer (WSAD) VERY nicely. We built tests to prove the connection classes, and it was great to get the "green bar" showing all tests ran successful. We're both pretty stoked that the combo of this type of testing linked with pair programming will lead to a very solid design.
OK... I've rambled on a lot here. I plan on updating the learning experiences here as we go along, so that you can get an idea as to how XP might work in the real world. Now that we've actually done some of the techie parts of XP, we're thinking this is gonna be fun!
| Permalink |
Comments
I understand the sentiments all too well. Both Alex and I discussed the fact that we were a little unsure of and uncomfortable with the concept. But knowing that we both felt the same way, and both had a commitment to trying it out, it made the adjustment period a lot easier.
Having said that, I'm sure we can all think of people that we wouldn't want to be paired up with for more than 10 minutes. I'm not sure I'd be so enthusiatic about the concept unless I was comfortable with the person I'm pairing with. Alex is really good, and neither of us are obnoxiously opinionated. I could also imagine pairing with a former co-worker (Joe Litton) with very good results.
I'd recommend giving it a try in order to see what happens. I'd also recommend getting the book eXtreme Programming Explained by Kent Beck. It will explain a lot of the techniques so that you can place everything in context.
Posted by Tom Duff At 13:08:19 On 18/07/2003 | - Website - |
give it here...
my turn...
I wanna write!!!../
go away...off with you..
Ok, after careful beatings we shall end this now.
Posted by Chris Miller At 07:42:20 On 21/07/2003 | - Website - |
Posted by Richard Schwartz At 21:15:07 On 21/07/2003 | - Website - |
Thanks for the post, I'm definitely following your XP experience with interest
Posted by At 11:43:53 On 18/07/2003 | - Website - |