An overview of Agile development

Agile Development Overview:

The Agile development mode is a kind of new software development method which has aroused wide attention gradually from the 1990 's, and is a kind of software development ability to deal with the fast changing demand. Their specific names, concepts, processes, terminology are different, compared to "non-agile", more emphasis on the programmer team and business experts close collaboration, face-to-head communication (think more effective than written documents), frequent delivery of new software releases, compact and self-organizing team, Code writing and team organization methods that can adapt well to changes in demand, but also focus on the human role of software development.

Agile Development Roadmap:

　Test-driven development, test-driven development.

It is the most important part of agile development. In ThoughtWorks, we implement any function from the beginning of the test, the business needs of the first analysis, broken down into a 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 does one integration do? 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 uses the product CruiseControl developed by ourselves.

　　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 are you 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.

Principles of Agile Development:

1. Advocating simple

2. Embrace change

3. Your second goal is a sustainable

4. Incremental changes

5. Maximizing Stakeholder investment

6. Purposeful modelling

7. Multiple Models

8. High-quality work

9. Quick Feedback

10. The software is your goal

11. Move Lightly

Agile development compared to other methods:

Agile methods are sometimes mistaken for a non-planned and disciplined approach, and it is actually more accurate to say that agile methods emphasize adaptability rather than predictability. Adaptive approaches focus on adapting to real-world changes quickly. When the needs of the project change, the team should adapt quickly. It may be difficult for the team to describe exactly how the future will change.

Contrast iterative approach

Compared to iterative development, both emphasize the submission of software in a shorter development cycle, the cycle of agile development may be shorter, and more emphasis is placed on a high degree of collaboration in the team.

Contrast waterfall-style development

There is not much in common, waterfall model is the most typical predictive method, strictly follow the pre-planned requirements, analysis, design, coding, testing sequence of steps. Step results as a measure of progress, such as requirements specifications, design documentation, test plans, code reviews, and so on. The main problem with the waterfall is that its strict grading leads to reduced degrees of freedom, and the early commitment of the project makes it difficult to adapt to changes in late requirements and is costly. Waterfall methods are not feasible in situations where the requirements are unclear and may change during the course of the project. In contrast, the agile approach accomplishes relatively small functionality over a period of weeks or months, emphasizing the ability to deliver as little as possible as early as possible, and to continually improve and enhance throughout the project lifecycle. One might use a waterfall approach in each iteration of such a small scale, and others might choose to work in parallel.

Overview of Agile development