Analysis of user requirements in XP: Overview of planning game and user story

The Demand Analysis in extreme programming is completed through the planning game. Although we use
At the beginning of the game, we discussed the specific process of the extreme project. However, in fact, some stages in the planning game almost ran through the project.
Development always. (The word "game" can help you relax your mind .)

Planning is something that is easy to say and difficult to do. When planning, the programmer considers how to program faster.
The project manager considers how long the programmer can finish these tasks, and the customer considers how many things can be obtained after the time ...... Start
Of course, there is nothing wrong with all these questions, but the plan is done step by step like anything.

A planning game is divided into three phases: probe, plan, and adjustment.

Test phase: the customer and the developer divide the requirements into many small and predictable parts.
Planning phase: the customer and the developer work out the release plan.
Adjustment phase: customers and developers should adjust the original plan or formulate new plans in time according to the actual situation during the development process.
Stroke.

Like all chess and card games, XP's planning game has its cards (ChEss), goals, players, and game rules.

Chess: the chess in planning game is the user story. Each user story is a small user requirement.
It is often a few words or one or two sentences. Every user story is written on a card, which lists its commercial value and developed
. Because the commercial value and development cost of a user story may be closely related to the trade-off between another user story, these cards
Sometimes it looks complicated.

Goal: If we compare a product to a box, the goal of the game is to enable the story card in the box at the end of the game
The sum of business values is as greatest as possible.

PLAYERS: customers and developers.

Game rules:

Story Writing: a new user requirement can be written into a story at any time in the game. In addition to its business, each story
Besides value (priority in the customer's eyes), there is enough content for developers to estimate development costs.

Story estimation: developers estimate the Ideal Development Week for each story. If it is more than 2 weeks, the story should be decomposed (this has been
.). If it is estimated that the development time is short (for example, half an hour), consider
And merge it with another story.

Release plan: together with developers, the customer decides which story is to be completed and which is the next release.
What should be done during the next release, when to deliver the product, and what story should be included in the product. There are two starting points for preparing a release plan:
Based on story and time.

Based on story: the customer classifies some story cards as the content to be completed in the next release plan. Each time a card is placed, the customer describes the story.
The developer estimates the development time and release date of this story.

Time-based: the customer specifies a delivery date or release date. Developers can estimate how many tasks can be completed from now to that date.
Less work (How many ideal work weeks), and then the customer selects which story to complete, the total development time of all selected story should be
This is less than the ideal total number of working weeks estimated by developers.
Business Value and development risk first: arrange the story with high commercial value as much as possible in the early plan (Business Value first );
The story of development risks is arranged in the early Plan (development risk is preferred ). After the developers arrange the story, they should be able to commit
Within a week, give the customer a workable but rough system.

Correction estimation: for example, a developer previously estimated that 20 story records can be completed before the delivery date, but during the development process
Computing and development speed and re-evaluation, found that only 15 story can be completed. The customer selects 5 from the original 20 story and places them to the next one.
Development in progress. (Sometimes, the customer may delay the delivery date to get all the story .)

Correction of Business Value: customers can change the business value (priority) of each story at any time ). Accordingly, developers can follow these changes
Adjust the sequence of story development.

Introduce a new story: the customer can add a new story at any time. Developers must estimate development costs and risks. If the customer requires
After this story is completed in this development, developers should work with the customer to re-estimate the story based on the commercial value and development risk priority principle.
Related story.

Split a story: the customer Splits a large or complex story into two or more small story. After each decomposition, the customer must estimate
The commercial value of story. developers need to estimate the development cost. It is usually because the story cannot be broken down in the short term.
Completed by a few people.

Spike: the customer can allow developers to concentrate resources and prove the feasibility of an idea in a short period of time (maybe two or three days) or
Deal with an emergency (such as data recovery ). If this requirement is complex (not a small patch), you should write it
A story. This story should also be evaluated based on the principles of business value and development risk priority. Spike usually affects development.
Speed.

Re-estimate: after a story is developed, the developer re-estimates the remaining story, and may find that the previous overestimates are based on their own
Development capability, it may also be found that the development time can be shortened.

 

 

This article from: http://cnc.chinaitpower.net/A200508/2005-08-07/183732.html