Wiley Leveraging Drupal: Getting Your Site Done Right 978-0-470-41087-5 사용자 설명서
제품 코드
978-0-470-41087-5
Chapter 1: Keeping It Simple
with the website application. Doing it this way (asking who will use the site, and, for each of the roles,
what they are going to do when they interact with it) guarantees that you can cover all the functionality
required and come up with a complete list of user stories.
what they are going to do when they interact with it) guarantees that you can cover all the functionality
required and come up with a complete list of user stories.
Start project
Main
Process
Flow
Process
Flow
Write User
Stories
Plan the
Release
Estimate
Velocity
Estimate
Use Stories
Prioritize
Use Stories
Allocate
Stories to
Iterations
Identify
Customer
Identify
Roles
Do
Iterations
Continuous
Build
Figure 1-1
At this point, you have all your user stories, perhaps written on 3
×5 cards and spread out on a table in
front of you, or on a magnetic board, or taped up to the wall, or whatever. So you can do the planning.
This involves making an initial estimate for each user story, taking advantage of the fact that each user
story is a semi-autonomous chunk of functionality that can be dealt with independently. Then, you
create a way of putting the estimates in context on the basis of the velocity of the team. (Is this our first
time? Any extra-special technical areas of difficulty, like dealing with a text messaging gateway, or with
specialized web services?)
This involves making an initial estimate for each user story, taking advantage of the fact that each user
story is a semi-autonomous chunk of functionality that can be dealt with independently. Then, you
create a way of putting the estimates in context on the basis of the velocity of the team. (Is this our first
time? Any extra-special technical areas of difficulty, like dealing with a text messaging gateway, or with
specialized web services?)
Next, you are ready to prioritize the user stories. If they are indeed 3
×5 cards, this means unshuffling
the deck and putting them in order. The two most significant criteria for this should be: which ones does
the client think are the most essential, and which ones need to be tackled first because they involve some
kind of risk that needs to be mitigated at as early a stage as possible.
the client think are the most essential, and which ones need to be tackled first because they involve some
kind of risk that needs to be mitigated at as early a stage as possible.
This process dovetails into the next important planning task, which is allocating the stories to iterations.
You want to have several iterations, at least four to six for a medium site, even more for a large site,
following the Agile principle of ‘‘frequent releases.’’ One reason for this is so that the client, who should
be considered part of the development team, can give really effective feedback in time for the architecture
of the site not to be adversely affected by any ‘‘surprises’’ that may crop up: If implementation is straying
far from the client expectations of what the website is supposed to actually do, you want to find out
about that sooner rather than later. Another is so that work can be expressed as much as possible using
the semantics of the solution domain, rather than the problem domain — which means that people can
think much more clearly when something concrete is up and running, rather than being forced to work
in the abstract.
You want to have several iterations, at least four to six for a medium site, even more for a large site,
following the Agile principle of ‘‘frequent releases.’’ One reason for this is so that the client, who should
be considered part of the development team, can give really effective feedback in time for the architecture
of the site not to be adversely affected by any ‘‘surprises’’ that may crop up: If implementation is straying
far from the client expectations of what the website is supposed to actually do, you want to find out
about that sooner rather than later. Another is so that work can be expressed as much as possible using
the semantics of the solution domain, rather than the problem domain — which means that people can
think much more clearly when something concrete is up and running, rather than being forced to work
in the abstract.
5