7 major waste during software development)

1. Additional Features

According to the Standish Group survey, the traditional software development process creates a large number of features that people do not need (7% always used, 13% often used, 16% sometimes used, 19% rarely used, 45% never
Used ). Every function must go through the entire lifecycle of Software Development: requirement analysis, design, coding, testing, release, and maintenance. This requires a lot of manpower, material resources, and financial resources, if people will not use these functions in the end, all investment will become a waste. This does not take into account the overhead of system complexity caused by too many features. Therefore, additional features are the greatest waste of software development.

2. partially completed work (inventory)

In Lean Thinking, Mary
Poppendieck maps one of the seven major wastes in the manufacturing industry "inventory" to the demand list in software development. Her judgment environment is that the software requirements are carefully written, meticulous to the extent that can be directly used for programming, and these refined requirements will not be immediately implemented, on the contrary, they will wait for a long period of time in the demand list. Of course, there is no doubt that this is one of the "inventories" in software development, but I think this is not all inventories. In addition, there are some common phenomena: Most of the "encoded" functions have to wait a long time before they can be tested, the tested functions will wait for a long time before being accepted by the customer. These functions are inventories during the software development process. They are the second waste.

3. Additional steps (overprocessing)

Similarly, this waste is identified in Lean Thinking as too much refinement of requirements and unnecessary documentation work, and I agree with this statement. I also think this statement is not comprehensive, because the extra steps (overprocessing) exist not only in the requirement, but also in the code. Many programmers will do a lot of "preventive" work in the Code, such as predicting possible changes or possible situations, in order to leave room for these variables, the result is usually some additional code in the code. This method increases unnecessary complexity. On the other hand, if "possible" situations never happen, the Code becomes a liability. The emergence of the design pattern may alleviate this problem a lot. However, we should always pay attention to whether the development process has been overly handled.

4. Search for information (Context switching)

In the software development process, customers are often asked to confirm or clarify their requirements. They should convey the design ideas and technical points to developers, and ask team members to learn about the progress of the project, in short, the stakeholders need to communicate with each other in a large amount. All these communications are information transmission processes, therefore, it is very important to convey information in a timely and accurate manner. At the same time, the development team often faces a situation where it is difficult to find customers to communicate and confirm their needs, or they have to spend a lot of time and energy searching for information they need, we often encounter embarrassment and waste caused by misunderstandings. The time the team spent looking for information does not directly create the value of software, so it is a waste and efforts should be made to reduce it. I have also seen some people in some communities define context switching as one of the seven major wastes. After careful consideration, I think the context switching process is actually to find another type of information in a timely manner, and enters the state process, so it is consistent with the meaning of the information to be searched.

5. Software Defects (Defects)

Does a Bug create value? No, no Bug is what the customer expects. Does a Bug generate overhead? Yes. overhead is required for discovering bugs, reporting bugs, locating bugs, fixing bugs, and verifying bugs. Can bugs be avoided? Most bugs can be avoided. Therefore, defects in software are a waste of resources. If you can take appropriate measures to reduce the occurrence of bugs, it will save a lot of time to handle bugs, and then use these time points for valuable things. This positive and negative will produce a huge difference.

6. Waiting

Waiting also includes waiting customers. It is of no value whether it is the waiting of customers or the mutual waiting within the development team. Waiting also delays problem exposure and resolution, so reducing waiting is to reduce waste.

7. Hand over (Handoffs)

According to the study, if a person's expressive ability is acceptable, he may be able to express about 70%. If the other person's understanding ability is acceptable, he may be able to understand about 70% ~ 80%. If so, imagine that the information is transferred from one person to another, and then to the next person, and then to the next person. How much is left? The same is true for work handover. the more people who handle the work, the more places that need to be handed over, and the higher the cost. Therefore, reducing handoffs reduces waste.