There is one trade off. They almost never know what a customer wants. Most frustration in projects is in this part. Developers build what they think a customer wants, a customer thinks the developer speaks his language and doesn't need many words. Both wrong. When you find a developer who does know or a customer who can speak nerd language, call me! There must be telepathy or magic working there.
So, we can say that both the customer and the developer live in their own world, they speak there own language, have their own fun. And all in all, the don't understand each other, but say they do. The trick here is that both should stay in their own dimension and talk a language both can understand. One way I like very much is the way of the use case. It's not a perfect way, not a holy grail, but then again, nothing ever really is. It comes close though, both people can stay in their comfort zones and talk their own language but understand each other, because they understand use cases.
Goal
In a use case a customer defines what he wants, not how he wants it. The developer can make how he wants it. What now exactly should be in a use case then? Well one of the most important thing is a goal. This should be a short, SMART, sentence what the customer wants to achieve when the change requested is implemented by the developer. Erhm, a what? Glad you asked. SMART is a abbreviation of the following: Specific, Measurable, Achievable, Relevant and Time-bound. Which means a goal should be very clear and because it's measurable, there should be no debate whether or not the implementation of the change is correct or not. A goal should never be ambiguous. One of the features of a SMART goal is about achievable; can it be done; do we need extensive resources to pull this off, or is the goal realistic? Is the change relevant at all? Is it relevant to the project? And last but not least make it time-bound. There should be a timed element in a goal.
Actors
When we defined a goal we start in defining the actors which are needed to achieve the goal. We don't talk about the developer or certain persons, we talk more generic in the way of "a customer", "a sales employee", "a marketeer" and so on. All persons needed to achieve the goal are summed up. To be honest, in most cases there are one or two actors.
Scope
One of the items I like most. Scope sounds simple, but it can be so hard to define. Everything you don't mention in the scope is up for debate. So besides defining what is inside the scope, it's important as well to define what is outside of the scope. This defines the narrow barrier of what a customer thinks he will get to what he actually gets. Scope is mandatory to define, this is the point where are discussions are spawn from. When talking about software change there should be a definition here about what the change should imply on the system and what is should not do.
Preconditions
Preconditions or requisites are the elements or changes that should be in place before this change can commence. Think about version numbers, hardware capacity or even any other change that should be implemented before this change can be made.
Description
What should go in the description of a use case? Well start with the main success story (MSS). Define the happy flow through the application when this change is made. Did you finish the happy flow? Nice, work on a couple of failure scenario's now. When will the change fail? What message should the user get? A tester will use these scenario's to define if the change is successful and if all fail cases are hit.
To make sure a customer gets what he wants and to ascertain it is of a certain quality, do describe precisely how the application should work when the change is implemented.
This is about the smallest form of use case I use, or allow to be used. If a customer cannot define a use case in this form I will try to help him, interview him and educate him. If the customer understands the how's and why's of a use case he will never want to make incomplete stories anymore. He will find a quality change when he delivers a good use case. But bare in mind that he needs some help!
Template
Although I hate templates because people use them as they are, instead of pragmatically convert them for their own use, I believe in this case that it can help a bit.
- Number: each use case has a unique number, so it can always be referred to.
- Name: a use case has a name which uniquely identifies the use case.
- Goal: every use case should have a SMART goal
- Actors: define at least one actor. A system can also be an actor.
- Prerequisites: any law, rule, system that should be respected or interacted with.
- Description: the main success story and preferably a fail scenario.
- Exceptions: any exceptions on this use case
- Result: what is the remaining product when the use case is finished. Use this to measure if the use case is achieved.
- Trigger: describe the trigger, if any, that fires the use case.
More
http://alistair.cockburn.us/Use+case+fundamentals
No comments:
Post a Comment