User stories and Agile methods read Note 05

13th. Advantages of User Stories

　　From the previous chapter we learned that there are a variety of ways to handle demand, but why should we choose a user story? Because it brings multiple benefits:

① User Stories emphasize verbal communication: from ancient times, oral expression is very important. and the oral presentation is more straightforward than the ambiguity of written writing, as is the requirement document.

② Everyone can understand user stories: the language used in user stories is easier to understand, concise, and more user-friendly than the technical jargon of some of the more conventional software requirements.

The size of the ③ user story is suitable for planning: other types of requirements analysis are too relevant, and relatively general, size can not be easily implemented as a suitable requirement.

④ user stories are suitable for iterative development: Due to the nature of the user story, developers can implement the development according to their current needs.

⑤ User Stories encourage delay in detail: User stories allow us to set a goal level story, then actually develop it, then detail it, speeding up the whole team's progress.

⑥ User Stories support an adaptable development: because of the user's controllability, the requirements are often changed. In the past from top to bottom demand analysis method, this is simply a nightmare, it will let our pre-determined all the requirements of all obsolete. User stories are a good solution to this.

⑦ User Stories encourage participatory design: the user story itself is not a professional term, unlike other requirements methods, and users can fully understand that they are more willing to participate in designing the software they need. In this process, we will be able to better understand the needs of users, to make better quality analysis.

⑧ User Stories Dissemination tacit knowledge: tacit knowledge refers to the existing properties of the target system, the user is accustomed to work, think we should know, but we are not familiar with the process of knowledge. Because the user can participate in the design, this will help us to tap the potential needs of users, shorten our development cycle.

Nonetheless, the user story still has some shortcomings: in large projects, the number of user stories grows, resulting in relationships that can be complex and difficult to control (solutions: increase users, reduce the number of details); If traceability is required for the development process, additional documentation is unavoidable (each iteration produces a story document, It writes the work of the round iteration, keeps the document updated), does not fit the structure of a large multi-team (or the need for relevant communication records).

14th. List of undesirable symptoms of user stories

　　The user story is good, but it is not easy to use, if used poorly, there will be a variety of problems. Here are some common bad signs (symptoms, solutions): Stories are too small (often need to adjust estimates, merge related stories), stories are interdependent (it is difficult to do iterative planning, if the story is small to merge or to see if the story is properly divided), gold (to achieve the function beyond the planning needs, Developers waste extra effort to make sure that each iteration of the plan minimizes redundancy for each job, too much detail (wasting too much time writing stories rather than gathering stories, using small cards to record user stories), premature consideration of user interface details (including interface details in the written story, avoidance or modification to specific feature descriptions), Think too far (for a variety of reasons the story is difficult to summarize, so that developers learn to collect user stories), the story is too frequent (multiple division, scanning the rest of the story to find the real need to divide the story), the customer is difficult to prioritize the story (the story is too big or the user story No business value, change the story, Customer efforts to rewrite), customers are reluctant to write stories, and are reluctant to prioritize stories (unwilling to take responsibility and discuss negotiations privately with the user). To solve these problems, user stories can be more robust and development will be smoother.

15th Chapter scrum and user stories

　　Scrum is also an iterative and incremental software process. Iterative refers to continuous improvement, in the iteration, the software can be gradually improved; promotion refers to the team to develop and release software according to the function point, which can make the project steady progress, reduce the chance of rework. Projects that implement the scrum process often iterate over a period of 30 days, a process known as sprint. ScrumMaster is the equivalent of a traditional project manager, but more like a leader and organizer, he has a closer relationship with the developer than the manager. A general Scrum team consists of 4~7 developers. The product backlog is a list of functional requirements to be developed, and the entries are not yet implemented or planned. The Sprint backlog is a list of tasks that a team commits to complete in the current sprint. The product owner in scrum is the equivalent of a client in extreme programming, and he is responsible for prioritizing the backlog. Each time the sprint starts, the soft pair selects the task to be performed in the list that has not been implemented or planned. In a daily briefing, each team member needs a self-contained three provinces: Completed, to be completed, and a problem. The actual product function increment should be in each cycle, so that the project can be healthy and orderly forward. At the end of the final sprint, Ruan will demonstrate the completed function at the review meeting. This is a scrum-related content and process.

User stories and Agile methods read Note 05