Agile development with tools-12

Well, the plan will also be completed, and the sprint will also be set up and set a good time. The functional points to be done in this sprint will also be allocated. It is time for developers to work.

 

After dividing the task, after logging on to devtrack, each development comrade will see the task he needs to do in the story board. Generally, the task status is "under development, just like what everyone does: write code. Of course, you may also need to study it through the requirement information and design documents of the task link.

 

You don't have to write the code. You can directly write the code. After writing the code, first let others review the code. After the code is finished, the commit code is started. At the time of the commit, a window will automatically pop up, let you bind the changed code to the relevant devtrack task, so that you can see the associated code information in the devtrack task.

 

After the code is submitted, if the task is completed, the task is in the "test available" status in devtrack, so that the tester can start the test. Of course, you still needTime spentAndRemaining TimeUpdate the two fields andActual completion timeThe field is also updated. if the task is only completed today, you do not need to change the task status. You only need to update it.Time spentAndRemaining TimeThat's all. Continue tomorrow.

 

After the development is complete, the rest is the test. In Agile development, both development and testing are required in a sprint. Therefore, when a sprint ends, this means that the test has been completed, and all the functions that need to be done in this sprint can be used (of course, some features may be postponed to the next sprint for some reason ).

 

In fact, the ideal situation is that, in a sprint, the development is complete, the test is completed immediately, the development is repaired, and then the test is performed to fix the confirm bug. In this way, a sprint is completed, however, this can only be achieved when the project is very small. In many cases, it may not be as smooth. For example, the Sprint has already been set, but the development has completed several functions on the last day, if the tester wants to test the sprint, it must be too late to extend it. In this case, we will use the development task to complete the sprint as a reference, when the sprint completes the Development of the Next sprint, the test task is basically slower than the development task. That is to say, this week, for example, the development should be in the sprint.
The test is actually a task that has been completed in the test of sprint 1. Someone may ask, if a bug is found during the sprint 1 test, is the Development repaired or not repaired? The answer is repair required! Every sprint is a product that can produce work. If there is a bug, we think it cannot work. It is equivalent to failing to complete this sprint, so we cannot implement the so-called incremental iteration, the increase is not a volume, but a bug. Therefore, during the development of a sprint, there are actually three active tasks, one is to do the function, and the other is to fix the bug caused by the function in the sprint, the third is to fix bugs generated in the previous sprint. Therefore, in this case, if you evaluate the completion of a sprint from the perspective of function completion, you should evaluate the previous sprint each time instead of the previous sprint.

 

For the completion of the sprint, I think each company should be different based on the Development Volume and test volume, but one thing is certainly the same, that is, every sprint must come up with a product that can work, and there must be actual increments. Many companies now use scrum in name, but this sprint often fails to complete several functions. The Sprint does not fix several bugs. What will happen at the end of the project?

First, we do not know the actual situation of this product, because it seems that all functions have been done, but many serious bugs have not been fixed;

Second, there is no basis for the quality of the product, because many bugs that should be repaired earlier have not been repaired. If you fix them later, you do not know if they will affect other functions, we know that if a bug is not fixed in the early stage, the cost of fixing it will be higher and higher in the later stage, because the product is stable in the early stage and may not have many functions, A bug you fixed will not affect other functions, but more and more functions will be available in the future. If the function of this bug is closely related to other functions, fixing this bug will very likely affect other functions, in this way, the investment time and cost for testing will be very large, perhaps several times the initial time.

Therefore, we recommend that the functions and bug fixes of each sprint not be dragged too long. A sprint can be dragged at most, and it cannot be dragged back until the end of the sprint, otherwise, it would not be agile, because too much testing power and bug fixing power will be invested in the future, which is no different from the waterfall model.