Welcome to demand changes and embrace changes

First, say happy new year to all the friends in the garden!

Last year, I spent half a year at the customer's site working on the project and delivered the project on time. Many incidents occurred during project development, most of which were demand-side changes. Our team was also worried that the project could not be completed as planned. It turns out that these concerns are redundant. As long as there is a good development process, we can embrace changes.

Before arriving at the customer's site, the team had organized the requirement documents into a list of user stories, all of which were managed in mingle. One week after arriving at the site, that is, the first week of the project's formal start (we call it 0th iterations), the Project Manager and Business Analyst completed the iteration plan for the first few weeks together with the customer. From the perspective of our developers, if you know what to do, you can start the project.

The first two iterations are progressing smoothly, not only because developers are getting started quickly, but also because the actual workload exceeds the plan to complete more stories. So on the first day of the third iteration, the manager was confident to present the project to the customer.

In our project, the customer will be demonstrated after each iteration. Its advantages include:

• 1. confirm that the developed product meets the customer's requirements.
• 2. Collect customer feedback to help the team make continuous improvement
• 3. Give the customer confidence to see the Team's work results and efficiency
• 4. Confidence and achievement for team members

However, the customer said that this was not the system he wanted to see. It did not reflect the requirements, nor the spirit and purpose of the company. However, he cannot tell what the system he needs is. At this time, everyone in the team was very depressed. In order to truly reflect the needs of the Team, let the customer say at first glance: Well, this is the system I want. I cannot understand it. After that, the team held a short stand-up Meeting and made a decision. It took me one afternoon to resume the demand meeting and communicate with the customer, find out the information we need.

At the beginning of the meeting, the Project Manager briefly introduced the arrangement of the meeting and then began to discuss the requirements. The customer and the team brainstorm together, and the customer speaks out the desired functions. We sort out the functions, and continuously ask and confirm them until we figure out the details related to all the requirements. The original intention of this meeting was to guide the customer to find the information we needed, but recall that at that time, the customer took the initiative in the meeting, maybe because of lack of experience, only the project manager has quick start experience. In any case, no matter how many detours we take, we still understand a lot of requirements, such as how it reflects the spirit of the company. After the meeting, the team members immediately designed the user interface prototype and made the lofi-prototype of the core page to confirm with the customer. After reading this, the customer was very satisfied and felt that this had better reflected the requirements.

Afterwards, we will summarize the following points:

• 1. The team's understanding of the requirements should be agreed with the customer
• 2. communicate with customers as frequently as possible
• 3. Give a demonstration to the customer as soon as possible, and receive feedback as soon as possible.
• 4. lofi-Prototype
• 5. Confirm the scope and details of the requirement to the customer before starting the user story.

This demand change has a great impact on the development progress. We spent an iteration to rewrite most of the user stories and reintroduce the New iteration plan. However, with this lesson, we followed the above steps in the subsequent development process. After that, there were no major changes to the demand, and the released products were also very compliant with the customer's requirements. Looking back, it seems that this problem is still due to lack of team experience. If it is the best from the very beginning, then this big demand change will not occur.

However, small demand changes have occurred many times, most of which are details. In fact, there is a risk no matter how the demand changes. For example, for a function, remove this and add that. As long as this change is of value to our customers, we should do it. Necessary. We can modify the existing code or add new code. Are you confident to do this, especially in the later stages of the project? Are you worried that the changes will damage the existing functions? Are you worried about fixing bugs? We will not worry about this. Because:

• 1. Each existing function has a functional test.
• 2. Each line of code has unit test coverage.
• 3. For every existing bug, there is a test to ensure that they will not appear again.
• 4. Continuous integration tools are available to provide feedback on a change within a short period of time. If any problem occurs, we can quickly learn and fix it.
• 5. Each line of code you write will have your pair to help you review

With the above measures, You can minimize the risk of demand changes (or modifications to existing code. Because demand changes are very valuable to customers, we are willing to do this (excluding personal sentiment ).

One time the team had dinner with the customer, he said that only the change was the same, and we were quite touched. Since demand changes are inevitable, the risk should be minimized to embrace changes.

 

Some may ask, isn't the first few iterations delayed? Why does it not affect the development progress? In fact, a large part of the reason is that with the team members' understanding of the project, their familiarity with development tools, languages, and frameworks has deepened, and the development efficiency has become higher and higher. But how can we grasp the progress? In the future, I will write my experiences on the project progress.

Address: http://www.cnblogs.com/blusehuang/archive/2009/01/09/1372256.html