User stories and Agile development Methods Note 06

The user story gets so many people's affirmation, is because its own superiority has many: 1, the user story emphasizes the verbal communication, because the traditional through each kind of document carries on the expression, each person has the different understanding to the literal meaning, therefore may in the reading document process because the understanding different to the project completion influence; 2, Everyone can understand the user story, and the user story can enhance people's memory of various events; 3, the size of the user story is suitable for publishing planning and programming and testing; 4, the user story is suitable for iterative development, the project process can write a part of the story and then code and test 5, user stories to encourage delay in detail ; 6, user stories support the development of the improvise, because the user stories focus on verbal communication, and it is easy to write or rewrite different granularity of the details; 7. User Stories encourage participatory design, because stories are easy to understand, inspire users to become participants in software design, and 8. User stories disseminate tacit knowledge.

There are two sides to anything, so the user story has its shortcomings: 1, in large projects, the relationship between stories will be very complex, so try to ensure that user stories not too detailed, until the development of these stories only began to refine; 2. If the development process requires traceability of requirements, additional documentation is required. So it takes some extra time to move in or out of the story to keep the document updated; 3. Although the story can promote the base class of tacit knowledge within the team, it does not apply to the structure of a large multi-team, then it is necessary to record some communication information, in order to ensure the full sharing of information within the team.

Although user stories are simpler than other requirements, they are not a good grasp of its standards. So there are some bad signs when using a user story: 1, symptoms: often need to adjust the estimate, performance: The story is too small; 2, symptoms: It is difficult to do iterative planning, performance: Story interdependence; 3, symptoms: The developer son, the iterative process to achieve the unplanned function, or simply by their own feelings to achieve the story, or implementation of the function beyond the actual needs, performance: Developers do not need to implement the function, 4, symptoms: Spend too much time to discuss details; 5, Symptoms: Premature Consideration of user interface details; 6. Symptoms: The story is divided too frequently; 7. Symptoms: It is difficult to prioritize the story; 8, symptoms: Not willing to write user stories, Nor do I want to prioritize the story.

User stories will also encounter some problems in the application process:1, to deal with non-functional requirements: Non-functional requirements are often not properly expressed in the form of stories. The types of non-functional requirements are: performance, accuracy, portability, reusability, maintainability, interoperability, usability, ease of use, security, capacity. Most non-functional requirements are constraints, so non-functional requirements can be present in the project as a constraint card. 2, paper quality or software? Paper cards and software have their own advantages, paper cards are more convenient to bring into various meetings, but the size of the card is not good for writing test cases, but can give the story to describe a natural limit of text, and sorting is simpler. Software is not used by teams in the same location, and customers prefer software rather than paper cards. Therefore, in the specific use of the team according to the specific choice of paper or software to record the story. 3, user stories and user interface: for highly iterative agile processes, the traditional user interface design method relies heavily on the previous design, so there may be significant changes in the user interface implementation later. As a result, the design for agile processes is generated: 1, User Role modeling, 2, capture high-level user stories, 3, prioritize stories, 4, refine high-priority and medium-priority stories, 5, organize groups of stories, 6, build a written prototype, 7, refine the prototype, 8, start programming. 3 , whether or not to keep the story: Preserving the story is more valuable for subsequent maintenance of the product and the need for some documentation after the project is over.

In a word, the advantages of user stories make them stand out in many demand methods, and there are shortcomings, which require some extra cost to compensate; User stories are easy to understand, but they are not easy to use, so be aware of the various symptoms that may occur during the iteration and then prescribe the right remedy And there is a user story that may conflict with some of the habits of the traditional development process, and then the need for people to make appropriate changes based on their characteristics.

User stories and Agile development Methods Note 06