Internet product Operations: How needs are agile designed

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

Agile development is not just about the need to develop and test the agile level, in fact, the requirements of the design level is also to be agile, so as to meet the follow-up development and testing, so that the real agile up, the previous introduction of agile development of the general model, this major share of the actual operation of the requirements of how the level of agile design.

In most cases, the processing of requirements can be divided into requirements analysis and requirements design, the former to transform the business requirements into product requirements, the latter to the product requirements into product design, or finished PRD. When we do the requirements analysis, we also receive a part of the demand, button business priority to do analysis, each analysis must be linked to the needs of the analysis, or the first analysis of higher priority, after analysis of lower priority, this process will analyze the task is divided, so it is also closer to the agile model , put aside, this is mainly about how the requirements design part of the development and testing in the combination.

Before I really start talking about agile design, I think it's important to think about whether all the requirements are suitable for agile design. Why there is such a doubt, is agile development is actually more flexible, and not blindly for agile and agile, it can be divided into product agile and project Agile Two ways, in my understanding, Product agility is the real agile design, agile development, agile testing combined, from the product level, all tasks are managed in an agile manner, while project agility is based on the design of the waterfall, development and testing is agile, so there is a difference between the two, Why do some needs not be designed in a agile way?

The agile model in general is to split the whole into multiple individuals, and then individually to complete the individual to achieve these individual synthesis is the overall effect, so here is a problem exists, the overall requirements of the product is suitable for splitting? The personal experience of the operation is summarized as follows:

1, each function is more independent and suitable for agile. A product has 10 function points, each function point interdependence is not strong, loose coupling, can each function point separate extraction to do the design;

2, the function of its own logic to follow some kind of operation process of agile. The realization of the function is to follow a more fixed process step by step down, so that each step can be separated separately;

3, the product on-line after the maintenance of the version of Agile. After the line, for some bugs, problems, small demand for the sewing, are suitable for the agile way to design;

4, after the new demand for agile. The new requirements on line are generally designed for a functional module, relatively independent, so it is also suitable for agile design;

Conversely, if the above conditions are not met, in particular, a high degree of coupling demand, personal advice or go waterfall mode, the overall needs of the whole need to comb clear after the overall requirements of the design, so as to avoid the design process behind to change the previous design results of the problem, reduce part of the requirements change, Although Agile says a great advantage is that it can better adapt to changes in demand, this requirement change refers to from the business level, not from the product designers or product managers themselves in the way the work of the resulting. Of course, some people are all go agile, such words to its product planning ability requirements, the overall thinking logic to be very clear to avoid mistakes, here is only personal advice, for reference only.

After you have finished with agile design, let's talk about how the output of agile design is maintained. Usually we call a function point for a case or a story, and in the agile called Backlog product entry, in fact, just changed a name, the essence has not changed. I also said that in learning the strengths of others, it is important to understand and adapt, rather than copy.

Product Backlog is the core of agile and the origin of the agile process of the whole product. Fundamentally, it is a list of requirements, or stories, or features, sorted according to the level of importance. It contains what the user or the business party wants, and is described in terms that are understandable to the user or business side. Usually there are several parts:

Ordinal ID: A uniform identifier, which is a self growing number, used to uniquely mark each backlog, mainly for marking purposes, and for labeling each backlog in the PRD as a description of requirements;

Name: A short, descriptive backlog title, such as "View your own transaction details". It must have a clear meaning, so that developers, testers can generally understand what we are talking about, in fact, also facilitate the product manager to do their own checklist inspection, can be separated from other backlog areas, it is generally composed of 2 to 10 words; split backlog is required, It is generally required that each backlog can be completed within a specified single iteration cycle;

Importance importance: The Product Manager selects a number indicating how important this backlog is, typically an integer value between 1 and 10, and the higher the score, the more important it is. is actually priority, but some people understand the priority is 1 the highest priority, so here with the importance of the expression. Priority evaluation mainly refers to two dimensions, one is business value, the other is urgent, others can be temporarily not considered;

Workload estimates initial estimate: The team's initial workload estimates indicate the minimum amount of work required to complete the backlog is 0.5 people/day. In order to maximize the accuracy of the estimates, the current individual use is the entire team to write an estimate of work, remove one of the highest, remove one of the lowest, the rest do the average, hehe, and then arrange their respective explain why, ultimately, within the team to reach a consensus;

Demo to Demo: Roughly describes how this backlog should be demonstrated, essentially a simple test specification. Generally "do it first, then do it, you should get ... The result ", agile for each backlog requirements is can be demonstrated alone on-line;

NOTES: Relevant information, explanations and references to other materials, etc., are generally very short;

Backlog are usually stored in a shared Excel document so that team members can view edits 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 the document, figure out something, or modify the estimate.

Another problem here is how to keep the product backlog at the business level. For example, if the product manager has a technology-related background, he might add a backlog: "Add an index to the events table." The real goal might be "to increase the response speed of searching for event forms in the background system." It may be found that the index is not a bottleneck that slows down the form, perhaps because it is completely irrelevant to the index.

So it's up to the development team to figure out how to solve the problem, and the product manager needs to focus on business goals. This technology-oriented backlog can always ask "why" until you find the intrinsic purpose, and then rewrite the backlog for real purposes ("increase the response speed of searching and generating forms in the background system"). The first technical description will only exist as an annotation ("adding an index to an event table may solve the problem").

Maintaining the backlog table is a process of splitting the product requirements, when the split is complete and the implementation is designed according to the iteration plan, the project agile is then split after all requirements have been designed, and the main purpose is to split the development task and the test task.

Agile, by contrast, is a more novel model, at present in the Internet industry used more, each company in the use of the actual situation may be not the same, in fact, the best for their own, as long as you can improve the efficiency of the product iteration release, you can, first use, and then in the process of using slowly optimization , to play the greatest utility of agility.