Thoughts on "User stories and Agile Methods" (v.)

Thoughts on "User stories and Agile Methods" (v.)

Today, I read the third part of the book-the topics that are often discussed, the user stories are not what, the advantages of user stories and bad signs.

First, the user story is not a guide to the software Requirements specification, which emphasizes the "system should ...", and for requirements specification guidelines, the cost of each requirement is not visible until the requirement is written. Typically, one or several analysts spend two or three months (usually longer) writing lengthy requirements documents. The document is then delivered to the programmer. The programmer then tells the analyst (the message will be relayed to the user) that it will take 24 months to complete the project, rather than the 6 months the analyst wants. In this case, the analyst wasted a lot of time writing a three-fourths-part document that the team did not have time to develop, and repeated discussions between developers, analysts, and customers about the features that needed to be developed within a limited amount of time would waste more time. Every story starts with an estimate. The customer knows the rate of the team and knows the story points of each story. After writing enough stories to fill all the iterations, she knew her task was done.

Want to the traditional requirements Specification guide, user stories still have a lot of advantages, first, promote oral communication, we discuss the most perfect solution, crowds well; second, the user story does not have the complex domain terminology, these things can make the developer at a loss, So user stories are easier to understand than use cases and scenes, and thirdly, the size of the user story is suitable for planning, the user story can be divided according to the actual situation and needs, so the story size can be controlled, it can be easy for users to do release planning and programming and testing, the user story is suitable for iterative development, I don't need to write out all the user stories before I start coding. I can write some of the stories to encode and test and repeat the process as needed. When I write a story, I can write it according to the appropriate granularity. It is because it is easy to iterate over the story itself, so the user story is well suited for iterative development; The user story encourages delay in detail and can quickly give everyone a holistic view of the system to be developed; The user story supports the development of the improvise and encourages the participatory design, the user story is fascinating, It can inspire the user's enthusiasm, make the relationship between the developer and the user become intimate and active, this virtuous circle makes all development design person and software user to benefit a lot.

Although the user story has a lot of advantages over traditional documents, we should also look at its shortcomings correctly. First, stories are dependent on each other, and the user stories are likely to be detrimental to iterations as they lead to a high degree of correlation due to design biases, and second, because developers have implemented unplanned functions in iterations, making actual functions beyond their actual needs; three, too much detail, should not spend too much time writing stories but discussing stories; , considering the details of the user interface too early, we should try to avoid writing stories about the page, the stories are divided frequently and the customer is difficult to prioritize the story or the customer is unwilling to write the story or prioritize the story.

User stories are aids, and what we need more is an agile approach that leads the team to the right and concise direction by thinking about it.

　　

　　

Thoughts on "User stories and Agile Methods" (v.)