Relationship between user story task decomposition and hierarchical development

What is a user story? User stories appear in Agile development for convenience of communicating with users. He describes the requirement from the user's perspective in words that the user can understand.

The task is to complete a user story. The system developers and designers break down the user story into several tasks and assign these tasks to some people so that they can complete these tasks, then the entire user story is realized. Of course, this involves some synchronization and collaboration issues.

The hierarchical development of the system is familiar to everyone. When I get a project of a business system, I will first use the domain-driven development model, and then use the DDD hierarchy, using layering can greatly reduce the complexity of the system.

What is the relationship between task breakdown and hierarchical development of user stories?

First, let's take a look at what problems we usually encounter during system layering.

Traditional development is basically divided by functional blocks. For example, A is responsible for the user management module, and B is responsible for the log management module. C is responsible for the major project management module. In this case, a problem occurs. Even when designing the system, the UI Layer, domain logic layer, infrastructure layer, data access layer, and application service layer should be strictly separated, however, in actual operations, some people do not want to be too troublesome in order to catch up with the progress. Some people may not be able to reach the level of water, and they did not follow the established hierarchy. The most obvious mistake is that there are too many domain logic on the UI Layer.CodeAnd a lot of If judgments.

In addition, this does not take full advantage of the expertise of each individual. Everyone is doing all the knowledge points covered, but it is only a small part of the work. It is not easy for members to communicate with each other. They will discuss the issue together unless there is interaction between modules.

Second, let's take a look at the task breakdown of user stories.

For example, there is a user story. As a super administrator, You Can batch delete logs within the specified log range so that when the system is used for a long time, you can clear logs that are of little significance for a long time. Of course, this user story is relatively simple.

We may break down tasks into the following tasks.

Task 1: In the data access layer and logdal class, add and delete logs from the database in batches Based on the date segment. Deletelogs (datetime pstartdate, datetime penddate ).

Task 2: add the UI for batch log deletion. You must enter the start time and End Time, and click OK or cancel.

Task 3: add the batch deletion function to the system menu and hook it with user permissions.

In this way, we can allocate Task 1 to at least one member and Task 2 and Task 3 to another member. Basically, when a task is assigned, each task is basically not implemented across layers. A single task is implemented on a single layer, and each task is implemented by different people. Even if these tasks are implemented by one person, they must be implemented one by one. This also avoids system quality problems caused by "Laziness" or level confusion due to limited levels.

 

In the agile development scrum process, the estimation of user stories and task breakdown are generally completed together with the team members. With the help of senior developers, all user stories may be configured according to the system hierarchy. This is a good guarantee for the system.