user story2

But in the process of using Story, many problems are also exposed. First, the practice of completely abandoning the requirements analysis record (Use Case or IPO method) makes the knowledge of the product or project team unable to be effectively passed on. When I participate in the module architecture optimization of multiple project teams, I can only understand the module requirements from the code, because there is no Other records; Second, the use of Story is in danger of being amplified. Now there are not only project-level stories, but also version-level stories, and even the concept of solution-level stories has recently been proposed. If the scope of use of Story is so expanded, the problem of knowledge inheritance will also expand, and no one pays attention to the Use Case that actually conducts demand analysis and recording. This is a big question.



I think the best way is to implement the company's requirements for the new architecture 2.0, use System Feature, System Requirements, Allocated Requirements to represent system features, system requirements and module allocation requirements, and use Use Case to describe SR/AR. It is only necessary to use the concept of Story when formulating the iterative development plan at the project team level or individual, and this Story is only a decomposition of AR; when formulating the iteration plan at the version level, it is enough to use the concept of SF/SR.



Many times we are playing with nouns without really understanding the meaning of the nouns.



The following is the dependency definition of the Use Case of a project team's module requirements, and the definition of the three-round iterative delivery plan Story. Generally, stories are divided after the module design is completed, because only after the architecture design is completed, we can know exactly what a Story has. How much work.