I was inspired to seek out something like this after previously reading Mike Cohn's User Stories Applied (TODO: my review). It was in Mike's book that I found compelling hope that we could get away from the unwieldy requirements specifications used in my organization. These have traditionally served as the definitive record of what our software should do yet, they have never felt helpful or right to me. Indeed there is much evidence that they don't help at all, but that's another post...
In User Stories Applied, Mike answers the question I think everyone has after getting the quick overview of what a user story is: "Where do the details go then?" After all, given a story such as "As a hiker I want to view a list of nearby trail heads so I can investigate suitable hikes" one is naturally left with many questions. How far away from your current location should the software look for trail heads? Should you be able to vary that distance? What information should be in the list -- trail names? Dog / horse / mountain biking use allowed? etc.
The answer is that these details, rather than being captured in a traditional specification or use case documents can be very beneficially recorded as actual examples and acceptance tests. Understanding this was a real "aha" moment for me. Prior to this, user stories, estimating in story points, measuring velocity and using that to finally have some measure of what a team could accomplish in a fixed length iteration all felt right, but I couldn't quite figure out how we should do requirements.
Gojko's book opens by building the argument that traditional approaches to gathering and documenting requirements are flawed. I don't know that it would be hard to convince many people who've spent more than a few years in an environment where they must develop software based on the information in 100+ page requiremetns documents that this was the case. However, what Gojko does is to articulate well some reasons why this is the case. For me though, the real meat of the book is all contained in section II, which provides the concrete specifics of how to go about specifying by example and deriving acceptance tests.
The key points covered that I found valuable are:
- Confirmation of my own belief in the necessity of customer/domain expert involvement alongside testers and developers. Business analysts should not be a conduit (or worse, filter). There's a particularly good explanation of the role of BAs mentioned in the book drawn from Martin Fowler and Dan North's presentation The Crevasse of Doom.
- A detailed explanation of what make good examples.
- Commentary on the benefits of a project language -- a non technical business oriented vocabulary that enables unambiguous communication for the team.
- How to go about converting examples to acceptance tests.
- How to run specification workshops successfully. Besides the information in the bookon this topic I am currently quite enamored with the Nine Boxes approach to interviewing people.
Since reading the book I've had a chance to get a little hands on with the technique but not in anger. I took some of the ideas and applied them to something we had already done, where I knew plenty about the system to allow be to play the role adequately of customer, tester and developer. I turned 40 pages of crap documentation (no offense intended to the original author) into about three. I'm very much looking forward to seeing us apply this approach to the next release cycles of a couple of our products.
The third section of the book discusses how to go about implementing agile acceptance testing covering items such as how to get people interested in the prospect to the synergy the technique has with user stories and the various tools available for automating tests. There is one slightly dubious (but perhaps necessary under adverse conditions) technique mentioned which is altering one's language to avoid the use of the word "test".
The fourth section is pretty short, and covers how adopting this approach to specifications and acceptance testing alters the work of various roles. This was already covered in briefer terms earlier in the book. This section expands upon that, although to some extent it feels like a bit of a rerun.
All in all the book gets a definite thumbs up from me. My only real complaint would be that the writing style is a little dry, definitely not as readable as some authors. Nonetheless, the effort to read it has been worthwhile from my point of view and I would definitely recommend the book to anyone on a team looking to do requirements better.
No comments:
Post a Comment