Preface :
You can't always get what you want...but the customer should!
Great software development delivers what the customer wants. This chapter is all about talking to the customer to figure out what their requirements are for your software. You'll learn how user stories, brainstorming, and the estimation game help you get inside your customer's head. That way, by the time you finish your project, you'll be confident you've built what your customer wants...and not just a poor imitation.
Requirements :
All softwares come from requirements. Before you code, you have to know what you are going to create. So first step is to talk with your customer and try to record and understand the requirements. It is better to have a index card with title and description as below picture :
And remember one requirement should be a single thing the system has to do.
- Try to get additional requirements
Talking to the customer doesn't just give you a chance to get more details about existing requirements. You also want to find out about additional requirements the customer didn't think to tell you about earlier. There's nothing worse than finishing a project and the customer saying they forgot some important detail.
So how do you get the customer to think of everything you need to known, before you start building the software?
- Bluesky with your customer
When you iterate with the customer on their requirements, THINK BIG. Brainstorm with other people; two heads are better than one, and ten heads are better than two, as long as everyone feels they can contribute without criticism. Don't rule out any ideas in the beginning - just capture everything. It's OK if you come up with some wild ideas, as long as you're all still focusing on the core need that the software is trying to meet. This is called blueskying for requirements.
Find out what people REALLY do :
Everything (that's ethical and legal) is pretty fair game when you're trying to get into your customer's head to understand their requirements. Two particularly useful techniques that help you understand the customer are role playing and observation.
- Role playing
- Observation
Your requirements must be CUSTOMER-oriented :
A great requirement is actually written from your customer's perspective, describing what the software is going to do for the customer. Any requirements that your customer doesn't understand are an immediate red flag, since they're not things that the customer could have possibly asked for.
requirement should be written in the customer's language and read like a user story : a story about how their users interact with the software you're building. When deciding if you have good requirements or not, judge each one against the following criteria :
- User stories SHOULD...
- User stories SHOULD NOT...
Develop your requirements with customer feedback :
The steps we've followed so far have been all about coming to grips with the customer's ideas and refining those ideas into user stories. You execute these steps, in one form or another, at the beginning of each iteration to make sure you always have the right set of features going into the next iteration. Let's see how that process currently looks :
User stories define the WHAT of your project...
estimates define the WHEN :
After your initial requirement-capture stage you will have a set of clear, customer-focused user stories that you and the customer believe capture WHAT it is you're trying to build, at least for the first iteration or so. But don't get too comfortable, because the customer will want to know WHEN all those stories will be built. This is the part where the customer asks for the big question: How long will it all take?
- Your project estimate is the sum of the estimates for your user stories
To figure out how long it take to complete all of the requirements captured in your user stories, you need to use a two-step process :
- Playing planning poker
To come up with accurate estimates, you need to get rid of all those assumption that put your estimates at risk of being wrong. You want a set of estimates that everyone believes in and are confident that they can deliver, or at the very least you want a set of estimates that let you know what assumptions everyone is making before you sign on the dotted line. It's time to grab everyone that's going to be involved in estimating your user stories, sit them around a table, and get ready to play "planning poker" :
A BIG user story estimate is a BAD user story estimate :
Your user story is too big.
40 days is a long time, and lots can change. Remember, 40 days is 2 months of work time. An entire iteration should ideally be around 1 calendar month in duration. Take out weekends and holidays, and that’s about 20 working days. If your estimate is 40 days for just one user story, then it won’t even fit in one iteration of development unless you have two people working on it! As a rule of thumb, estimates that are longer than 15 days are much less likely to be accurate than estimates below 15 days.
The goal is convergence :
After a solid round of planning poker, you should not only have estimates for each user story but be confident in those estimates. The goal now is to
get rid of as many assumptions as possible, and to converge all of the points on each user story’s spread of estimates :
The requirement to estimate iteration cycle :
We’ve now added some new steps in our iterative approach to requirements development. Let’s look at how estimation fits into our process...
Tools for your Software Development Toolbox :
Software Development is all about developing and delivering the software that the customer actually wants. In this chapter, you learned about several techniques to help you get inside the customer’s head and capture the requirements that represent what they really want...
You can't always get what you want...but the customer should!
Great software development delivers what the customer wants. This chapter is all about talking to the customer to figure out what their requirements are for your software. You'll learn how user stories, brainstorming, and the estimation game help you get inside your customer's head. That way, by the time you finish your project, you'll be confident you've built what your customer wants...and not just a poor imitation.
Requirements :
All softwares come from requirements. Before you code, you have to know what you are going to create. So first step is to talk with your customer and try to record and understand the requirements. It is better to have a index card with title and description as below picture :
And remember one requirement should be a single thing the system has to do.
- Try to get additional requirements
Talking to the customer doesn't just give you a chance to get more details about existing requirements. You also want to find out about additional requirements the customer didn't think to tell you about earlier. There's nothing worse than finishing a project and the customer saying they forgot some important detail.
So how do you get the customer to think of everything you need to known, before you start building the software?
- Bluesky with your customer
When you iterate with the customer on their requirements, THINK BIG. Brainstorm with other people; two heads are better than one, and ten heads are better than two, as long as everyone feels they can contribute without criticism. Don't rule out any ideas in the beginning - just capture everything. It's OK if you come up with some wild ideas, as long as you're all still focusing on the core need that the software is trying to meet. This is called blueskying for requirements.
Find out what people REALLY do :
Everything (that's ethical and legal) is pretty fair game when you're trying to get into your customer's head to understand their requirements. Two particularly useful techniques that help you understand the customer are role playing and observation.
- Role playing
- Observation
Your requirements must be CUSTOMER-oriented :
A great requirement is actually written from your customer's perspective, describing what the software is going to do for the customer. Any requirements that your customer doesn't understand are an immediate red flag, since they're not things that the customer could have possibly asked for.
requirement should be written in the customer's language and read like a user story : a story about how their users interact with the software you're building. When deciding if you have good requirements or not, judge each one against the following criteria :
- User stories SHOULD...
- User stories SHOULD NOT...
Develop your requirements with customer feedback :
The steps we've followed so far have been all about coming to grips with the customer's ideas and refining those ideas into user stories. You execute these steps, in one form or another, at the beginning of each iteration to make sure you always have the right set of features going into the next iteration. Let's see how that process currently looks :
User stories define the WHAT of your project...
estimates define the WHEN :
After your initial requirement-capture stage you will have a set of clear, customer-focused user stories that you and the customer believe capture WHAT it is you're trying to build, at least for the first iteration or so. But don't get too comfortable, because the customer will want to know WHEN all those stories will be built. This is the part where the customer asks for the big question: How long will it all take?
- Your project estimate is the sum of the estimates for your user stories
To figure out how long it take to complete all of the requirements captured in your user stories, you need to use a two-step process :
- Playing planning poker
To come up with accurate estimates, you need to get rid of all those assumption that put your estimates at risk of being wrong. You want a set of estimates that everyone believes in and are confident that they can deliver, or at the very least you want a set of estimates that let you know what assumptions everyone is making before you sign on the dotted line. It's time to grab everyone that's going to be involved in estimating your user stories, sit them around a table, and get ready to play "planning poker" :
A BIG user story estimate is a BAD user story estimate :
Your user story is too big.
40 days is a long time, and lots can change. Remember, 40 days is 2 months of work time. An entire iteration should ideally be around 1 calendar month in duration. Take out weekends and holidays, and that’s about 20 working days. If your estimate is 40 days for just one user story, then it won’t even fit in one iteration of development unless you have two people working on it! As a rule of thumb, estimates that are longer than 15 days are much less likely to be accurate than estimates below 15 days.
The goal is convergence :
After a solid round of planning poker, you should not only have estimates for each user story but be confident in those estimates. The goal now is to
get rid of as many assumptions as possible, and to converge all of the points on each user story’s spread of estimates :
The requirement to estimate iteration cycle :
We’ve now added some new steps in our iterative approach to requirements development. Let’s look at how estimation fits into our process...
Tools for your Software Development Toolbox :
Software Development is all about developing and delivering the software that the customer actually wants. In this chapter, you learned about several techniques to help you get inside the customer’s head and capture the requirements that represent what they really want...
This message was edited 28 times. Last update was at 14/03/2011 18:35:12
沒有留言:
張貼留言