Agile development in combat

Introduction to Agile (Agile) development

Before starting this article, let's take a closer look at the Agile development content:
The first manifesto for Agile Development:
1. Individuals and interactions outweigh processes and tools
2. Work-ready software trumps all-encompassing documentation
3. Customer cooperation is better than contract negotiation
4. Responding to change is better than following plan

Take a look at some of the principles that agile development needs to follow:

• Our top priority is to make our customers happy by delivering valuable software early and consistently.
• Even in the late stages of development, it is welcome to change demand. Agile processes leverage change to create competitive advantage for customers.
• Regularly deliver software that can work, delivered at intervals from a few weeks to several months, and the shorter the time interval, the better.
• Throughout the development of the project, business people and developers must work together every day.
• Build projects around motivated individuals. Provide them with the environment and support they need, and trust them to get the job done.
• Within the team, the most effective and efficient way to deliver information is through face-to-head conversations.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development speed. Responsible people, developers and users should be able to maintain a long-term, constant development speed.
• Constant attention to excellent skills and good design will enhance agility.
  Simplicity is the most fundamental.
• The best architectures, requirements, and designs are for self-organizing teams.
• Every once in a while, the team will reflect on how to work more effectively, and then adjust their behavior accordingly.

So much content, Jianyan, compared to the standardization of CMMI Development, the advantages of agile development is rapid and change. As for the quality, customer satisfaction, and so on itself is the software development is indispensable requirements.

Actual project status

Although the agile development approach has some of the above advantages, the different software development methods apply to the actual situation of different projects. Even Martin Fowler, one of the founders of Agile, thinks:
New methods are not everywhere applicable. The agile approach is appropriate in the following situations:
-Uncertainty and volatility (volatile, meaning that today's requirements are not needed tomorrow).
-Responsible and motivated developers.
-Users can easily communicate and participate.
And in the actual project software development process, it is difficult to completely strictly in accordance with a certain software development method to carry out, Chairman Mao told us very early: do not "bookishness", to "theory with practice". Most of the project development process, according to the actual project situation, personnel situation, combined with a variety of development methods, the actual situation to do some adjustment of the method, but it is possible that a certain method in the main position.
The general situation of the project described in this article is as follows:
1. The project is a large enterprise application system based on a platform of two development (the system is mainly used for production, research and development, such as filling, process and control of related intelligence data)
2. The project is for the company's global users to use (more than 6000 users)
3. Although similar systems have been in the pipeline before, the reference is largely insignificant. Because the environment is changing and the demand is changing quickly. Users need to use the system quickly.
4. The development team has 2 needs analysts, 4 experienced developers and 2-3 testers
5. The team has been formed for about 6 years, although the ability and cooperation are good, but lack of enthusiasm and initiative to improve the momentum. Before the team development is basically the standardization process development mostly.
6. The user is very busy.
7. Development uses JIRA to perform task assignments.
8. System sub-module, phased on-line.

The actual project development process

Based on the above description, project delivery needs to be fast and varied, and looks more appropriate for agile development. In fact, it is also natural to use this development method, because if the standardization of the development process, will face a lot of problems. Slowly, the development process (for a module) is formed:
1. SA and the user to collect the requirements, with the user to confirm and communicate (PPT)
2. SA splits the user case and writes the specification (EXCEL)
3. SA explains the specifications to the AP and carries out task assignments, schedule planning, and scheduling of the demo prototype.
4. APs are developed and delivered in stages according to planning.
5. SA tests the features that are being developed.
6. SA and User demo, collect comments, distribute AP for modification
7. Steps 4 and 5 are repeated multiple times
8. All development completed, QA into the test
9. Test completed, the module is on-line

Problems encountered

Look at the above process carefully, it is easy to find two questions:
1. No SD work
2. Testing seems to be lacking

For the first question: no SD work
First, the time is tight, and then, the AP are more senior, so most of the SD work is omitted. But also because of this, led to a number of follow-up problems:
1. Insufficient development time estimate
SA always optimistic about the code, the function of the column linkage on a page, for SA, from the functional level may be very simple, but from the development level, the need to consider more, Either there are cross-browser compatibility considerations, or extended modifications to existing components, which consume far more than the SA estimate.
In addition, some of the interaction on the code level is the most clear to AP personnel, so the work of SD, some parts are necessary. And for this part of the work can not just open a task for an SD to complete, there should be a quick meeting, let the relevant SD together to storm. SD is also responsible for half of the time-to-time portion of the estimate.
2. Code reuse is not high, piling up serious. Structural confusion
SA is connected to the AP single-line, the AP developed the function SA to verify that the time course has the courage to lead the AP to the fastest speed to complete the development of features, what code style, code quality, code reuse, code maintenance all first put aside, first complete SA for the demo requirements. On the other hand, said here is the requirements of the demo, all of these features, it may be pushed off after the demo, so spend too much time to consider the part of the function outside the AP point of view, there are some gains, and slowly formed a pile of serious or even structural confusion.
The pursuit of speed can not lose quality, for specific situations, the use of different ways to ensure quality, can be a little more stable system to do some code reuse and code refactoring work, but necessary.

For the second question: Tests seem to be lacking
As you can see from the above process:
SA has a similar unit test, and the final phase of QA will be a sit-and-uat test.
In that case, the problem comes again.
1. SA is not adequately tested
Why should SA be tested? The reason is that the function changes quickly, each time the demo always have some changes, the big may be pushed to the back, if the QA came in early test, the first is the number of bugs will be many, and another is for the same function, QA may test to some immature version, wasting time. Thus, the SA is tested before stabilizing.
However, the SA test is coarse-grained because the function is SA out, so the SA does not need a reference specification for testing. The SA test felt that some changes would be made to the AP at any time, and the AP found that some improvements were also made with the SA acknowledgment for some modifications. In this process, the function of the system is always changing gradually, and SA is concerned about the function of a certain point, and SA basically does not do regression testing. Changes after the impact of the part how, no one knows, can only throw to the last round of QA.

1. QA testing is always urgent.
   QA is always in the final stage to enter the test, more, may be set aside 1 months, less then half a month. and QA Because enter the time late, to the function of the system does not know much, light familiarity will take a period of time. Familiar with the test is also stumbling. It is difficult to guarantee the completion of time.
   QA can intervene later in the test, but the time to intervene in the system should be earlier, participate in the SA and AP meetings, participate in the user demo session.

2. The quality of the test is not high, bugs flying all over the sky (really?) A fake? )
   The above also mentioned, the function of the changes will be many, but the specifications of the basic mountain is difficult to synchronize with the change, so that, QA into the test, according to the specifications to measure, there are bound to be a lot of problems. Some bugs, some of the specifications are not modified parts. In short, the result is a bug flying all over the sky, the average word a small function to produce two bugs.
   The AP takes the time to look, also to check with SA, and then with the QA instructions, some of the saved time is finally consumed.
   In addition, after frequent changes, there is time even SA himself to the specifications are not very clear. Even when the specification is to be confirmed, an SA will appear stating the status of the AP.

Lessons to learn

1. Later specifications and supplementary specifications and information
   Clear and correct specifications are essential, otherwise all of them have no basis. But the specifications can be improved later, such as: Before the QA start testing.
2. SD certain work is essential (time double Confirm level design)
   The so-called "first Seek and then move", there is no design action, often blind or do some repetitive work and useless. SD can be simplified, but some work cannot be eliminated, such as time and duration confirmation and overall design.
3. Regular collection requires improved partial and periodic refactoring
   System needs continuous improvement, any role, SA, SD, Ap,qa as long as the discovery system needs to improve the parts can be proposed, unified arrangements for improvement.
4. Regular code Review
   Self-discipline is a category of vocabulary, in different situations, the degree of self-discipline is different, the level of demand theory can be very good to explain this. Therefore, the definition of code Review is not only useful for improving the quality of the codes, but only for the problems found by the code Review itself.
5. Need to increase developer testing and unit testing
   Black box testing At the same time, appropriate to supplement some white-box testing, the best is the AP's own unit test written. Accurate and efficient.
6. Add parts of automated tests to standardize QA testing standards and processes.
   The speed of accelerated testing and the quality of the cue test should play a role in agile development.
   The ability to improve QA testing, to differentiate bugs, to classify bugs, to improve test flow and to interact with APS, is beneficial for accelerating development.
   In addition to this, import automated tests to do some repetitive test parts, reduce the QA burden, and speed up testing.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Agile development in combat