Waiting during software development

The proportion of waste waiting in the software development process should be the largest.

Which of the following waits have occurred in your project?

(1) waiting for confirmation from the customer
(2) Wait for the command from the supervisor
(3) Wait for Environment Construction
(4) wait for the results of the previous stage
(5) wait until the bug is modified
(6) Wait for the test result
(7) Wait for the UI design drawing
(8) Waiting does not know anything-inexplicably waiting

In fact, there is no need to wait.

First, you must understand the reason for waiting. Only in this way can you find the root cause to eliminate unnecessary waiting.

How does waiting happen?

The first is caused by an incorrect process definition.

Why do two processes need idle time? Because these two processes are completed by different people. When a person works, another person must wait.

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

For example, after a tester registers a bug, the developer needs to analyze the cause of the Bug, analyze the impact, propose a solution, and modify the bug, after self-verification, submit it to the test personnel for confirmation.

Throughout the process, testers are basically waiting.

If this is because the process is set in this way, there is no way to wait, it is a bit of regret.

After analyzing the problem, we should continue to analyze the problem.
The reason why the regression test process needs to wait is that the process design is incorrect. That is to say, the design of the process to be waited for in the test results in waiting.

Imagine that if we put the test aboveCodeWhat will happen if the changes are placed in the future?

That is to say, test cases are expressed by automatic test code.
Developers only need to run the test code to check whether the code is modified correctly. At this time, testers who have completed writing the test code can do other work (such as adding new test cases) without waiting.

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

For example, after the requirement document is sent to the customer, the customer who needs to wait for confirmation can start the development work only after the customer confirms it.

This is also the process requirement. If the previous project is not completed, the next process cannot begin.

In fact, this is not the case. The reason for this waiting is that the communication method is incorrect.

The requirement is written in a document, which makes it necessary to wait. If the (functional) requirement is presented using a working prototype (that is to say, the development work is started directly and presented to the customer with the developed results), as long as the customer confirms OK, the prototype can be directly converted into software that can work (such as modifying the logo space of the development/release version ). In other words, after the requirement confirmation is completed, the development is basically completed. If the customer says it wants to change, change as required until the customer confirms OK.

For non-functional requirements, such as performance, security, and fault tolerance, we can discuss them at the meeting. We can leave confirmation on the whiteboard COPY method and immediately enter the development correspondence without waiting.

The above two waits are caused by incorrect process design and can be avoided by adjusting the process.

SecondWait is caused by inadequate management.

For example, the requirement details are unknown because the requirement validation document is not managed, and you need to recall and search for the document. The wait formed by the inability to perform subsequent work during the Recall Search and period is caused by inadequate management.

However, in turn, if you want to sort out all the validation details, it will also take time. How can we weigh the gains and losses between the two? The development team will leave document records for self-protection purposes. However, this approach will also lead to other waste. For example, chew text.

So how should the functional requirements be recorded? Story card, number.

 

What's more, all users are shut down to prevent viruses...

 

Management is not in place and can be avoided by improving management methods.