Shulou(Shulou.com)06/01 Report--

I. what is quality built-in

1.1 about quality

In software development, quality is an eternal topic, as shown in the following figure, this is the project management triangle in traditional project management: we can find that the cost of the three sides of the triangle, time and scope revolve around quality. in other words, quality is considered to be the center of choice and an attribute that cannot be compromised. In agile project management, this triangle has evolved, and the result is shown in the following figure: we can see that in addition to turning the scope into a more focused customer value, the weight of quality is also enhanced to enhance the end-user experience. Therefore, we should not pay too much attention to quality. So how to better get the quality we pay attention to? Especially at present, in order to adapt to the change of demand and deal with the uncertain market more flexibly, how to ensure the quality has become a more prominent problem. You know, for agile development, "fast" does not mean "rough". MVP is "simple" but does not mean it is "crude". The promise of quality has never been compromised or discounted. We think that the quality is not added later, the quality is not tested, the quality is built-in! 1.2 what is the built-in quality role in the development process, all roles involved in the software life cycle are required to be responsible for the quality of the software in real time. Ensure that the software has basic quality assurance before it is delivered to the next step. Its core purpose is to reduce rework caused by quality problems and avoid wasting a lot of labor costs. 1.3 quality built-in in Lean Agile is one of Lean's core principles, which helps us reduce waste and avoid delayed costs associated with demand recalls, rework, and defect repair. As shown in the figure below, we can know that about 85% of bug occurs in the coding phase, but the cost of solving them is the lowest. In other words, if we can avoid these bug in the coding phase, then we will reduce the bug in our products by 85%, thus avoiding the exponential growth cost of solving defects later. In other words, "the earlier the problem is discovered, the lower the cost of repair."

Quality built-in is also one of the Agile principles, and one of the 12 principles of the Agile Manifesto clearly states that it is necessary to focus on quality: "Agile capabilities are enhanced by the unremitting pursuit of technical excellence and good design." The description of "Sprint" in the "Scrum event" in the Scrum guide makes it clear that "the goal of quality cannot be reduced during Sprint". Built-in quality in SAFe is one of the four core values of SAFe. Built-in quality ensures that every element and increment in the solution meets the quality standards, and the quality is not "added later". Built-in quality is a prerequisite for lean development flows, and without quality, the operation of the organization may be accompanied by a great deal of untested and validated work. This can lead to excessive rework and slower delivery. There is no doubt that built-in quality is critical for large systems (in fact, built-in quality is essential for any system), and quality is mandatory.

Second, if there is no quality built-in

If there is no quality built-in, then we will encounter a growing technology debt until we are unable to repay it. The friction between developing a new feature and modifying an old bug. Unpredictable delivery, slow response to customers. The team lost confidence in quality. 2.1 Technology debt, which is the bad smell we leave in the code. For example, a class has too many lines of code, the coding format does not conform to the coding specification, repetitive code, hardcode, workaroud, unreasonable architecture design, and so on. It should be noted that technology debt is not always a bad thing, or technology debt is not zero tolerance. For example, in the early stage of the design of one of our products, we may still be in the commercial stage, so we need to launch our ideas very quickly and be verified by our customers. At this time, in order to make quick trial and error, we will inevitably introduce technical debt. However, it should be noted that once feedback is received and it is decided to continue, the technical debt needs to be repaid in time in the following iteration to avoid the accumulation and spread of technical debt. Technical debt carries interest. When programmers are writing code, if they find that the original code is very bad, they will scold and automatically copy and paste it at the same time, and produce the same bad code in the same style. Therefore, during the code walk-through and fault review, the most common excuse we hear is that this is how the original code was written. Poor quality code constantly increasing technical debt, should be passive to active, only built-in quality can enter a virtuous circle. Technology debt cannot be avoided, and failure to pay it now will only make us pay a higher price to repay it in the future. Why do you need to solve defects in the software in the first place? It's because you can't extend bad code to avoid interest on technology debt. 2.2 friction between new features and old defects in agile development we promise to do some Story in each Sprint, or in the Kanban pattern as shown in the figure below, we want value to flow. Imagine if we were doing story C or D and An and B were testing, and then there were a lot of bug. We will get caught up in the friction of continuing to develop new features and fix old defects, and the more bug we have, the greater the friction. If we do not solve the bug in Story An or B in time, the value will not flow and may hinder a series of subsequent behaviors, such as testing, release, etc. But if we solve the discovered bug in a timely manner, it means that the process of developing new features will be constantly interrupted, which will make our development pace chaotic and inefficient. When we do C and D, we don't feel "cool", we only feel the pain of the death march. Even worse, when we are already developing G and H, there are still bug from An and B (release phase) and CMagne D (acceptance phase), and we may have to deal with problems in G and H, and the pain caused by this friction can be imagined. Only when the quality is built in and the defects in each part are reduced can the flow of value be smoother and smoother. The flow of value is like water, we can not let the water countercurrent (frequently go back to correct previous problems), but also as far as possible not to let the flow of water stop. 2.3 unpredictable development of delivery iterations allows us to identify and solve problems earlier, so as to deliver customer value increments on time as much as possible at the end of the iteration. Before entering the iteration, we will use various ways to estimate the workload of the new features to be developed, so as to select part of the appropriate user story as the iterative commitment (Scrum), so that we will have an expectation of delivery, even if the end of the iteration can not meet all the commitments, then we can have a relatively clear prediction of how long the remaining user stories will be delay. But poor quality will destroy our expectations and predictions. Because you can't predict how many pits there will be on your road in the next two weeks and when you'll be able to fill them. Sitting in front of the computer is like walking in a fog. I can't see where the end is, and I don't know where I am. I can only bury my head in the hole and wait for the dawn to see the flag at the end of the road. Poor quality code makes it difficult for team members to back up each other, especially when it is difficult for newcomers to get started and even have to ReFactor. This is why no one wants to touch the ancestral code, because the quality of the code is too poor to understand, difficult to expand, unclear architecture, logical confusion, and seriously affect the principle of public ownership of the code. once others are involved in parts they are not familiar with, they will encounter the various pits shown in the above figure, and the expected delivery time cannot be guaranteed. The software development process is often complex and changeable, so batch repair is bound to bring new defects. 2.4The team's loss of confidence in quality is also cumulative in Bug. The more bug you have, the harder it will be to eliminate each bug. Partly because bug interacts with each other, the failure shown may be the common result of many errors-which makes it difficult to find each one. This is also psychological, when there is a lot of bug, people naturally lack the passion to find and solve these bug-, which is a phenomenon known as the "broken window effect" in the book Pragmatic Programmer. Broken window effect (English: Broken windows theory) is a theory of criminology, which was put forward by James Q. Wilson and George L. Kelling. This theory holds that if undesirable phenomena in the environment are allowed to exist, it will induce people to emulate or even aggravate them. In a building with a few broken windows, for example, if those windows are not repaired, saboteurs may break more windows. Broken window theory can well explain the reasons behind people's violation of code cleanliness and turning a deaf ear to quality problems: it is because it is rubbish, and other people's wrong actions are not punished or restrained. Then it is normal for me to do the same thing and behavior, and everyone is the same. But the so-called irrelevant mistakes or flaws are put in the past and accumulated, and when there is an avalanche, not a single snowflake is innocent. Finally, the whole team pays for the quality. How to avoid the broken window effect? So that our quality can be maintained in a healthy state? The way to deal with it is the Boy Scout rules: "when you leave a camping camp, make sure it is cleaner and cleaner than it was when you came." Every time we commit, we should make the code a little cleaner than the previous version, even if it reduces some of the duplicated code and fixes a format problem. It also keeps us away from the bad smell of code and keeps our code and architecture clean.

Third, how to build in quality

Requirements Analysis this is a process of continuous dialogue between PO and the team. The clarification of US and AC is one of the most important means or tools to ensure external quality. AC is not a contract, and US is not a document for handing over. Their most important role is to communicate. The analysis of requirements is the beginning of our built-in quality, the input is garbage, the output must be garbage. Without adequate requirements analysis and communication, quality will be out of the question. When the requirements are clarified, we should pay attention to: starting from the end, to ensure the quality of the requirements input. As shown in the agile triangle we gave at the beginning: the first thing to do is to explain the business goal, that is, value, in other words, to solve the user or business problem. Secondly, the operation and operation flow, in order to achieve the above goals, which user operations does the system need to support? What is the process of these operations? The third is the business rules, what are the business rules corresponding to each operation step? Business rules will be translated into acceptance criteria. Demand is not the solution, but the value of the user. Only when we start from the value, decompose layer by layer, and fully communicate from the business to the implementation level, can we ensure the quality of the later delivery.

3.2 continuous integration is not a new concept, but a part of our software developers' lives. To put it simply, continuous integration is a software development practice, that is, team development members often integrate their work, usually at least once a day, which means that multiple integrations may occur every day. Each set is verified by automated builds (including compilation, release, and automated testing) to find integration errors as soon as possible. Many teams find that this process can greatly reduce integration problems and enable teams to develop cohesive software more quickly. Continuous integration is an important practice of our quality shift to the left. Because it can give us very timely quality feedback, the more frequent integration, the earlier the discovery of problems in the code. In the engineering practice of continuous integration, we need to automate everything. Because frequent integration means continuous and repeatable work. Automation is far more reliable for this kind of work than our manual operations. As engineers, code is our tools and weapons, and wherever it can be automated, it should be implemented in an automated way to reduce defects caused by human errors and release our energy and time. Focus on more valuable and creative tasks. In the era of DevOps, quality would be out of the question if you wanted to be released online within an hour after the code was submitted, without the weapon of continuous integration. Test-driven development (TDD): test-driven development is an important part of Extreme Programming (XP)-extreme programming. It is also a design methodology. The principle of TDD is to write the unit test case code before developing the functional code, and the test code determines what product code needs to be written. Although TDD is the core practice of XP, it applies not only to XP (Extreme Programming), but also to other development methods and processes. The more important advantages of TDD are: first, it can clarify the requirements, because the test comes first, so the test cases are designed according to the requirements, not the code, and the ambiguous requirements have no way to write the test cases and must be clarified in advance; second, it can avoid over-design and only write the code that allows the test cases to pass without writing a single line of extra code. Third, the test case is the best code comment, avoiding the problem of no comments / documentation or document / comment expiration; fourth, there is a test case set submitted with the code to ensure the security of future refactoring and code conflicts. These advantages will be a strong guarantee of quality. Acceptance test-driven development (ATDD): at the code level, writing test scripts before coding is the above-mentioned TDD, while at the business level, the acceptance criteria for requirements (such as user stories) are determined during requirements analysis, which is called acceptance test-driven development (Acceptance Test Driven Development,ATDD). The relationship between TDD and ATDD is shown in the following figure. ATDD solves some of the practical obstacles encountered by TDD in practice, such as tight deadlines and more time for unit testing. Prepare acceptance criteria and test cases from a requirements point of view. It can also ensure high quality from the beginning of development. Behavior-driven development (BDD): BDD can be regarded as an extension of ATDD, but BDD emphasizes users' perspective and behavior, injecting a specific requirement description language such as "Given,When,Then" into ATDD. It fits very well with the agile user story. When writing test cases, TDD often says "what should we test first" and then populates the code according to the conditions of the test, while BDD tries to think about the problem in a different way, that is, ask himself, "what is the expected behavior?" It is possible to write better structured code In the final analysis, BDD pays more attention to the needs of customers, and has a deeper understanding of customers' needs by understanding their different behaviors, so as to drive software development with the help of a deeper understanding of requirements. The following figure is a typical case of BDD: the relationship between BDD and TDD can be clearly seen in the following figure: 3.4 refactoring in Martin Fowler's famous book refactoring, he defines refactoring as "the process of making changes to the code without changing the external behavior of the code to improve the internal structure of the code." But why change the structure of the code that is running? We should all know that Henry Ford has a saying, "if something isn't broken, don't fix it!" The purpose of refactoring is to clean your code all the time. We don't want the mess to accumulate. We want to be able to expand and modify our system with minimal effort. One of the principles of agile development is to deliver available user functionality for each iteration so that user feedback can be obtained more quickly and then improved based on real data and feedback. This is the requirement, and so is the code. In addition to maintaining the status quo, the code must also be robust enough to cope with changes brought about at any time. How do you keep the code alive? Refactoring is our only choice. Refactoring is also a good way to eliminate the technical debt we mentioned in this article. Of course, it is not easy to refactoring, before refactoring, first check whether you have a reliable testing mechanism. All the engineering practices with better results must have higher requirements for practitioners! There are never shortcuts. 3.5 the necessity of Code review for Code review does not need to be restated, and the benefits of Code review are hardly controversial. Code review is not only an access control for quality, but also a good way for knowledge sharing. So how to ensure the quality of review? First of all, we need to adopt different review strategies at different stages of the team's technical capabilities. For example, if the team is stable, the coding specification is well mastered, and the language used is also familiar, then maybe the focus of review will be on business logic; if the team is newly formed and is still running-in, the coding specification may need more attention; if the team has changed a new programming language, then the syntax itself may also be the focus of review. Different review strategies are also needed at different stages of the company's business development. For example, if the business of To B is progressing steadily, Code review may need to be more careful and strict to ensure the quality and readability and maintainability of the code; but if it is in the Internet industry, in the early stage of business development, in the stage of rapid trial and error, then Code review needs Technical Leader to balance the strength of review and the requirements of business delivery. Requires an open culture and mindset in the team. Make it clear to the team that Code review is not about setting up obstacles or finding faults, but an essential process of quality assurance and a process of learning from each other. Here you need to have a consensus on the programming specification to avoid unnecessary objections because of programming habits. Control the amount of code required for Review each time. If you submit a large amount of code for review at one time, it is very difficult for people who do Review to devote so much time at once, and the other is that it is easy to miss the point. At the same time, the person who submitted the code should write clearly the purpose of submitting the code in commit note: what function is achieved? What kind of optimization are you doing? What bug was modified? In this way, review can be targeted and clear about the context of code changes. Finally, to make Code Review a habit and a part of your work, you need to guarantee the Review's time, because everyone has their own committed task in an iteration, and review can be executed as a day-to-day task only if Review time is set aside. You can use review as part of DoD. 3.6 Code sharing is the embodiment of the spirit of "sharing and progress". It means that everyone's code belongs to the team, and everyone can modify any code. Collective ownership encourages everyone to contribute new ideas to all parts of the project. Any developer can change any line of code to add new functionality, fix defects, improve the design, or refactoring. No one will be the bottleneck of change. In the absence of collective code ownership, it will cause difficulties in modification and refactoring, and even lead to duplicate code, increase technical debt and destroy code quality. Code ownership can enhance the team's ownership of the code, all of them become the person in charge of the code, they supervise each other and share information. In the environment of code co-ownership, the environment of no leadership, no authority, fair and open brings us back to the most essential engineer culture, from which quality comes into being. 3.7 Code is documentation this is an engineering practice used by Nokia, and the reason for using code as the main source of documentation is that the code is the only code that performs the role in sufficient detail and accuracy. Especially in agile development, documentation is becoming less and less important (although Agile has never said that documentation is not needed). Incomplete documents, out-of-date documents and wrong documents will mislead us in development and maintenance, resulting in unnecessary defects and waste. Including comments, if a programmer modifies the code, but does not modify the comments, it will cause more trouble. Once something goes wrong, it is difficult to know whether the code logic is wrong or the comments are out of date. This is more common in ancestral code. So using code as a document can make our vision clearer, and we can have the only quality standard: working code. In order to ensure that the code is documentation, programmers need to make efforts to ensure the cleanliness and readability of the code, as the refactoring part said, good engineering practice must correspond to higher requirements. Reference: https://www.scaledagileframework.com/safe-core-values/http://blog.cutter.com/2009/08/10/beyond-scope-schedule-and-cost-measuring-agile-performance/ Agile Triangle Jim Highsmith http://agilemanifesto.org/principles.html Agile 12 principles https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Chinese-Simplified.pdf Scrum Guide

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.