Introduction to Agile development

These two circles represent a different perspective of agile practices, including the developer perspective and project management perspective. Next from the inside out, because some of the practice I do not know clearly, if there are some of the following is not the right place also please point out.

Test-driven development, test-driven development, is the most important part of agile development. At thoughtWorks, we implement any function that starts with testing, first analyzing the business needs and breaking it down into a single story, recorded on the story card. Then two people sat in front of the computer at the same time, a person according to the story, from the point of view of business needs to write test code, another person looking at him and thinking, if there are different opinions will be proposed to discuss, until the consensus, so that the written test code reflects the business function requirements. Then another person controls the keyboard and writes the implementation of the test code. If you do not have the test code, you cannot write the implementation code for the feature. Writing the test code first allows the developer to define the goal, which is to let the test pass.

Continuous integration, continuous integration. In the past software development process, integration is a very painful thing, usually a long time to do the integration, so that can cause a lot of problems, such as build failed or unit test failure. Continuous integration is advocated in agile development, integrated more than 10 or even dozens of times a day, so frequent integration minimizes conflicts due to the frequent integration and very few changes in integration, even if the integration fails to locate errors. What to do once integration. It includes at least: getting all the source code, compiling the source code, running all the tests, including unit tests, functional tests, verifying that the compilation and testing passed, and finally sending the report. Of course, there are other tasks, such as code Analysis, test coverage analysis, and so on. In our company, there is a volcano lamp on the developer's table that is used to sign the integrated state, if it is a yellow light, which means it is being integrated, and if it is green, the code obtained by the developer at this time is available and reliable, and if it is shown as a red light, be careful, the last time the integration failed, Need to locate the cause of failure as soon as possible to turn the light green. In continuous integration, our company is using its own products developed cruisecontrol

Refactoring, refactoring. I believe everyone is very familiar with it, there are a lot of books to introduce the reconstruction, the most famous is Martin's "reconstruction", Joshua "from the reconstruction to the model" and so on. Refactoring is to optimize the internal structure without changing the external behavior of the system, making the code as simple, graceful and extensible as possible. In the past development, usually in the need to come over, now the system architecture is not easy to implement, so as to reconstruct the original system, or in the development process, there is time left, the current code refactoring. But in agile development, refactoring runs through the entire development process, refactoring the code before each developer check in code to get the code to clean code that works. It is worth noting that at the time of refactoring, every change should be as small as possible, using unit tests to ensure that refactoring causes conflicts, and not just refactoring the implementation code, but refactoring it if there are duplicates in the test code.

Pair-programming, pair programming. In agile development, everything is pair, including analysis, writing tests, writing implementation code, or refactoring. Pair do a lot of good things, two people together to explore the spark is easy to produce ideas, it is not easy to embark on the road. In our company, there are a lot of things are pair to do, such as pair learning, pair translation, pair do ppt, about this topic, money students have a very famous article on it, named pair programming (pair programming).

Stand up, standing meeting. Every morning, all members of the project team stand up for a meeting, because they are standing, so the time is not very long, usually 15-20 minutes. The content of the meeting is not demand analysis, task allocation, etc., but everyone answers three questions: 1. What did you do yesterday? 2. What you are going to do today. 3. What difficulties have you encountered? Stand-up meetings let the team communicate, familiarize themselves with each other's work, and if someone has had a similar problem with you, then after the stand-up meeting, he will discuss with you.

Frequent releases, small version released. In the agile development, there will be no such situation, to get the demand after the closed doors, until the end of the product delivery to customers, but as much as possible to release products, generally in weeks, months as units. In this way, the customer will get the released product for trial at intervals, and we can get more feedback from the customer to improve the product. Because of the frequent release, the new features of each version are simple and do not require a complex design, so the document and design are largely simplified. Because of the simple design, there is no complex architecture, so customers have new needs or changes in demand, can quickly adapt.

Minimal documentation, fewer documents. In fact, agile development is not without documents, but there are a lot of documents, that is, testing. These test codes truly reflect the needs of the customer and the use of the system API, and if a newcomer joins the team, the quickest way to familiarize yourself with the project is to show him the test code, and be more efficient at debugging than while looking at the document. If you use a written document or note, the code changes over the day and you need to update the documents. Once you forget to update the document, there will be a mismatch between your code and the document, which can be confusing. And not in agile, because only the test changes, the code will change, the test is the real response code. Then someone will ask: code does not write comment line. Generally good code does not require a lot of comments. In fact, the simple readable code is good code, since it is simple to read, others can see at a glance, this time there is no need to comment on the code. If you think this code is not annotated, others may not understand, it means that the design is not simple enough, it needs to be reconstructed.

Collaborative focus, collaborating as the center, shows code sharing. In agile Development, code belongs to the team and not the code of the modules belong to WHO, everyone has the right to get any part of the system code and then modify it, if someone sees some code is not happy, then he can refactor this part of the code without the need to ask the author's consent, Probably don't know who wrote this part of the code. This way everyone is familiar with the code of the system, even if the team's personnel change, there is no risk.

Customer Engagement, on-site customers. In agile development, the customer is working with the development team, the team to the customer site to develop or invite customers to the team company to develop. If there is a problem with the development process, or the product after an iteration, can be the fastest speed to get customer feedback.

Automated testing, automated testing. In order to reduce labor or duplication of effort, all tests, including unit testing, functional testing, or integration testing, are automated, which puts higher demands on QA personnel. They are familiar with the development language, automated test tools, the ability to write automated test scripts or to record with tools. Our company has done a lot of work on automated testing, including selenium open source projects.

Adaptive planning, can adjust the plan. Agile development planning is adjustable, not as in the previous development process, requirements analysis--------design------development-----------------each stage is planned, and the next phase begins at the end of one phase. and agile Development has only one iteration, the release of small version, according to customer feedback at any time to make appropriate adjustments and changes.

The agile development process differs greatly from the traditional development process, in which the team is passionate and dynamic, able to adapt to larger changes, and to make better quality software.