Cruise is released once a week-fast delivery of lean Software Development Principles and Applications

Since last year, the cruise team has insisted on updating their own Cruise servers at least once a week, and updating the cruise servers used by other teams once. Four months ago, we created another personal build CI server, which is deployed more frequently. Once submitted to the continuous integration server of the team, the unit test passes, cruise will automatically deploy it on this server. The results are very good, because this continuous Integration Server is used by every developer for pre-commit. If it does not work properly, developers will know immediately (because their pre-commit test can be passed, hey), it is also a practice of building quality in.

------------------------------------------------------

 

An important part of the entire software lifecycle is the O & M period after the system is launched. The length of the software O & M period ultimately proves whether the software is successful.

 

However, the fact is that many software was launched after six months of Development and six months of debugging and test run, and it was not long before it was listed as an upgrade and transformation project. What is the reason for this.

 

Let's first think about why the customer wants to develop software? The user must complete one of his tasks, and this task requires the help of the software to complete better. In other words, without the software, the user's tasks can also be completed, and the results are the same as those with the help of the Software. Why should the user pay for the software?

 

Therefore, software must be a product that delivers business value to users. If the task is canceled before the software is released, the value of the software will be lost.

 

The upgrade mentioned above is exactly the case. That is, when the contractor takes a long time to develop the software, the business objectives of the producer are changed. What will happen at this time? The poster will certainly inform the contractor, "my business is about to change. Do you think our software can be made like this ?" "Our software architecture has been well established, so we have to go into details. If it changes now, we need to modify the software architecture, almost from the beginning ."

 

As a result, the delivery of the software will be postponed (three months. If the user's requirements change after two months, what will happen next?

 

The problem is that the software or framework we have not yet delivered is the inventory in the production warehouse. If the market demand changes and such a product is no longer needed, it will become a backlog of products, that is, "waste! What we often do is "dumping these backlog of products to users, on the condition that users are allowed to pay more money, and then deliver their new needs together ".

 

 

If we can take the user's business goals as the goal and the software as a tool to accomplish the business goals, we can break down the functions of this tool according to the user's business goals. Through the decomposition of such business objectives, we can find the business priorities of sub-targets after decomposition. In this way, the customer can be effectively persuaded to divide the project into multiple release, and both parties will reduce the risk.

 

The rapid delivery of multiple release allows users to use software tools to accomplish their business goals as early as possible, and allows developers to further understand the real needs of users, so as to verify their own software, reduce future release risks.

 

Imagine that a weekly release would not be so terrible.

 

One release every week is not impossible. The question is, have you ever seriously thought about this problem?

 

If it can be released once a week, there will be no worries about launching the trial run.