We have described the complete process of an iterative development in detail earlier. First, the preliminary analysis of the project plan - workload evaluation and priority evaluation, then the formulation of an iterative project plan, and finally the implementation of the project according to the project plan. Every day, use the Burn-Down Table to monitor the progress of the project, keep track of the deviation of the project progress (whether it is behind or ahead of schedule), and then formulate corresponding response plans to make adjustments until the final project is over, everything seems to be going relatively smoothly. But the real situation is often not like this, and one of the most important factors is overlooked here, that is, demand changes.
If there are no requirements changes, we don't need to use iterative development, the waterfall model is enough. As I talked about in Chapter 1, there is a risk in our software development, and that risk is changing requirements. Changes in demand are everywhere, just like the vast universe we humans face, there must be safeguards against possible risks. What are the safeguards against changes in requirements? That is to use iterative development. So, how does iterative development protect against changes in requirements from users? We use a melodrama to explain in detail.
Mr. A is a project manager who is about to start a new software development project. He first organized demand personnel to conduct in-depth demand research with customers, conducted detailed demand analysis, and finally formulated a demand specification, which was signed and confirmed with the customer. At the same time, he organized the designers, discussed with the requirements personnel, and carried out task decomposition, workload assessment, and priority assessment for all requirements. Then discuss with company leaders and negotiate with client leaders to determine the personnel, funds and time required for the project. Finally, an iterative project plan is developed.
After everything is in place, the project begins to enter the execution phase. Mr. A made a Burn-Down Table to monitor the progress of the project and started the first iteration period. Everything went relatively smoothly, the project successfully completed all the tasks of the first iteration period, and successfully submitted the first deliverable. Just when everyone thought that the project would go on like this all along and were smiling, something happened - when the client saw the first deliverable, he was not satisfied with some features, suggested changes to features of one kind or another, and even proposed New functionality - A requirement change has occurred.
When a customer proposes a change to the requirement, our first reaction is to record it and then go back and do it, but many experiences have proven that this is not right. The fundamental reason for the frequent changes of customers is to modify the customer's change requirements without analysis. As we mentioned earlier, an important feature of customers' requirements is that when the software is not really designed, customers often do not know their real needs. Therefore, when he sees the revised content after the last proposed change again, he is likely to be unsatisfied, which means that he must continue to make changes until he is satisfied. In this way, repeated revisions are inevitable.
When a customer proposes a change in demand, we should first understand why the customer proposes such a demand. At this time, the requirements analyst should stand from the user's point of view and the business point of view to understand such requirements and understand their motivations. Maybe the customer needs to check some relevant information when doing this operation, maybe this data has a logical relationship with that data, or even the reason is that a person who is not a computer professional sees this interface is not easy to understand, misunderstood, or difficult to operate.
After understanding the real motivation of users to propose changes, the subsequent analysis is whether such changes are necessary, feasible or not, or whether there is a more reasonable solution. Every time we will return some unreasonable or unrealizable demand changes proposed by some customers, and give our reasons. As long as the wording is appropriate and well-reasoned, clients are often able to accept our recommendations and cancel those requirements (more suggestive, less imperative). For other change requirements, we often analyze their real needs from the user's surface language and make a more reasonable suggestion. In this way, the client will not only accept your suggestion with pleasure, but also have the feeling that you are a roundworm in his stomach, trust you more, and your prestige in the client's heart will also increase.
When the customer put forward the change requirement, and after the analysis has determined the modification plan, Mr. A immediately went back to organize the design and development, but he did not know that this would be an important reason for the huge hidden danger in the later stage of the project. What should be the correct approach to iterative development? Let's break down this issue in detail next time.
Reprinted from http://fangang.iteye.com/blog/1208221