Follow-up to Sam's recap of Sep 26

While in a way, it's true that this team's purpose is primarily to learn XP, and secondarily to produce good software, hopefully, the purpose of learning XP is to learn to use XP to produce good software. At this point, I think it would be good to explore what has worked, what has not worked, what of the good/bad is attributable to the XP process, etc.

First, the problem: What the customer asked for has some serious problems.

Now, that doesn't mean there's anything wrong with the execution, but of course, that's missing the forest for the trees. If we have a process that helps us do a really good job of implementing something while leaving us blind to the fact that what is being implemented is not as useful as we hoped, is there something about the process, or how we're doing it that could be improved in this regard?

By the way, I think that's exactly what we've done so far. Even with a team that only meets once per week, and often has little overlap in attendance between one week and the week before, we've been able to implement some really impressive features, and implement them in a very high-quality way. I think the XP process has had a lot to do with making this level of success possible in really awkward circumstances.

Again though - the question is whether these "really impressive" features have turned out to be the most valuable things we could have been implementing.

So, what is the role of XP in all of this? Well, one of the things XP is supposed to achieve is giving the customer what they asked for in small iterations, top priorities first, and allow the customer to evaluate results along the way, changing priorities at will (of course, we have been playing both customer and programmer roles). In our case, one could say that the customer really needed to have the story "Basic Standard Error Macros" done before anything else to have a good picture of what would be the outcome of all this work. It so happens that neither the "customer" nor the programmers aver did see the need for prioritizing this story higher until well into work on the second release!

Based on my recent reading, there are 2 common practices of XP that we've neglected so far (partly because I was not fully aware of them), either or both of which might have helped:

1. At the initial release planning session, on the back of each card to be worked on in the release, the customer and programers work together to describe a test (a user test, not a unit test) that, if it passed, would indicate that the story is completed. The programmers should be able to define the story as done when they can perform the actions described in the test successfully. Essentially, this is a testable specification for the story.

2. Implement and use an automated Customer Acceptance Testing system. This is a piece of code that can read some sort of a script file, table, or something, that could be easily written by the customer, and use that input to simulate the operation of the user interface at the highest possible level in the code. Essentially, this is a way to (almost) fully automate user tests. Here's a hypothetical example of what a simple script for our system might look like...

*make-new-access-project TestProject.mdb
*make-module basTest
'/<MacroDef name="Test1">
'/    Debug.Print "Test1"
'/</MacroDef>

'/<Macro name="Test1"/>
*end
*end-new-access-project
*start-session
*ui-open-access-project TestProject.mdb
*ui-select-module basTest
*ui-expect-pre-processed
'/<MacroDef name="Test1">
'/    Debug.Print "Test1"
'/</MacroDef>

'/<Macro name="Test1"/>
*end
*ui-expect-process-preview
'/<MacroDef name="Test1">
'/    Debug.Print "Test1"
'/</MacroDef>

'/<Macro name="Test1">
    Debug.Print "Test1"
'/</Macro>
*end
*end-session

The reason I think #2 might have helped is that these tests are not supposed to be as atomic as most programmer tests, and the customer gets to help write them. That might encourage the writing of tests that more closely resemble a real user session from the customer's perspective. This in turn, might give the customer a better vision of what they're really asking for, and whether that's really what they want. In other words "If these programmers work for weeks or months writing code to make this test pass, is that a -good- thing?"