This morning was Paul King's presentation on 'Agile Developer Practices for Dynamic Languages.' Although we're not using Ruby or Groovy, with the updates coming in .NET 3.5, it was still good to see what challenges we could face in the future. Some of the notable points I thought were:

• Patterns are embedded in the language so you don't need to reinvent the wheel. For instance, you can get the 'Visitor' effect by using closures.
• If you're using a dynamic mock framework (I'm not) then you can get very similar behaviour by using maps. Actually Paul went further on this and claims they've reached a point where unit tests are disposable. Apparently the code for the mocks that describes class behaviour is identical to the code in the real classes and so they can generate one from the other and vice versa. I'm a tad skeptical about this.
• Aspects are built-in to the language, although you may still want to use a framework at times

I was a bit surprised to hear a few under-handed jabs at Microsoft technologies, but it seems to be a recurring theme throughout this conference. Ah well.

In the afternoon I went to Mike Cohn's talk on user stories. Mike is a very experienced presenter and the session was completely packed. Although I've read his book on the subject, it was still good to go over the basics of what makes good user stories and I found it especially useful to hear some of the examples of refactoring 'developer' stories into value-proposition ones. The slides for the presentation can be found here. A few notable points were:

• Waterfall is comprised of three sections: the fuzzy front end, the "middle part" where stuff gets done, and the rapid descoping phase :)
  
• Estimating a software project accurately is as likely as a salesman or businessperson being able to say how much money (to the dollar) the company will make this quarter/year/whatever.
• Stories written in the first person help to make things more personal, and as a result people become more invested in the them.
• Try to imagine 5-12 (ballpark) user roles to help creat your user stories. In most cases, having a number outside that range either means you haven't thought about your users enough, or you're breaking them into far too many categories.
• (My favourite) Developer stories should be rewritten as value propositions

Looking at the slides, you can see some good examples of the last point. It's often tough to get a product owner to sign off on refactoring-type work items, but if you spend the time to phrase it in a way that shows how it benefits one of the user roles, you're much more likely to get acceptance.