BDD and TDR help focus on client needs (write the ‘right code’ as opposed to the ‘code right’, as achieved by TDD). However, tooling is more developer-focused for BDD, and business-analyst-focused for TDR.
Therefore, TDR appears to me as a great tool, when business analysts are well integrated with developers. For example, they are part of the same Scrum team, or at least available regularly during the course of an iteration for the Sprint Planning and for conversations aimed at explaining what’s behind the story. TDR helps in making sure that all parties are clear regarding what should be coded (and what has actually been coded), while having no more than a simple user story to begin with. TDR is then mainly a communication tool between technical people and business people.
See a post by James Shore for more on that aspect of TDR.

However, I feel that BDD is an appropriate tool when developers receive specifications from an external team of business analysts, written maybe several iterations earlier. This is not an ideal situation, but it does still occur. In this case, developers should not waste their time with a tool such as Fit which is not the most efficient from their point of view.

BDD also seems great when the whole team is made of very technical people, able to read source code everyday on their own machine. Committers on an Open Source project would be a good example (how often do you ever hear of business analysts contributing to an OSS project?). Another example would be small and focused teams in start-ups that have an excellent understanding of what should be implemented (especially if this team is the one that created the start-up, as it often happens).

Last thought: just like other techniques (such as Pair Programming), it might be that BDD increases cohesion within the team, while creating protection from an outside world that is not as agile as the team. So it is possible that future improvements on the project such as integrating business people in the team might be harder to achieve.

If you can read French, check out this discussion on the XP France mailing list.

Here is a look to the RichNesse editor (note the button bar on top)

Compare to the old editor:

There are four features that make the difference:

• Undo/Redo; yep, it seems that everything you do while under the editor can be undone
• Search and Replace! That was not in the basic editor. So when you wanted to change the name of a variable, you had to copy & paste into a text editor, and copy back again. It’s now built in!
• one button to insert a whole column: saves tons of keystrikes
• a button that redirects to the upload section of Fitnesse; that was not in the basic editor.

Unfortunately, I spotted a number of limitations. None of them are very serious, though:

• Some formattings very specific to Fitnesse such as collapsible sections are not available yet.
• The Copy and Cut buttons did not work and Paste behave curiously. The message I got was that my ‘browser security settings don’t permet the editor to automatically execute cutting operations.’ Of course, Ctrl-C, Ctrl-X and Ctrl-V still work perfectly.
• Integration with Fitnesse is not perfect. For example, if you create a table, the wizard will allow to enter a ‘caption’. Unfortunately, this caption will mess up the display and prevent the table from being properly interpreted as a fixture.
• The editor that opens when you first create a page is the basic Fitnesse editor. This is not a big deal: you can always save the empty page and reopen it again.

Another feature that I’d like to see, but will no doubt be tricky to implement, would be some kind of search & insert feature for links to other pages. Fitnesse is rather complex on this, especially since it supports hierarchical pages (a concept not usually found on wikis). It’s be cool to be able to search for a page, and then specify whether you want to link to it as a sub-page, or an absolute URL, or even as a SymbolicLink.

All in all, it is a very useful addon to FitNesse, one that I now systematically install. No doubt that lots remain to be done, but come join the fun now, it is already worth it!

Note the RichNesse button on the left when viewing a page; the Edit button is still available

Well, I’ll have to make up by going to CITCON Amsterdam in October! Who’s joining me?

<reporting>

  <plugins>

    <plugin>

      <groupId>org.codehaus.mojo</groupId>

      <artifactId>cobertura-maven-plugin</artifactId>

      <version>2.2</version> <!-- use last version available -->

    </plugin>

   </plugins>

 </reporting>

Finally, to get the actual report, you must remember to run ‘mvn site’. The reports will *not* be generated when simply running the unit tests.

For configuration, you must add a <plugin> tag in <build><plugins>; this is optional if you are only interested in Maven Site Reports. Remember: this does *not* mean that coverage analysis will be done when testing or running the code, only when running “mvn site”.

If you want the coverage reports directly under Hudson (and are not satisfied with publishing the maven site reports), things gets messy. There is a plugin for this, but I couldn’t get it to work (some people report that the current version, v0.8.4, is broken; it could also be because I’m using a Maven 2-type job under Hudson, which is not the most stable)
First, install the Cobertura-Hudson plugin.

This plugin requires XML reports to be generated by Cobertura. Looks simple enough according to the documentation.
The wiki page for the Cobertura plugin states that the configuration should be done in the <build> tag, but that didn’t work for me. In my case, I had to do it in the <reporting> tag, as follows:

<reporting>

  <plugins>

    <plugin>

      <groupId>org.codehaus.mojo</groupId>

      <artifactId>cobertura-maven-plugin</artifactId>

      <version>2.2</version>

      <configuration>

        <formats>

          <format>html</format>

          <format>xml</format>

        </formats>

      </configuration>

    </plugin>

  </plugins>

</reporting>

That’s it from me. I hope you’ll have more luck than me with the Cobertura plugin. Anyway, don’t forget that you can always look for the report on the Maven-generated site. You can even create a Bookmark to it, since the page is stable (except when the build overrides it, of course).

Sun has started what they call the GlassFish Awards Program. Under it, contributions to some projects are eligible to cash awards. One of these projects is Hudson, and what’s important is that not too many contributions have been made so far, so it is likely that yours could actually get money!

Many types of contributions are accepted: courseware, user-groups, plugins… as for me, I intend to submit the translation to French, as well as my Fit plugin — that is, if I can get moving before it is too late ;-)

It is not easy to say how much money can be made. It depends on the quality of the submission, but also on the number of submissions that are accepted. I guess it should be rather easy to make a few hundred US$ (of course, as Kirk Pepperdine says, that’s probably only a couple of euros ;-) ).

How wrong I was when I said that Sun was not founding Hudson much!

This is now a book I regularly point to at the end of the Scrum courses that I give for Valtech Training.

What can you do if you want to help?

• visit the wiki page for the French translation: it provides the latest status of the effort
• report typos, alternative translations, anything that can enhance the current translation. Do this on the above-mentioned wiki page (an email will be sent to me automatically), or get in touch with me directly (via a comment to this post, for example)
• if you are a contributor to Hudson, join the internationalization effort
• translate the plugins; I have hardly worked on any plugin at all (except the Fit plugin, which I have written myself). This is the area that needs most work.
• demonstrate Hudson in French to your French-speaking colleagues! for this, simply change the preferred language in your browser to French
• spread the word about Hudson!

Generally, once committed, enhancements to Hudson are released within a couple of days. So anything you contribute will be quickly visible.

I am looking forward to hear from you! And many thanks for your time and efforts.

Let’s assume here that all your stories are dimensioned using story points. I personally like using “story points” for estimating features, as opposed to “ideal engineering time”, but this is a debate for another time. Let’s just start with story points.

If it all goes according to plan, you should have a whole range of stories, with sizes going from 1 to 21 (or 40 & 100 when you want to make clear that some stories are really big and need to be detailed more in the future). Let’s further assume that you know your current velocity (if this is your first sprint, Mike Cohn recommends either doing rough estimations in hours, or just let the team loose and see the results at the end of the sprint — see his book Agile Estimating & Planning for more on this).

Simply put, you want to be in a position to fit “many” stories into a single iteration.

Having “many” stories is important, because the more you have, the less risk you carry. Suppose that you have only 3. If things go just a little bit wrong, then you’ll miss your Sprint goals by a third (remember, you do not demonstrate or release partially implemented features, right? and testing is part of the implementation effort, right?). Missing objectives by 33% is a lot in the agile world. You appear to have done badly, despite the fact that you still might have complete a significant portion of the remaining code. Even if you have done 95% of the tasks, you still have only 66% of the features — supposing that you tackled the three features in order of priority. Yes, you will probably complete the remaining 33% in the following iteration, and more. But still, your client only got 66% of the features at the date you agreed on. Plus, your velocity will vary greatly between iterations, giving an impression of unevenness and unreliability.

So the strategy is simply to split your features into smaller functional chunks to get closer to “95% technical tasks implemented = 95% features implemented”. My rule of thumb is to aim for 10 features. Some will be bigger than others, but all will be rather small.
In practice, this probably mean that you have a mix of features of size 1, 2 and 3. I might accept one size 5-story occasionally, but I’d keep an eye on it while the iteration is going.

Interestingly, this means that velocity for most of the teams using that strategy will be between 10 and 50 story points per iteration. Reaching 50 points or implementing more than 20 distinct features might be a sign that you are ready to try shorter iterations.

Finally, note that this is, as always, only a step in the never-ending quest to Agile nirvana. Once you’re confortable with having many small features, the next level, besides shorter iterations, could be to force all features in an iteration to be of size 1. That would be a nice improvement. “Our velocity is 12″ would always mean “we are implementing 12 features”. Also, it’d be much easier to select features during the Sprint Planning meeting. I wonder if someone has already been that far.

All the ideas are there, but I wished the journalist had not literally transcribed my talk. You might also want to check out this version, automatically translated by Google. Rather awful to read, but the content is there.

Congratulations, Kohsuke! You deserve it.