6 Practical experiences in agile development

In large enterprises, it is often a mix of software development models, some with agile development, some with traditional waterfall or RUP (Unified software development process). Agile development, relative to the traditional software development model, is mainly aimed at the rapid change of demand, constantly optimize the management process, and finally launch high-quality software.

The original author Ulf Eriksson, one of the founders of an online problem-tracking software company, is a loyal fan of agile development and has been practicing agile development for many years. The following is a summary of the author's experiences based on his years of experience.

1. Quick iterations

for a large version of a half-yearly release, the requirements, development, and testing of a small version are much simpler and faster. Some companies publish only two or three versions a year, the release process is slow, they still use the waterfall development model, more serious is the Agile development model has misunderstood.  

is not likely to be released from 2 releases a year to one months for 2 releases. But for now, fast iterations have become the norm, and the key is to publish faster than the current version.  

Fast iterations can force teams to constantly optimize processes, improve productivity, and not waste time on unimportant things. If there are 6 months away from deadline, then the whole work rhythm must be leisurely. If you publish a version every month, it will be more efficient than before. If the release cycle is too long, the user needs cannot be identified as soon as possible, resulting in timely product improvements. &NBSP

2. Involve testers and developers in the requirements discussion

Requirements Discussions are most efficient in the form of discussion groups. Discussion groups, which need to include testers and developers, make it easier to define testable requirements, group requirements, and prioritize them.  

At the same time, this approach can also take advantage of the complementary nature of team members. The need for such certainty is often more efficient, more active and more participatory than the need to discuss the conference.  

When determining requirements, do not stare over the details. The demand report is too detailed, is a habit of not agile, but also waste everyone's time. Of course, you can't miss a good idea, but it's not too thin, because the demand will change very much when the project is actually implemented. &NBSP

3. Writing a testable requirements document

Start by using the user story method to write the requirements document. This approach allows us to focus on requirements rather than solutions and implementation techniques. Premature mention of a technology implementation reduces the need for attention.  

Planning business needs, you can use the "3W template", that is,:  who is (what) the above 3W actually describes who the stakeholders are, what they want, and why they have this need. Let's take an example to illustrate: 

Who (WHO)	What is it (what)	Why (why)
User	Want to use an application to transfer files between different servers	In order to store project data

To get closer to the "User story," We can rewrite it as:

Who (WHO)	What is it (what)	Why (why)
Consumer/user	Want to digitize the archive process	To enhance communication and improve sharing efficiency

Writing user stories in agile projects There is a common template: As a [user type], I want [requirements] for [reason]. In this case, as a user, I want to digitize the archive to improve communication and sharing efficiency.

In most cases, the need for content needs to be more substantial and detailed, and this step should be done later and not at first. The methods of user stories are sometimes criticized for being too brief and repetitive. Here we must understand: The requirements document is not prose or poetry, should be clear and concise description of user needs, the focus of the requirements of the document is also this, do not control the form of changeable or whether the content is repeated such problems.

4. Communicate more, minimize documentation

Communication is a common problem in any project. Good communication is a prerequisite for agile development. The longer you mix in a circle, the more you emphasize the importance of good and efficient communication.

The team wants to make sure that everyday communication is much better than email.

Agile Development encourages daily coordination meetings and brief meeting, and 5~7 people participate in meetings as much as possible within 10 minutes. When we meet, we'll go through what we finished yesterday, what we are going to do today, and what issues remain to be discussed. You can use the Burndown chart (burndown chart) to visualize the progress of your work. Each iteration of the time to open a planning meeting and review meetings, the general need for more time may be longer, such as half a day. The purpose of these meetings is to find gaps in work.

The review meeting is very important, the traditional development pattern tends to skip this link, causes some wrong practices to repeat unceasingly, the good practice cannot promote.

At the meeting, the original group can be scattered, so that the entire team involved in the project needs discussion and testing, so as to highlight the individual members, so that everyone more willing to participate.

5. Do the product prototype

It is recommended that you use sketches and models to clarify the user interface. Not everyone can understand a complex document, but everyone will look at the picture.

A common problem is that the new functionality of the software is inconsistent with what the user wants. To avoid this problem, it is possible to simulate real-world operations and to improve operational behavior that is difficult to understand and unclear during simulation operations.

6. Early consideration of testing

It is important to consider testing early in agile development. Traditional software development, test cases start writing late, which leads to late detection of problems in demand, making the cost of improvement too high. Start writing test cases earlier, and when the requirements are complete, the acceptable test cases are basically complete.

A common problem in agile development is that developers do not have sufficient regression testing of existing code libraries. The iteration cycle is short, from start to delivery is 4 weeks, which allows regression testing of the design, implementation, and underlying tests of an iteration.

After a series of iterations, you can supplement only one iteration for the test activity. This iteration can focus on system testing, integration with other systems, performance, and more. During the agile development process, too few test documents may be caused. If the iteration period is around 1 months, you may not need to ask for the test document too much, but make a good test strategy.

finally

It's possible that most companies or teams haven't started to try agile development yet, but can start with a little bit, such as opening brief meeting, adopting a more efficient management tool for project management, and so on. Finally, I hope that the above suggestions for the management of software development for everyone to bring help. (Compile/Wang Jianjin)

Http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques