Introduction to agile development

I went to Xijiao University with my colleagues a few days ago to present a lecture on campus. Of course I was here to help. :-) HR and colleagues introduced a lot about the company, including culture, values, and agile development. I learned many things for the first time. Later, I told Ma that, I have gained a lot from your passionate agile introduction to the company. He encouraged me a lot by saying this.

Next, I will briefly introduce the explanations of Jack Ma. First, I will take a look at the figure below:

 

The two circles represent agile practices from different perspectives, including developer perspectives and project management perspectives. Next we will introduce it from the inside out, because I am not clear about some practices. If you have any mistakes, please point them out.

Test-driven development, test-driven development, is the most important part of agile development. InThoughtWorks, we implement any function from the test. First, we analyze the business requirements and break them into one story, which is recorded on the story card. Then two people sit in front of the computer at the same time, one person writes the test according to story from the perspective of business needsCodeAnother person looks at him and thinks about it. If he has different opinions, he will discuss it until a consensus is reached. In this way, the written test code truly reflects the business functional requirements. Then another person controls the keyboard to write the implementation of the test code. If no code is tested, you cannot write functional implementation code. First, write the test code to enable developers to clearly define the goal, that is, to pass the test.

Continuous integration. In the previous software development process, integration is a very painful task. It usually takes a long time to do integration. In this way, it will lead to many problems, for example, the build fails or the unit test fails. Continuous integration is promoted in Agile development. Integration is performed dozens or even dozens of times within a day. Such frequent integration can minimize conflicts. Due to frequent integration, there are few changes to each integration, even if the integration fails, it is easy to locate the error. What Should one integration do? It includes at least: Get allSource code; Compile the source code; run all tests, including unit tests and functional tests; check whether the compilation and testing are successful, and finally send a report. Of course, some other tasks will also be done, such as code analysis and test coverage analysis. In our company, there is a volcano lamp on the developer's desk to mark the state of integration. If it is a yellow light, it means integration is in progress; if it is a green light, it means the last integration passed, the Code obtained by developers at this time is available and reliable. If it is displayed as a red light, you should be careful. The previous integration failed, and you need to identify the cause of failure as soon as possible to turn the light green. In terms of continuous integration, our company uses its own product cruisecontrol.

Refactoring, refactoring. I believe everyone is familiar with it. There are many books to introduce refactoring. The most famous one is Martin's refactoring and Joshua's refactoring to pattern. Refactoring is to organize and optimize the internal structure without changing the external behavior of the system, so that the Code is as simple, elegant, and scalable as possible. In the past development, there was usually a demand, and the current system architecture was not easy to implement, thus restructuring the original system; or there was time remaining in the development process, refactor the current code. However, in Agile development, refactoring runs through the entire development process. Every time a developer checks in code, it is necessary to refactor the written code so that the code can reach clean code that works. It is worth noting that during refactoring, every change should be as small as possible, and unit tests should be used to ensure whether the refactoring conflicts, and not just to refactor the implementation code, if there are duplicates in the test code, you also need to refactor it.

Pair-programming, Pair programming. In Agile development, everything is done by pair, including analysis, writing tests, writing implementation code or refactoring. Pair has many advantages in doing things. It is easy for two people to explore together, and it is not easy to get on the wrong path. In our company, there are still a lot of things to do with pair, such as pair learning, pair translation, and pair PPT. Regarding this topic, Qian has a very famous articleArticleIntroduce it, called Pair Programming (Pair programming ).

Stand up, standing meeting. Every morning, all members of the project team will be standing for a meeting. Because the meeting is standing, it will not take a long time, generally 15-20 minutes. The content of the meeting is not demand analysis, task allocation, etc., but that everyone answers three questions: 1. What did you do yesterday? 2. What are you going to do today? 3. What difficulties have you encountered? The standing meeting allows the team to communicate and get familiar with each other's work content. If someone has encountered a problem similar to you, they will discuss it with you after the Standing Meeting.

Frequent releases, minor version released. This is not the case in Agile development. After receiving the requirement, we will close our doors and deliver the product to the customer. Instead, we will release as many products as possible, generally in weeks and months. 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 complicated design, so that documents and design are simplified to a great extent. Because of its simple design and no complex architecture, the customer can quickly adapt to new demands or demands.

Minimal documentation, a small number of documents. In fact, in Agile development, there is not no document, but a large number of documents, that is, testing. These test codes reflect the customer's requirements and system API usage. If a new person joins the team, the fastest way to get familiar with the project is to show him the test code, it is more efficient than debugging while looking at the document. If you use written documents or annotations, the code changes one day and you need to update these documents. Once you forget to update the document, the Code does not match the document, which is even more confusing. But it does not appear in agility, because the code changes only when the test changes, and the test actually reflects the code. At this time, someone will ask: do I leave the comments line in the code? Generally, isn't a good code that requires a lot of comments? In fact, simple and readable code is good code. Since it is easy to read, others can understand it at a Glance. At this time, there is no need to comment on the code. If you think that this code is not annotated, it may not be understood by others, it indicates that the design is not simple enough and needs to be reconstructed.

Collaborative focus, centered on cooperation, shows code sharing. In Agile development, the code is owned by the team, not the code of which modules belong to and everyone has the right to get any part of the code of the system and modify it, if someone finds some code uncomfortable, he can refactor the code without the consent of the Code author, and probably does not know who wrote the code. In this way, everyone can be familiar with the system code, even if the team's staff changes, there is no risk.

Customer Engagement: on-site customer. In Agile development, the customer works with the development team. The team goes to the customer's site for development or invites the customer to the team's company for development. If any problem occurs during the development process or the product is iterated, the customer's feedback can be obtained as quickly as possible.

Automated Testing. To reduce manpower or repetitive work, all tests, including unit tests, functional tests, or integration tests, are automated, which puts higher requirements on QA personnel. They should be familiar with development languages, automated testing tools, and be able to write automated testing scripts or use tools to record them. Our company has done a lot of work in automated testing, including the selenium open-source project.

Adaptive planning, which can be adjusted. In Agile development, the plan is adjustable, not like in the previous development process, Requirement Analysis-> outline design-> detailed design-> development-> test-> delivery, each stage is planned, and the next stage begins at the end of a stage. In Agile development, there is only one iteration, and the release of minor versions can be adjusted and changed at any time based on customer feedback.

The agile development process is very different from the traditional development process. In this process, the team is passionate and energetic, able to adapt to larger changes, and make higher quality software.

Address: http://www.cnblogs.com/blusehuang/archive/2007/10/17/926802.html