In fact, agile development not only requires agility at the development level and testing level, but also requires agility at the requirement design level, so as to cooperate with subsequent development and testing to make it truly agile.
We can understand the agile design of requirements by analyzing the agile design at the requirement level in the actual operation process.
In most cases, the processing process of requirements can be divided into two parts: requirements analysis and requirements design. The former is to convert business requirements into product requirements, and the latter is to convert product requirements into product design, that is, the PRD of the finished product.
When doing demand analysis, we also analyze the business priority after receiving a part of the demand. Each analysis must analyze the interrelated requirements together, or analyze the higher priority first, and then analyze it. Lower priority, this process divides the tasks of analysis.
Therefore, it is also closer to the agile model. I will not talk about it here. It mainly talks about how the requirement design part is combined with the subsequent development and testing.
Before really starting to talk about agile design, I think it is necessary to think about whether all requirements are suitable for agile design? Why there is such a question is that agile development is actually more flexible, not just for agile and agile, it can also be divided into two ways: product agility and project agility.
In my understanding, product agility is a real combination of agile design, agile development, and agile testing. From the product level, all tasks are managed in an agile way; while project agility uses requirements design Following the waterfall model, development and testing are agile, so there are still some differences between the two.
Some requirements are not suitable for designing in an agile way
In general, the agile model is to split the whole into multiple individuals, and then complete each individual individually to achieve the effect of the whole after these individuals are combined, so there is a problem here, whether the overall requirements of the product are suitable for splitting. ? Personal experience in operation is summarized as follows:
• The more independent functions are suitable for agile. A product has ten function points. If the interdependence between each function point is not strong and the coupling is loose, each function point can be extracted separately for design.
• The logic of the function itself follows a certain operational process suitable for agile. The realization of the function is to go down step by step according to a relatively fixed process, so that each step can be separated separately.
• Version maintenance after product launch is suitable for agile. After the launch, some bugs, problems, and small needs can be patched up in an agile way.
• New requirements after going live are suitable for agile. The new online requirements are generally designed for a certain functional module, which is relatively independent, so it is also suitable for agile design.
On the contrary, if the above conditions cannot be met, especially the requirements of high coupling degree, my personal suggestion is to adopt the waterfall mode, and make the overall requirements design after sorting out the overall requirements, so as to avoid the need for the subsequent design process. The problem of changing the previous design results, reducing part of the requirement changes.
Although a great advantage of agile is that it can better adapt to changes in demand, this change in demand refers to the business level, not the way product designers or product managers work.
Of course, there must be some people who are all agile. In this case, they have higher requirements for their product planning capabilities, and the overall thinking logic must be very clear to avoid mistakes. This is just a personal suggestion for reference only.
How to maintain the output of agile design
Usually, we call a function point a CASE or a Story, but it is called a backlog product entry in agile. In fact, it just changed the name, and the essence has not changed.
I also said before that when learning the strengths of others, the important thing is to understand and adapt, not copy. The product backlog is the core of agile and the origin of the entire product agile process. Basically, it's a list of requirements, or stories, or features, etc., ordered by level of importance.
It contains what users or business parties want, and describes them in terms that users or business parties can understand. Usually there are the following parts:
Serial ID
The uniform identifier is just a self-increasing number, which is used to uniquely identify each backlog, mainly for marking purposes, and to mark the requirement design description corresponding to each backlog in the PRD;
name
Short, descriptive backlog titles like "View your own transaction details". It must have a clear meaning, so that developers and testers can roughly understand what we are talking about. In fact, it is also convenient for product managers to check the checklist themselves, which can be distinguished from other backlogs. It generally consists of 2 to 10 words; it is required to split the backlog, and it is generally required that each backlog can be completed in a specified single iteration cycle;
Importance Importance
The product manager evaluates a numerical value indicating how important the backlog is, generally an integer value between 1 and 10, the higher the score, the more important it is. In fact, it is the priority, but some people understand that the priority is 1 the highest priority, so it is expressed in importance here. The evaluation of priority mainly refers to two dimensions, one is business value, the other is urgency, and the others can be ignored for the time being;
Workload estimateInitial estimate
Preliminary workload estimate of the team, indicating the workload required to complete the backlog. The minimum unit is 0.5 people/day. In order to improve the accuracy of the estimation as much as possible, at present, everyone in the entire team writes an estimated workload, removes the highest one, removes the lowest one, and averages the rest, hehe. Then arrange to explain why, and finally reach an agreement within the team;
Demonstration How to demo
It roughly describes how this backlog should be demonstrated, which is essentially a simple test specification. It is generally "do this first, then do that, and you should get the result of...". Agile's requirements for each backlog are that it can be demonstrated and can be launched separately;
Notes Notes
Relevant information, explanations, references to other materials, etc., are generally very brief; the backlog is usually stored in a shared Excel document so that team members can view and edit it at any time. Generally, this document is maintained by the product manager, but it does not exclude other team members. Developers and testers often have to open this document to clarify something, or to revise an estimate.
Another question arises here, that is, how to make the product backlog stay at the business level?
For example, if a product manager has a technical background, he might add a backlog like this: "Add an index to the Events table". The real purpose may be "to improve the responsiveness of the search event form in the background system". Later, it may be found that the index is not the bottleneck that slows down the form, and the reason may be completely unrelated to the index.
So it's the development team who figure out how to solve the problem, and the product manager just needs to focus on the business goals. This technology-oriented backlog can keep asking "why" until the inner purpose is discovered.
Then rewrite the backlog with the real purpose ("improving the responsiveness of searching and generating forms in the backend system"). The original technical description will only exist as an annotation ("Adding an index to the event table may solve this problem").
Maintaining the backlog table is a process of splitting product requirements. After the splitting is completed, the specific implementation is designed according to the iteration plan. The agile project mentioned above is splitting after all requirements have been designed. At this time The main purpose is to separate development tasks and test tasks.
Relatively speaking, agile is still a relatively new model. Currently, it is widely used in the Internet industry. The actual situation of each company may be different when it is used. In fact, it does not matter. As long as you can improve the efficiency of product iterative release, you can use it first, and then slowly optimize it in the process of using it to maximize the effectiveness of agility.