On the idea of gradually practicing agile development-agile development

Because of the organization of a new research and development team, and probably the team will be young people mainly, fresh graduates especially large.

I think it's a good time to try out a new development model, but of course it needs a smooth transition. First of all, we do not have the experience of agile development, and secondly, all the concepts of agile development may not be fully suited to the team, need dynamic to find the point of integration.

1. Simple Design and reconstruction

First of all, we need to establish a more rigorous concept of engineering, I appreciate the principle of "simple design", but I do not fully agree.

The system has just begun the entire architecture should be carefully designed, and after each module of the detailed design should be often brave to restructure, often have new ideas. And the implementation of refactoring is also to be carried out without affecting the software delivery of the premise.

The final summary is: the degree of iteration.

2. Automated Testing

Second, automated testing also needs to be gradually popular, especially the core functional modules, but on how to build testable code, this is a very deep knowledge to drill, I will be in the next time to practice this personally. The main questions I have now are:

Test cases to what level, if the functional modules require a number of module integration or database Special environment support, how to write test scripts. This is particularly expensive for scripting.

3. Continuous integration

This is based on the maturity of the automated test, and I think I have no say in this at the moment. Of course, I would also like to study carefully, but I think for a long time, small team, project or do not use to achieve continuous integration.

4. Code is public

In agile development, this is not a version of the library permissions so simple, but a person must be familiar with the entire project, or the whole project code style and design highly unified, I think the team members are not first-class one, and the project code is larger, the implementation of more difficult.

5. Pair programming

I've always thought that core modules can be programmed using pairing. The premise is to be able to well estimate the workload, the timing qualitative assignment. But the common job is not to use the pairing.

6. Regular meetings

Refactoring experience exchange, agile development experience exchange, automated Test experience exchange, need to be separated from the business layer in each regular meeting, to in-depth discussion of our entire team development model.

7. QA Team

The testers were less involved in the research and development period, and the QA staff were only responsible for the final functional acceptance of the project. Make sure that the QA team and the research team live in harmony and that there is no "hostile" relationship so that there is no buck of bugs.