Agile development One Thousand and One question series 34: how to identify project requirements (requirement development steps )?

This is the first article in The One Thousand and One Q & A series of agile development. (Here, I am going to ask, one, two, the third, the general question directory) is also the tenth article in the agile development user story series (topic directory ). To what extent can I develop a clear problem? Do I have to figure out the requirements before development? How can we clarify the requirements? Note that the following analysis is as follows: Context of contract-based project development. The development process of products and Internet needs will be discussed later. Analysis and steps the following text is excerpted from group chat records without further modification. Project Context

If there are only two types of projects, there are two types of projects as a whole: one is to build a project, the other party wants something, and the other party pays the money for delivery; the other is to make a product with unknown demand, even customers are unknown and need to mine on their own. The rest are centered around two types, and the "product-project" is a customized product.

Step 1: Scope of requirements

First, you must realize the question: "What is the highest purpose of the demand ?" There are many requirements, but for project-based development, the most important thing is "requirement progress quality cost. That is to say, project profit = Contract-cost. If the cost is not guaranteed, the rest will not be discussed.

Therefore, it is important to keep the project profitable, that is, the contract amount is greater than the cost.

At this time, the scope of the requirement is more important than the details of the requirement. That is to say, you cannot start the project or start the project blindly before figuring out the scope of the requirement. However, it is acceptable, or at least not risky, to clarify the details of the requirement.

So if I am dealing with such a project, the first thing is to outline the outline of the demand, that is, he asked me to do nothing. The contract cannot be signed.

The specific method is the "Business Data + business operations" method I wrote in my blog. This is a concept in FPA.
For more information, see http://blog.csdn.net/column/details/agile.html? Page = 6 of 2 and later articles.
If the method is correct, it takes about one day to confirm that the work of ten people is not a problem (the customer needs to be clear-headed ).

With the demand profile, you can proceed to the next step. But what is next? This is a problem.

Step 2: Priority sorting

The requirements must be as follows: 1. A lot of unclear parts; 2. A lot of things that can't be done at the end; 3. Things that have finally been changed by the customer; 4. A lot of things that the customer later proposed ......

Therefore, it is basically unrealistic to try to find out the requirements for development. In the past, when "customers" were limited to military, aviation, aerospace, meteorology, and banking (banking services in the past were very simple and clear )...... But it is becoming increasingly unrealistic.

So the second step is better: find out how much the demand will be delivered and get the money back (note that we are discussing the project rather than the product)
The best method in step 2 is priority sorting. But pay attention to the method, because customers never say that some of their needs can be abandoned, but in fact they can.

There are several important questions:

1. Do not ask "what do you think is dispensable?" (you should ask: "What do you think is essential ")

2. Don't ask "what do you think is the last thing you do" (you should ask "what do you think is the first thing you should do first ")

...... In short, it is not difficult to grasp.

However, another difficulty is that Party B needs someone to view the project requirements "above the customer", so that the customer can understand the priority first. It seems difficult, but not necessarily.

Because customers seem to understand business very well, but they are also limited to their own business scope. Party B is different. Party B generally faces multiple customers and needs to understand some methodological content and study the products of multiple competitors. In fact, Party B has a much broader vision. Therefore, it is not a real problem to determine the priority of customers.

With priority, you can do the following:

1. Ensure that delivery and receipt will not be affected too much even if the deadline is delayed or incomplete (close to 100% may occur ).

2. Know what to do first, check with the customer, and proceed further.

Now we have reached the third step of requirement development. Let's review it first:

Step 1: understand the demand scope; Step 2: Sort priorities

Step 3: Development Requirements

It is recognized that the good method is the original method, but there are two types of original method, one is suitable for waterfall, one is suitable for agile (or iterative)

Discard prototype: at the very beginning, we made something to communicate with the customer to confirm the needs, and then develop according to the needs of the communication.

The discarded prototype is basically no longer needed after the requirement is confirmed. Therefore, you can choose a variety of quick tools, such as Excel and graphics software.

Evolutionary prototype: The prototype is not discarded, but is used as a product. It accepts the direct review from the customer (it should be said that the "use and feedback" is better) and then is modified on this basis.

In fact, the "runable Software" in the entire agile development is actually an evolutionary prototype.

It is difficult to directly compare the two prototype methods.

Abandoned prototypes are often used in the early stages of software development, because at that time most waterfall models were used, and such projects as military and aerospace did not need to be changed once determined; and, there is also a lack of a realistic environment to "gradually verify the demand". For example, the Apollo moon landing is only 10 times in total, and the needs and solutions must be clarified in advance.

The current Internet development is just the opposite, and the Evolution prototype is more suitable. First, the Internet industry is extremely difficult to predict the future (look at Nokia, Ms will know), followed by "customers" or "users" are mostly scattered, the collection of demand is very limited. Therefore, a product that is directly inspected in the market is a better method.

There are many ways to directly accept feedback from work products. If you have used appstore or androidstore, you will find that it takes only a few seconds to report a problem. Our own product (the Martian, a management system directly hosted on the Network) has a background record file to track the features used by the customer to understand the customer's behavior, for further improvement.