Iteration #1

This afternoon was spent doing iteration 1. Our initial task list was:

• Get people up to speed on RubyFIT
• Determine how to run FIT from within Eclipse
• Perform a spike to determine feasibility of using the cgi library (through Apache)
• Perform a spike to determine feasibility of using a basic built-in Ruby server
• Determine how to deploy the server so our real world customer can view
• Write pages & output result for single test

Now the test is done, and we have the following issues we talked about in our iteration retrospecitve:

• Story was simpler — Our initial impression of the story was more complicated than it turned out to be
• Delivered! We got the spikes done and the deployment proof of concept finished
• Didn’t have a repeatable process — were a little lax about things as we did the spikes
• Need cleanup of various things before concept is ready for real usage
• We rushed to finish (the time structure of the day had us rushing to get things done at the end
• Pairing worked well — both for spikes and for deployment
• FIT tasks not done — it was determined that FIT wasn’t going to be useful for the tasks today, so we moved the tasks to the end. We didn’t get to them in this iteration.
• Manual customer test — we did a test manually on both spike results. Didn’t get it automated.
• No unit tests (which we deemed ok for the moment, but which we will remedy as we stop doing proof of concept spikes
• Haven’t finished the process of determining which server method to use
• Completed a round trip proof of concept
• Planning game — some people felt like it was longish. We also discussed the possibility of running spikes prior to the planning game to help people visualize aspects. This does have the risk of biasing people towards certain paths, but Chris has found it useful and prefers it to planning then spiking. Brian added that the divide between abstract and concrete is based on the project, the people, with Brian tending to agree with Chris
• Estimates are deemed to be good enough for moving forward, though we don’t have enough information to fully evaluate them at the moment
• BC queried whether the risks we were spiking for were really risks — were we really unsure that the cgi approach would work, for example? Chris replied with a story about his client where they started with a spike for technology exploration at the beginning and how the initial spike helped get the development team to a base level of familiarity and comfort with the new technology. His developers were working with domain experts as well, and so doing it as a spike allowed the developers to not worry quite so much as the code. BC then asked that in Chris’ story, the technical risk was less the point than the information change. Chris clarified that there was technical risk — not so much as to whether the technology would work, but whether the team could work with the technology.
• Discomfort with FIT came up several times. Brian suggested coming to a group consensus about what acceptance tests ought to look like for this project. Lisa suggested learning FIT first before we can decide. Brian amended his suggestion to be learn our tools before doing much on production code
• Need to select an acceptance test approach

And thus ended iteration 1 (combined group discussion next…)

Estimation

We talked about how we were going to estimate the various stories. We decided to do estimates in stream half-days (one or two people (since there’s 7 of us – Bill, Brian, Lisa, Chris, Mike H., BC, and myself). Working down the stories in the last post, we came up with the following estimates.

One thing that I noticed (which Lisa was commenting on over lunch) is that it went a lot faster than I normally would expect. We weren’t summing estimates of each task, and our units of estimation were fairly loose (estimates were more against the other estimates rather than more attempts to accurately figure out our velocity (how many points we can get done during each iteration)

Stories for the Veterinary project

I’m working on the veterinary project. Brian has talked to a person he knows who is involved in giving this test, and talked about what they’re looking for in this application. We then talked about the user stories we could pull out of the description Brian gave us. Here’s the stories we’ve come up with for the application (in the extended entry). We did this by first listing them on a whiteboard (so we could all see them) and then transferred the stories to index cards.

We also identified a list of questions for Brian to go back to his contact to get answered.

Bill then had us try to come up with narrow stories so that we could show progress with each interaction (For example, the first three stories under the Questions & Answers section need to be partially implemented together so that we have an exam system, so we should reslice the stories into smaller stories that we use. The example he used was setting it up first to handle one case, with one test that you can choose to run or not, and one diagnosis. From there we would then grow the system in future interactions.)

Need to update

I just realized that while I can set categories for my posts, this categorization is not easily accessible in the archives. After I finish here at Agile Fusion, I’ll be updating the template to add that (and the links to my personal stuff blog that I promised earlier).

Plan for week

For the week, we’re going to split into two groups. One will work on extending RubLog, a Ruby blogging tool. The other group is going to work on updating/creating a computerized test for vetinary medicine. As part of the exam process for vetinarians, they’re given a test where they are given a case, have a chance to perform tests and at the end have to give their diagnosis(es — is that the plural?). Bill and Mike F. will be serving as XP coaches — Mike for the RubLog project and Bill for the vetinary tests. We’ll be working from 9-3 on programming and then spending the afternoon discussing the morning. The evenings are for breakout sessions, with the goal being that there is enough going on each evening that people are torn.

Those interested in taking a peek at the proceedings may want to point their browsers at the web cam image The image is a video/audio feed from the Satisfice lab. If bandwidth becomes an issue, we may unplug it, but until then, you can get a peek at how things are going there.

Goals of Agile Fusion

After dinner, we began the process with introducing ourselves and discussing our goals for the next week. There’s a very good mix of programmers and testers here, and I’m even more excited about this week than I was before getting here (assuming that’s possible). Here’s the notes from the goals session (in the extended entry which I’ve never used in Moveable Type before).