As noted previously, I spent all of last week at the Better Software Conference. I was speaking on Thursday, but prior to that, I had the opportunity to attend a variety of technical discussions and workshops. Here is my coverage of the second day. Click here for coverage of the first day.
The beginning of the second day was much less exciting. I simply woke up and went downstairs to attend Alistair Cockburn's session Use Cases for Agile and Traditional Development. (Just for the record, his name is pronounced “coh-burn” with a silent “ck”.) I've read and own his book Writing Effective Use Cases and he's one of the authors/founders of the Agile Manifesto, and I wanted to see what the difference of Use Cases were between Agile and Traditional development.
The first half of the session was working and describing through what Use Cases are and aren't. He broke it down into a few key points describing how a UC should be succinct (as in less than 2 pages), communicate across specialties, describe what the system should do, record the decisions made, and a variety of other things. One of the most important aspects that he pounded on was that there are many requirements – especially Operational – that simply do not belong in UC's. Apparently in the past when he's said this, people tend to simply drop those requirements completely. To be very clear, he described it as “UC's should be section three of your requirements document”. This does not mean that every requirement can or should be captured in your UC's, but they should appear elsewhere.
One of the most important concepts he also explained – yes, it's in his book – is the concept of Goal Level. It is represented simply as Clouds, Kite, Sea, Fish, and Clams describing the various altitudes of the goals. He pointed out that quite often the customers will give you a single Cloud (high summary-level) with a handful of Kites (summary level) and expect you to build a system. Most developers will tend to create/consider the Fish (sub-function) and Clam (nuts and bolts) UC's. Despite all of this, in order to be effective and get useful stuff done, you need the Sea level UC's. These are the ones which describe particular pieces of user functionality and how to do them. For example, dotProject would have a UC of “Manage Projects” at the Cloud level, “Create Project” at the Sea level, and “Create the Project Class” at the Clam level.
He also pointed out that there are often keywords such as “display”, “click”, and “type” which are bad as they specify an input/interaction method as opposed to the interaction itself. He suggested replacing these words with “presents”, “selects”, and “input” respectively. My own observation of his stock “good” UC's was that everywhere the words “the system” appeared could be just as easily replaced with the title of a person. When I noted this to him, he described a customer who did just this to implement their system. Intriguing… In another observation I noted, it seemed like his “good” UC's could form the basis of a Users' Manual with the addition of a handful of screenshots.
Alistair also pointed out an interesting dichotomy. He noted that often Traditional development organizations already writing UC's have trouble going to Agile UC. He said that the basis of this comes from the traditionalists' difficulty to trim the document down to a few pages. Although a great deal of understanding is already in the mind of the users, they have a tendency to prattle on and on explaining things explicitly to a level of detail which glazes over their readers' eyes and then no one bothers reading the document, it sits on the shelf gathering dust, the project fails, and everyone complains about everyone else. 😉
Alternatively, Agile organizations have the benefit of already being succinct and have a high level of communication. Therefore, 1-2 sentences is plenty in getting the point across.
He wrapped up the whole session with an exercise. We were tasked with writing the UC's for a simple system. Each group hashed out their cases and discussed the results. Our group completely missed a handful of subtle keywords and got tied up in a couple irrelevant aspects. Yes, we were going after the Fish instead of staying focused on what mattered.
In summary, I would attend the class again if the discussion revolved around a specific project. The theory and preparation was all great and definitely needed, but I think doing it as a post-mortem or even a project kickoff would be immensely valuable.
If you're interested in learning a bit more about Use Cases, Alistair Cockburn and related things, check out these:
Agile Alliance
Alistair's web site
Wikipedia entry on Use Cases
Oh, and since I had a copy of his book with me, I went geek and had him sign it.
“Hello, my name is Keith and I've been a geek for ten years…”