This is the second article in the agile development user story series. (Topic directory)
The syntax model used in user stories in Agile development seems simple, but it contains profound ideas.
"As ......, Yes ......, In order )......" Different from the description of functional requirement entries, there are three ...... Jump roles, functions, and values onto the paper. However, improper use may look different from God.
Here is an example of the three parts.
Online Game ranking
"As a player, you can display rankings so that you can recognize your position on the server ."
This function can stimulate players' "fighting spirit" and encourage them to buy items. It is a good idea, but there are technical problems in implementation: there are too many players on the server, it is unrealistic to view rankings in real time. Another problem is that little shrimps are not very concerned about their rankings. Even if they are concerned, they will not purchase items to improve their rankings. There are only one batch (there are also hundreds of items) the top bosses will be really confused.
This story was later changed to "ranking again once a week, and only displays topxxx (similar to" ranking 20 thousand out "in csdn "). Therefore, if you write a story, it becomes:
"As a top paying player, you can display the ranking to gain recognition (to stimulate consumption) of your position on the server )."
Of course, there are also ways to stimulate consumption for the small shrimps. For example, if you drop a great item, you have to spend money to buy drilling materials and inlaid gems, that is to say, using health-care factors rather than incentive factors for them to consume is another story. I once experienced a gang war in one of my games. The grand game will compete for "connected hackers", while the small game will have "Treasure Hunt champion" and everyone will have points, as a result, all layers of people are competing to participate.
This story makes us understand:The word "user" is too general. If their "value" is very different, you need to write stories for them separately to attract them to use features and achieve values.
"As an administrator, You can query the permissions of all users to understand the permissions of all users ".
It is a common story that is tasteless and can't be written, because it seems that the function = value. ActuallyThe Administrator does not view all user permissions for no reason.Most of them have their own purposes: Some people report that they cannot access a certain file, some projects cannot add new users, and some people just quit, people with three outsourcing teams need to work as members in the project in the last three months ......
Knowing this is much better. When you click the "permission" tab, most of the "permissions for all users" will not appear (if you think about a company with 10000 people), but several sub-links will continue to appear: query personal permissions, project members, resigned personnel, and limited-time permissions (outsourced personnel management )......
Of course, this requires a lot of stories, but if a product with clear value and operation friendliness is exactly what we are pursuing, we are very likely to choose to develop the most valuable products, and then leave the previous "omnipotent", but nothing is doing well.
This story makes us understand:Functions are not equal to value. To understand the business purpose of user operation functions, do not throw out omnipotent functions at will.
Anti-disturbing function of anti-virus software
"As a user, you can select 'approve all similar operations' to allow or prohibit consecutive similar operations ."
This seems to be a good feature, but I used this feature when installing the software. Although I chose to "recognize all similar operations", the window still keeps jumping, later, I checked the pop-up information carefully. I had to perform a lot of "not similar" operations during software installation: Modify the registry, create the C directory, and copy the DLL to system32 ...... During the processing of this anti-virus software, the changes made to different locations in the Registry are considered as "different operations ".
To correct this story, we must start with the final customer value. For example, if software installation is the most common process that requires "recognizing all similar operations", you can write a story like this:
"As a user, you can select 'approve installation operation' when installing the software to complete normal installation with one click ." Of course, what is a "normal" operation requires additional instructions, but the overall customer value is more accurate.
This story makes us understand:"Customer Value" must be understood from the customer's perspective; otherwise, it is very likely to be biased.
Editor's note: this blog is a previous article, which is interspersed with a little modification because it complies with the content of this series.
Click to download the free agile development textbook: Martian agile development manual