Agile demand analysis of Agile development and project management

Problem background

Many activities in agile development involve full participation rather than personal involvement. Requirements analysis can also be a full participation of an activity. This reflects the agile development of "personal and interactive better than process and tool" values. Demand analysis is based on the understanding of requirements. Therefore, the full participation needs analysis helps to discover the problem that the team members understand the same requirement in time, which largely avoids the introduction of the defect. In addition, it helps to circumvent human risk. For example, a demand developer suddenly needs to take a leave of absence, and other developers can replace him immediately, because others are also involved in the analysis of their needs for development. In addition, full participation in demand analysis can also contribute to the ability of all members of the promotion. The problem, however, is that most developers and testers do not have the capacity or experience to be competent for demand analysis. This means that the needs-analysis activities of all the members involved require a person who plays the role of mentor to lead us to an effective demand analysis. This article takes the author to lead the team member to do the demand analysis the actual experience to share the Agile development team the demand analysis some concerns and the method.

Distinguish between "what" and "how"

Einstein once said that if he had one hours to save the world, he would spend 55 minutes defining the problem and spending only 5 minutes on the demand solution.

This sentence explains the importance of understanding the problem itself in solving the problem. and software development can be seen as a problem-solving process. The problem with software development is how to translate requirements into code. Demand reflects the question of "what" (What). One of the problems that developers tend to make when it comes to requirements analysis is the rush to think about the "how" problem, which is what the design solves.

And from the point of view of problem solving, the first thing to solve a problem is to find out what the "problem" is. This is like two people running, first to the end of the people have bonuses. And the end is clearly in the south, and a at a fast speed to the north, the result he still lost. Therefore, the project manager should guide the team members to focus on the requirements themselves in the requirements phase, rather than having to consider the design problem prematurely.

The tool of analyzing the rationality and integrality of demand--the background of demand

In agile development, User Story is often used to describe a requirement. A typical format for a User Story is as follows:

As XX (role), I hope ... (The system can achieve ... ) in order to ... (To achieve a business goal).

For example, here is a specific example of a User Story:

As a mobile phone user, I would like to be able to check my phone records to verify my consumption.

As you can see, User Story is a two-part description of requirements: requirements background and requirements statement. The requirements statement tells us what the system is going to do, and it reflects what the customer wants (want). And the requirements background tells us why the system does something, it reflects the customer's business needs (need). Combining the two aspects of a requirement helps to analyze the rationality of demand. For unreasonable needs should be rejected in time, otherwise not only wasted team resources, the system may also be brought to the stakeholders after the loss.

Legend has it that Newton has a size of two cats, in order to facilitate the access of the two cats, he opened the wall in the size of two holes. This story describes a need: to open a large hole in a small hole each (demand statement) to facilitate the size of two cat access (demand background).

In fact, a large hole can meet the actual needs. It can be seen that the requirement statement may not coincide with the requirement background, which is exactly what we need to analyze the rationality of demand.

Understanding the context of a requirement is critical to understanding and analyzing a requirement. Because the requirements background not only helps to understand the needs, answers our questions, but also helps to further analyze the requirements. For example, ads in mobile networks may require personalized content customization, that is, each user can see the content of the ads may be different, the content of these ads because of the audience's age, gender and other personal information. Obviously, the system needs to first query the user's personal information and then according to the end user's personal information to query the advertising content. In response to such a requirement, we may ask the question: if the user's personal information query fails, does the system need to return the ad content? This is not mentioned in the demand statement. Considering the requirements background can help us find the answer to this kind of demand integrity problem--Get customized ads based on personal information. The goal is to better position potential consumers, if not access to personal information, then return to the public to read ads.

Analyze the consistency of requirements

Even in the same iteration, the description may be contradictory or different. This creates a problem of consistency. Just some consistency problems are obvious, as described in the following text and the same, text description and related pictures, accessories inconsistent. In addition, the problem of consistency is more covert, which needs to be discovered through logical reasoning and comprehensive analysis.

Analyze requirements for compatibility

In iterative development, the current iteration often involves changes to the requirements that have been implemented in the previous iterations, and the requirement may have undergone several changes before the change. In this case, we specifically need to focus on compatibility between these changes. Because this requirement that was implemented in the previous iterations may already be running on the line, the requirements change should take into account the possible compatibility issues with the online system. Otherwise, a new iteration release version that is incompatible with the online version is likely to lead to significant losses for the customer.

Distinguishing knowledge layer from Operation layer

I have heard of such an example. In a hospital management information system, customers swear to say that a patient transferred to the department will only appear three times. As a result, the development team to the patient transferred to the function of the department can only turn three times. Later, after the system was online, a patient turned three times and needed to be transferred back to the original department. As a result, users start complaining about why they can only turn three times.

In fact, the features in the story above have introduced defects from the requirements phase. The reason is not what the client says. It is not the knowledge layer and the operation layer that distinguish the requirement in the requirement analysis. In the example above, allowing a patient to be transferred from one department to another is a question of the knowledge layer, and the specific number of cases transferred to the Department is the problem of the operating layer. Confusing the knowledge layer with the operation layer of these two levels will often produce problems. Therefore, the needs in the above example should be correctly understood as: The patient can be transferred from one department to another. The number of transfer departments is N times (n>0). That is to say, if the system can support patients to transfer to the Department, and a specific patient will be transferred to the number of departments, that is the software on-line after the specific operation of the problem. As a software developer we cannot and need not know this quantity.

The concrete implementation of distinguishing knowledge layer and operation layer can often adopt system parameterization (such as parameterization through configuration file). For example, to prevent a system from being maliciously logged in. Many systems may lock up the relevant login account after multiple logon failures. However, the specific number of login failures should be able to be dynamically adjusted during the operation of the system, because this is an operational layer problem.

It can be seen that the knowledge tier and the operating layer that differentiate the requirements make the delivery system more available, reduce unnecessary changes in the system, and save team resources.