July 17th, 2006


One little milestone at a time...

Elliptical is definitely much easier on the legs than the treadmill. First time I've cracked an average of 6 MPH over a full workout (4.69 miles in 46 minutes) -- I could never do that on the treadmill, because my knees and shins would revolt within a few minutes...

Review: User Stories Applied

We're at the beginning of doing some process improvement at work right now -- due to changes in both the management staff and the projects we're working on, it seems the best time to shake up how we do things. As part of that, I was asked to dig up some good books on development processes, particularly on how to deal with the requirements problem. Best book I've found so far is User Stories Applied for Agile Software Development. (By Mike Cohn, published by Addison-Wesley, who seem to have cornered the market on engineering process books.)

This is one of those engineering books I just love: ruthlessly pragmatic, focused on what actually works in the field instead of coming up with mammoth and complex processes. The topic is "User Stories", and their use as a tool for structuring the development process. The short form idea is that you start by modeling your primary User Roles -- who are the people that are going to use this program, broken down by categories. Then you think up the "stories" for those users -- what they are going to do with the system. You don't go into much detail for each story upfront -- the story is really just a one-sentence description that you talk through just enough to get an estimate of how much work it will be. You maintain a prioritized list of these stories, and when one gets to the top of the stack, an engineer picks it off, talks with the stakeholders to figure out the details, and implements it. Simple and realistic: a nice change of pace in the world of programming. (And while the above sounds kind of obvious when stated like that, it is not how most software development works.)

The book goes into a great deal more detail, of course, showing how this fundamental idea is used for planning purposes, and how it interacts with a couple of the major Agile programming models (particularly XP and Scrum). It does require an open mind, that is willing to cope with the idea that one doesn't have to have tons of formal documents in order to run a software project; in general, the approach's XP origins show through. But I think that, if you can go through it without too many preconceptions, it's well worth the read. The writing is clear and concise, it is very well organized, and it has small examples sprinkled throughout, with a long section at the end detailing how a sample project might run. Even if you don't buy into all of its prescriptions, the ideas in here are well worth thinking about carefully.

A-grade work. IMO, probably worth a read for any high-level engineer or engineering manager, who is interested in thinking about how to organize and manage complex software projects.