Planning, testing and refactoring of agile development

Objective

This series is a reading note from Robert C. Martin's agile Development Book, which outlines some of the basic principles of agile development, which are presented separately for the more important aspects of planning, testing, and refactoring.

First, the plan

　　1. Initial exploration

At the start of the project, developers and customers should try to identify the really important user footage and not try to find out all the user footage.

The developers work together to estimate the footage. Use "points" to indicate the relative time required to implement the footage.

Materials that are too large or too small are difficult to estimate.

As the project progresses, metrics for speed are becoming more accurate as you can measure the number of user footage that has been completed in each iteration.

　　2. Release plan

If you know the speed of development, customers will be able to understand the cost of each material.

For the first release, the customer picks up the footage they want to implement in this release and roughly determines the order in which the footage is implemented.

Because the development speed is not accurate at the beginning, so the selection is also sketchy. When the speed of development is accurate, the release plan can be adjusted again.

　　3. Iteration Plan

Developers and customers decide the iteration size, typically two weeks.

The order in which user footage is implemented during an iteration is determined by the technician. Once the iteration begins, the customer cannot update the footage during the iteration.

Even if you do not complete all the footage, the iteration ends at the specified date. Then estimate the current completed footage to calculate the development speed of this iteration.

　　4. Mission planning

With the help of the customer, the developer breaks down the footage into a development task, a task that a developer can implement within 4-16 hours.

Developers can sign any type of task.

Each developer is aware of the number of task points completed in the last iteration, which can be used as the personal budget for the next iteration.

The team will hold a meeting when the iteration is about halfway. Review and adjust development tasks.

　　5. Iteration

At the end of each iteration, the client is presented with a program that is currently running. Customers will provide feedback in the form of new footage.

　　6. Conclusion

Through iteration and release, the project has entered a predictable and comfortable development rhythm.

Developers see reasonable plans that are based on their own estimates and are controlled by the development speed they measure.

Managers get data from each iteration and use that data to control and manage the project.

Second, the test

Writing unit tests avoids a significant amount of feedback loops, especially for functional verification.

　　1. Test-driven Development methodology

It is recommended that you design your test plan before designing the program, with the following benefits:

A. Each function in the program is tested to verify the correctness of its operation, and this test suite can also provide support for future development.

B. Writing tests first can force us to look at the program that we are going to write from the vantage point of the program caller. Facilitates the design of easy-to-invoke software.

C. Easy-to-call and testable programs, must be low-coupling programs.

D. The test program is a compiled and operational document that remains up-to-date and does not lie.

　　2. Acceptance Test

Unit testing is a white-box test used to validate individual mechanisms in the system, and acceptance testing is a black-box test that validates the system to meet customer needs.

Acceptance testing is written by people who do not understand the internal mechanisms of the system. Generally written in scripting languages.

First write acceptance test, can make the system testability, need to at very high system architecture level to decouple the system.

Third, reconstruction

Each software module should have three responsibilities:

　　A. Complete the function that it should complete.

B. Be as simple as possible to cope with change.

C. Communicate with people who read it.

The process of modifying the code to improve the internal structure of the code without altering the external behavior of the code-called Refactoring.

Postscript

The plan belongs to the process management category, and needs to explore the way that suits you in practice.

The flexibility to apply the methods described in testing and refactoring helps us to produce projects that contain neat code and good architecture.

Planning, testing and refactoring of agile development