Agile development process summary

Agile-agile developmentAs a new software development model introduced after the collapse of the CMM myth, it has been widely concerned over the past few years and has been highly expected. It is unknown whether agile development is ideal in other industries. However, the agile development experiment of my company is summarized below, hoping to gain a glimpse of it.

Agile Development declaration --
Individuals and interactions are better than processes and tools
Software that can work is better than comprehensive documents
Customer cooperation is better than contract negotiation
Responding to changes is better than following the plan
Although the right item also has value, we feel that the Left item has greater value.

The above declaration is more abstract than abstract. Based on this concept, the following are n agile development practices that thoughtswork consulting companies respect:
Iteration
Iterative development. Software that can work is better than comprehensive documents. Therefore, agile development advocates dividing a complete software version number into multiple iterations, each of which achieves different features. Major and high-priority features are implemented first, and features with high risks are implemented first. The software prototype was developed in the early stages of the project, and later iterations based on the prototype continued. Iterative development has the advantages of coding as soon as possible to expose the technical risks of the project as soon as possible. Enable customers to see executable software as soon as possible and provide optimization suggestions. The ability to deliver available version numbers to different customers in advance in stages.
Iterationplanningmeeting
Iteration plan meeting. When each iteration starts, the entire development team is called and an iteration plan meeting is held. all the team members speak freely, understand the iterative development tasks, and answer questions.
Story card/story wall/feature list
In each iteration, the architect is responsible for breaking all the features into multiple story cards. Each story can be considered as an independent feature. Each story should be able to complete development within a maximum of one week and deliver a pre-test ). After all the story in an iteration is developed, the testing group will perform a complete testing. During the entire testing process (pre-test, test), based on the daily build, the testing group will always take the latest compiled version number from the configuration library every day for testing, the developer can also change the problem ticket submitted by the Referer at any time and merge it into the configuration library.
One feature of agile development is open office and full communication, including the trial staff working with developers. Based on the story card development method, the team will place a whiteboard in the open office area, paste all the story cards on it, and paste them in the four areas according to the current development status, respectively: before development, development, pre-release, and release. Story card developers and auditors move the story card on the story Wall Based on the development progress to update the status of the story card. In this way, you can have a very intuitive understanding of the project development progress.
When a developer starts to develop a story, he/she needs to find the corresponding testing staff to explain the story function, so that the testing staff can have a consistent understanding, at the same time, start the development of your own active system trial script.
Standup MEETING
Standing Meeting. Every morning, all the team members hold an efficient meeting around story wall, usually within 15 minutes, reporting development progress and asking questions, however, it does not waste all people's time to solve the problem immediately, but will be resolved through communication after the meeting.
Pair Programming
Pair programming refers to the code of pairing two developers. The advantage of Pair programming is that the code written after discussion by two people is better than the code written by one person independently. Some big directions are not deviated, and some details can be fully taken into account. An experienced developer and a newbie Pair programming can promote the growth of newbie and ensure the quality of software development.
Ci/daily build
Continuous integration and strong daily building capabilities are an important foundation for successful iterative development. Built on a daily basis. The developer updates the written/modified code to the configuration library in a timely manner every day. The developer automatically compiles the program at least once a day and actively removes the code from the configuration library, execute your own static code check (such as pclint), Unit verification test, build version number, installation, system verification test, and dynamic check (such as purify ). After the preceding tasks are executed, a report is generated and you send an email to the team members. Assume that no matter what the problem exists, the responsible person should change it in time.
As you can see, the entire development group frequently updates the Code and some problems are inevitable. The trial is continuously based on the latest code. Whether new problems can be detected and eliminated in a timely manner depends on whether the active unit testing and system testing capabilities are strong enough, especially the active system testing capabilities. Assuming that you can only test the simplest operations, the hidden risks of new code integration will be very difficult to discover and leave behind the project to form a large risk. In fact, it is the most difficult to improve the coverage rate of your own active failover tests.
Retrospect
Summary and reflection. After each iteration, the project team members will hold a summary meeting to summarize the practices and lessons and implement them in the development of xingxu.
Showcase
Demo. After each story is developed, the developer calls the test taker to demonstrate the software functions so that the test taker can fully understand the software functions.
Refactoring
Rebuild. Since the iterative development model developed executable software prototypes early in the project, the code and architecture developed at the beginning cannot be optimal and comprehensive, therefore, in the probably story development, we need to continuously refactor the code and architecture. Iterative development has high requirements on architects. Because the architect wants to split a complete version number into multiple iterations, and each fall is split into a lot of story, from the perspective of architecture, these story must have a very strong inheritance, it is able to constantly overlay the code and architecture of early development, so it is inevitable that the story of development will overwrite the code and architecture of early development. At the same time, it is necessary to constantly rebuild and rebuild the code.
TDD
Test-driven development. As mentioned above, iterative development features frequent code integration and frequent release of version numbers. Pilot-driven development is an important means to ensure normal execution of the integrated code and will not be damaged in the future. The unit testing is used here.

Reflection on Agile Methods:
Self-developed agile development projects are not very successful in general, which may also be a common problem in the industry:
1. For the new software, the early project trial staff will renew and implement their own active trial scripts, but in fact the interface of the software is very unstable, as a result, the workload of the Trial staff is very heavy.
2. For all-new software, the data personnel will roll out early, and the rework workload will be heavy in the future. The reason is the same as the first one.
3. The workload of Self-Automation System failover is large, and the trial staff put a lot of energy into making the trial self-automation, there is not enough energy to focus on whether the functions of the real test software are normal. Even in this way, the trial script of the active system is mostly in the form of in-depth problems.
4. The Code Dynamic Check tool is not ideal for execution and is in the form. No one has a deep understanding of purify and application experience. Many alarms are found in the report, but I do not know how to eliminate them.
5. Due to the high-speed prototyping and no rigorous design on the architecture, code has been stacked in the future.
6. In the remote development mode, high-speed construction and delivery cannot be achieved, and the team is generally exhausted.
7. Agile development does not advocate overtime, but in fact, no matter which development mode is CMM or agile, it is not necessarily related to working overtime.