Agile development actual combat

Agile (Agile) development Introduction

First look at the contents to approximately agile development before the start of Benpian:
First Agile manifesto:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Then look at, agile development principles to follow:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Even late in development, also welcomed the change in demand. Agile processes harness change to create competitive advantage for our customers.
• Frequent delivery of working software, the delivery interval from weeks to months, delivery time interval as short as possible.
• During the entire project development, business and developers must work together every day.
• Build projects around motivated individuals up. To provide them with the necessary environment and support, and trust them to get the job done.
• In a team, the most effect and efficiency of the method of conveying information rich, is face to face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development speed. Sponsors, developers, and users should be able to maintain a long-term, constant development speed.
• Continuous attention to technical excellence and good design enhances agility.
  Simple is the most fundamental.
• The best architectures, requirements and design for self-organizing teams.
• At regular intervals, the team will reflect on how to work more effectively, and accordingly adjust their behavior.

So much more content, Briefly about, with respect to the development of standardized CMMI, agile development and rapid changes in the advantage. As for quality, customer satisfaction, this in itself is essential for software development requirements.

The actual project status

Although Agile development methods have some of the above advantages, but different software development method is suitable for the actual situation of different projects. Even Martin Fowler, co-founder of Agile also said:
The new method is not applicable everywhere. In the following, the method suitable for Agile:

• Demand uncertainty and volatile (Volatile, means today's requirements do not need tomorrow) occasions.
• Responsible and positive developers.
• Users can easily communicate and participate.
  And in the actual process of software development projects is difficult to completely strict accordance with a certain approach to software development, made it clear very early on told us: Do not "book worship" to "theory with practice." Most of the project development process, are based on the actual situation of the project, personnel situation, combined with the development of a variety of methods, some of the ways to make adjustments on the actual situation, but there may be some way in the main position.
  Project general situation of this introduction is as follows:

1. Project is a large-scale enterprise applications based on the secondary development of a platform (system is mainly used for production, research and development, such as filling orders, processes, and data were related intellectual control)
2. The project company is to give users worldwide to use (more than 6000 users)
3. Although a similar system before doing control, but basically reference of little significance. Because the environment is changing and changing needs quickly. Users need to use the system quickly.
4. The development team needs two analysts, four experienced developers and 2-3 testers
5. Team building about six years, although everyone capabilities and cooperation are good, but the lack of passion and initiative to improve power. Before the team developed largely standardized process development majority.
6. Users are busy.
7. Developed using JIRA to task assignment.
8. Sub-module system, on-line stages.

Actual project development process

Based on the above described situation, the project needs to deliver fast, more change, looks more suitable for Agile development. In fact, the practice is a natural development on the use of this method, because if we standardize the development process will face many problems. Slowly the formation of such a development process (for some modules):

1. SA and the user needs to collect, confirm and communication (PPT) and user
2. SA Split User Case, and writing specifications (Excel)
3. AP SA to explain specifications and task assignment, the time course of planning and needs Demo Prototype arrangements.
4. AP was developed according to plan, phased delivery.
5. SA on the development of functional testing.
6. SA and conduct User Demo, gather opinions, distribute modified AP
7. Step 4 and 5 will be repeated several times
8. All developed, QA into the test
9. The test is completed, the on-line module

Problems encountered

A closer look at the above processes, it is easy to find two problems:

1. SD did not work
2. Test looks do have a lack of

For the first question: no SD work
first of all, time is tight, then there, AP are more senior, so most of the work of SD have been omitted. But also because it led to some follow-up questions:

1. Development time underestimated
   SA estimates Always always optimistic code on a page column linkage function, for SA, the functional level, perhaps from the very simple, but from the development perspective, but more needs to be considered part of the and more, or there is a cross-browser compatibility considerations; or modification of existing components expanded; on this time consuming far more than the estimated SA.
   In addition, some interaction on the code level is most clearly AP staff, so SD work, some parts are essential. And for this part of the work can not just open a Task to carry out a complete SD, should have such a quick meeting, so that the relevant SD together to storm it. For the estimated time and part time course, SD is to bear half the responsibility.
2. Code reuse is not high, pile serious. Structure confusion
   SA AP-way contact with, AP SA developed to verify functionality, there is a time course very dare, resulting in AP fastest to complete the development function, what style of code, code quality, code reuse, maintainability of code all first put aside, SA to complete the requirements for Demo. On the other hand, it is said here Demo requirements, all of these features, it is possible after the Demo will be turned down again, so I spent too much time to think outside part of the function of the angle AP seems, indeed there are some more harm than good, it slowly formed a pile structure even serious confusion.
   The pursuit of speed can not lose quality, for a particular case, you can use different ways to ensure the quality, we can do some code reuse and refactoring work in a slightly stable system some time, but essential.

For the second question: do the test appears to have a lack of
it can be seen from the above process:
SA has done a similar unit testing, QA final stage of the SIT and UAT will do combined testing.
In this case, the problem again

1. SA test is not sufficient
   SA Why test? The reason is that functional changes quickly, every time the Demo there are always some changes may have to push to large again, if QA test to come in early, the first is the number of Bug will be a lot, and then one for the same function, QA testing may be some immature version, a waste of time. Thus, before stabilizing SA to be tested.
   But the test SA is coarse-grained, because the function is SA open up, so do the test SA without reference to specifications. SA test think there are some changes will be modified at any time to find the AP, AP found that some improvements are part of the SA also confirmed to make some changes. In this process, the function of the system is always in the gradual changing, and SA concerned only a point function, and basically SA will not do regression testing. How to change after the affected part, no one knows, you can only throw the final round of QA.

2. QA testing is always an emergency.
   QA always before entering the final stages of testing, and more, it may set aside a month's time, less then half of it. The QA since entering late, do not know much of the functionality of the system, the light will have to spend some time familiar. After the test is familiar stumbling. Difficult to ensure completion on time.
   QA test can intervene in late, but time should be earlier intervention system, participation in meetings SA with the AP, participation in meetings of User demo.

3. Testing is not high quality, bug flying (really? Fake?)
   Above mentioned, the function will change a lot, but the basic specifications of the mountain is difficult to synchronize the changes, this is the case, QA into the test case, according to specifications measure, is bound to be a lot of problems. Some part of the Bug, and some specifications unmodified. In short, the result is sky flying bug, on average, then a function produces two small bug.
   AP takes the time to look, but also with the SA check, and then with the QA instructions, save some time finally takes off.
   In addition, the frequent changes of time even SA own specifications are not very clear. To confirm the specifications even when the AP to explain the situation to SA will appear.

Lessons learned

1. Late required specifications and supplementary specifications and information
   clear and correct specifications is essential, otherwise there is no basis of all of them. But the complete specifications can put some of late, such as: QA placed prior to starting the test.
2. SD certain essential work (a general design of Double Confirm time)
   so-called "first plan and then move" action not designed, often blindly repeating or doing some work and wasted effort. SD can be simplified, but some of the work can not be removed, as well as time and schedules to confirm the overall design.
3. regular collection needs to be improved and regular part of the reconstruction
   system requires continuous improvement, any role, SA, SD, AP, QA found that as long as there is a need to improve the system part can be put forward, the unified arrangement to improve.
4. Code Review regularly
   self-discipline is a lexical category, under different conditions, different levels of self-discipline, a good level of demand theory can explain this. Therefore, the definition of the Code Review of Problems and improve the quality of the code in the Code Review useful not only found on the meeting itself.
5. The need to increase and unit tests developers of
   black box testing at the same time, appropriate to add some white-box testing, AP is the best I have written unit tests. Accurate and efficient.
6. Increasing portion automated testing, QA testing standards specifications and procedures.
   Speed accelerated testing, quality testing in Agile development tips should play some role in this.
   The ability to enhance the QA testing, bug's ability to distinguish, categorize bug, improve testing processes interact with the AP, to accelerate the development is not without benefits.
   In addition, import automated testing to do some duplicate test section, reduce the QA burden, speed up testing.