View self-similarity of agile development from continuous delivery (heartbeat of Agile Development)

Author: Chen Yong

Source: blog.csdn.net/cheny_com

Self-similarity refers to the similarity between a part of a thing and its larger part or even the whole.

From a big perspective, Agile Development attaches importance to customer value and advocates continuous delivery. However, in general, the product owner often has a very good sense of customer value, while the first-line developers pay more attention to the technology itself, so once they only stay at the ideological level, in actual work, we will find some deviations. Therefore, we should look at the overall idea and local practice of agile development from the perspective of self-similarity, so that everything is consistent with the idea of agile development.

This article only analyzes the self-similarity of agile development from the agile development idea of "continuous delivery.

"Continuous delivery? Is there a runable version for each sprint end ?" Yes, no.

 

Continuous delivery at the end of the sprint

One of the greatest features of agility is the delivery of runable software in stages, rather than a bunch of documents that are temporarily unavailable. According to the concept of lean production, documents are just an intermediate product, which is not only difficult to write but also difficult to review. Even if you see a perfect requirement document in the early stage, it is also difficult to ensure that the perfect software can be seen at the end. Therefore, agile development determines that, as long as possible (not absolute), it is possible to bypass this intermediate product and use runable software to indicate the progress and quality of the software.

At the end of the sprint, the product owner and stakeholders did not look at the document, but looked at a workable software for review, which is the core purpose of continuous delivery. To facilitate review, a group of related stories is often delivered, rather than "the most important requirements currently ".

 

Continuous delivery within the sprint

During the sprint period, you can see that it is calm. You are busy waiting for the final delivery, but it is not. If each iteration starts from "requirement analysis" and finally "system testing", agile development will become iterative development. However, even if each user story is developed independently, a bunch of stories may still be "under development", but these stories cannot form a running software state because they cannot be separated into chapters. In order to prevent this situation, good stories are generally independent, testable, and complete delivery of a customer's value. Therefore, every time a story is completed, a temporary executable software can be formed.

If you follow the Moscow method (as detailed in another blog post), you can ensure that you can still deliver an available software to the product owner even if you cannot complete all sprint backlog items at the end of the sprint.

 

Continuous delivery of "daily creation"

Daily build is well known for its ability to deliver software at the end of every day (this is Microsoft's pioneering development in Windows), but for small software development, you can see the results in 10 minutes after each code submission. It is incredible for 1000 people to locate 1000 defects in software developed for 1,000,000 days (one person per day on average ), however, it is very realistic for everyone to locate a defect in their daily code, provided that you can find it, and daily creation is the logic.

Continuous integration and automated testing, which are often referred to, refer to the continuous delivery activities at this level. The goal is to form the runable software in the shortest time after code submission, check whether the problem exists.

 

Continuous delivery between versions

Many software seems to be more and more powerful, but the market response is not good (for example, the "free" office installed by many people is 2003, that is, there is no intention to do business with MS in seven years ), the reason is that these software did not solve one problem: "Which market is the next version oriented? Why did they buy it ?" At this time, the software can easily follow the thoughts of the company's leaders, or be led by one or two major customers, or blindly try to cover all the functions of competitors and lose nature.

Or the previous sentence: plan the version content according to the business pace, that is, after each version is released, it must meet certain requirements, obtain some customers, defeat some competitors, replace some products ...... If you can find out who these "some" are, the next version will be successful. If you cannot find them, maybe the product has reached the stage of quitting the market. If you cannot find the market and customers continuously, it is meaningless to continuously deliver executable software.

 

Click to download the free agile development textbook: Martian agile development manual