Version release failure Summary

Document directory

• 1.1.1. Clearly defined delivery (Scope)
• 1.1.2. Qualified quality
• 1.1.3. delivery on time
• 1.1.4. Requirement understanding
• 1.1.5. prerelease action
• 1.2.1. Unclear scope
• 1.2.2. Poor Quality
• 1.2.3. Unable to be on time
• 1.2.4. The requirement cannot be understood.
• 1.2.5. No prerelease
• 2.3.1. Incomplete decomposition and poor trackability during scheduled tasks
• 2.3.2. Story PIC problems during execution
• 2.3.3. No valid acceptance for story
• 2.3.4. decision-making and execution problems in case of problems

1. Definition of successful/failed versions by the Team 1.1. dependencies for successful releases 1.1.1. Clear definition of delivery Scope

For every iteration of iteration, every member of the team needs to clearly know what the goal of this iteration is, that is, our iteration goal, and what story we need to accomplish, what is the priority order, and what is the status of each story to be delivered.

1.1.2. Qualified quality

Each release can be regarded as a successful release only when it meets the quality goal. Simply put, it should pass our sanity test (smoke test ).

1.1.3. delivery on time

Each release must be on time, and the time schedule must meet the delivery requirements.

1.1.4. Requirement understanding

A good understanding of requirements is the prerequisite for successful release. A clear understanding of requirements in the early stage will greatly reduce the troubles and risks, including quality risks (the requirement must be well understood and the quality will not be poor) and the risk of the delivery scope (the scope may be completely clarified only after the requirement is clearly understood ), the risk of time (more accurate time can be estimated only after the requirement is clearly understood) will be reduced.

1.1.5. prerelease action

This does not seem important, but it is actually very important. The prerelease action mentioned here means release in advance, not only in advance, but also in a more complete and standardized manner.

Especially for the first release, there are actually a lot of things to do. We recommend that you do prerelease at least three days in advance. Because the first release requires many preparations, such as the installation manual, as the publisher, you also need to strictly execute the installation action against each step of the document to ensure that all published content can be installed normally. This action may take one day. Another important thing is that the publisher needs to perform system integration for all the content to be delivered and complete sanity test to ensure that the released version is testable and has no serious problems. This process is the most likely to cause rework, because major defects must be solved. After the two major actions are completed, the release actions on the third day can be greatly ensured. Even if it may fail, you can use the pre-release content of the previous day to release the content to reduce the possibility of publishing failure.

1.2. possible causes of publishing failure

Here, the dependencies for successful releases correspond to one by one. The chances of success are high. If the dependency is not good, it may lead to failure.

1.2.1. Unclear scope

I don't know what we want to release in this iteration of iteration, what content it contains, and what fixes it delivers. Why did you say that the release was successful?

1.2.2. Poor Quality

The service process is blocked and cannot be tested at all. Even if it is released, it will be released. Why did you say that the release was successful?

1.2.3. Unable to be on time

It cannot be released at the release time. For our goal of setting the on time rate of 100%, it also fails.

1.2.4. The requirement cannot be understood.

The above part of the success factor also says that the requirement can be clearly understood to make the Scope clear, so that the quality can reach the standard, and the delivery can be made on time. The requirement understanding is the basis and premise. On the contrary, what about the successful release?

1.2.5. No prerelease

The prerelease action aims to make full preparations in advance, identify problems as soon as possible, and solve them in a timely manner. The essence is to improve the release success rate.

2. What causes the release of our project to fail? 2.1. What should I do for publishing?

Everyone in the team should have a certain understanding of what to do for release, so as to better cooperate with the publisher for release, because the release actually involves a problem of team cooperation, while the publisher is releasing, on the other side, how do developers continue to develop or modify defects? How can we find the right time for publishing? This requires careful consideration.

As a publisher, we should be more clear and familiar with what release needs to do? We have made a detailed definition of this process in our organizational process assets, including the PPT guide and to do list. You want the publisher to familiarize yourself with this information.

2.2. the prerelease action was not completed

Although PM requires three days before the release deadline, and the publisher has made some preparations, such as preparing the installation manual and installing the Oracle environment, it is far from complete. Many actions are not in place or are not done at all. This increases the risk of publishing.

We have already discussed how to make a prerelease in point 5th of the dependencies on the successful release above. We will not repeat it here.

2.3. emails and related story cannot be delivered on time

This may be the most important or important reason. The entire iteration cannot be released because multiple message-related story cannot be delivered. In my opinion, this is not the case. In fact, this problem is caused by the sharp outbreak of the problem due to the failure of the last level.

After analysis, the following main causes are obtained:

2.3.1. Incomplete decomposition and poor trackability during scheduled tasks

At the beginning of our plan, we ignored the story of the mail and did not complete the complete task decomposition action for the entire story. We have not split all the possible tasks that we can recognize. As a result, we have missed the story tasks on the task wall, so that we cannot track or even forget this part of the work.

2.3.2. Story PIC problems during execution

First, there is a connection problem with the allocation of story. The recipient of the mail's story clarifies that it is only responsible for the development of the mail's story. Then, who else will do it and who will deliver the story, unknown.

We recommend that you have a unique owner for each story. The responsibility of this owner is to ensure the completion of story, but not all of them need to be done. It may be done by multiple people, and the integrity and deliverable of story can be ensured. So he needs to hold the entire story and take charge of integration and delivery.

Second, when sending an email related to story, Zhigang was ill and asked for leave. Our team was not doing well when Zhigang was ill. If Zhigang is ill, who will take over the responsibility of Zhigang and who will continue to take delivery responsibility for Zhigang's story, we have not defined it in time. This also leads to work omissions.

To address this, we can conclude that if someone is not in the team and cannot wait for him to return, he must change the sole manager of story immediately, to ensure the delivery of story.

2.3.3. No valid acceptance for story

Here, we may think that TM (technicalmanager) has not completed the acceptance, but we believe that TM is only responsible for secondary tasks. We are a team, and each of us should be responsible for the products delivered by ourselves or by others. It is completely deliverable to ensure that a single "component" has no quality problems for the products delivered by itself. For example, in this event, as long as the first delivered story is checked strictly according to requirements and its integrity is checked, the mail function is not implemented as soon as possible, its implementation scheme may have problems and its impact on other story. TM focuses more on whether all the "parts" You deliver can still work as the customer wishes when they are integrated.

2.3.4. decision-making and execution problems in case of problems

At the time of release, multiple message-related story tasks were not completed yet. We were faced with technical difficulties in integrating the mail function with other parts of the story. This is because Zhigang has sent emails to the other two related story files and has delivered the documents for acceptance. However, Zhigang is absent and cannot contact them in time, therefore, it is difficult for us to continue with Zhigang's old plan in the near release level.

At this time, we think of two main solutions: a) continue to study Zhigang code and seek external help to find a solution. Other mail story continues to follow the old scheme. B) Overturn the old scheme and replace it with the new mature scheme of travelling.

In fact, there is no absolute right or error in selecting a solution. I just want to throw this question so that you can think about how to deal with it in the future, how can this problem be solved?

For the above problems, we should first make some analysis:

1) I have a general understanding of Zhigang's solution and his design ideas. Since Zhigang has already delivered two story, he must have designed it. So is his design suitable for the rest of the mail story, how much workload? How much work is required to overcome the difficulties of the Zhigang solution? Here, we have to emphasize that members should communicate with each other about their respective tasks and share their technical solutions and experience in solving problems. This reduces the difficulty of task cohesion.

2) If the traveling solution is used, is the traveling solution suitable for our current wilegal architecture? What are the risks that traveling's solutions apply to our projects? How big is it? What preventive measures can be used? If you use the traveling solution, will the two story files delivered by Zhigang be affected? What about future maintainability? What is the workload? And the workload caused by rework, including integration testing and system testing.

3) The team should get the final resolution after comprehensive analysis of their respective advantages and disadvantages. When a resolution is available, all team members should resolutely execute the resolution and actively discover and analyze and solve the problem. The strength of the team is a strong backend to the success of the project.

I would like to share with you the lessons learned from the above and hope to learn from this and continue to improve.