• Agile development is the current process of development, through version iteration can quickly update and upgrade the product, today I will talk about agile.

    •  My experience in agile development
      • Traditional development model
      • Potholes in traditional mode
    • What is an Agile development process?
      • Agile development concepts
      • The agile manifesto
    • What are the Agile development methods?
      • What is Scrum?
    • What are the aspects of an agile development process?
      • Requirements clarification Session
      • Project analysis meeting
      • Will stand
      • Judges,
      • Review will be
    • How do projects start using Agile development?
      • Rapid iteration
      • Involve testers and developers in requirements discussions
      • Communicate and minimize documentation
      • Prototype your product
      • How do you assess if your team is agile?

Agile development can be described as a standardized process of rapid iteration of products. I mean fast and flexible? Not so. In fact, agile development is centered on the evolution of user needs, adopting a fast iterative and step-by-step approach to the development of software products.

In agile development, a software project is subdivided into multiple sub-projects (stories) during construction, and the results of each sub-project (stories) are tested, independent, can operate independently, and can be combined into a whole.

In this regard, agile development has many advantages over normal development.

In this Chat, the following will be covered:

  1. What is an Agile development process?
  2. What are the Agile development methods?
  3. What are the aspects of an agile development process?
  4. How do projects start using Agile development?
  5. How do you assess if your team is agile?

My experience in agile development

First of all, I would like to talk about my experience in contacting agile development. During my working period from 2010 to 2015, several companies were engaged in mobile Internet products. At that time, I had not contacted the concept of Agile development and still used the traditional development mode.

Traditional development model

Here I’ll briefly talk about the traditional development model and the pitfalls of the one I used.

Traditional development models include:

  • Traditional waterfall development
  • Prototype model
  • The spiral model

For those of you who are confused by the above three traditional development patterns, what are they?

Here we introduce one by one, I believe you can understand more specifically, and know what you deep development mode.

1. Traditional waterfall development model

The process is as follows:

From requirements to design -> Design to code -> Code to test -> Test to delivery

This process, presumably, requires the best at every stage of development. Especially in the early stages, the better the design, the less cost will be lost after submission. This is the typical waterfall model.

Waterfall is the most predictable approach, strictly following a pre-planned sequence of requirements, analysis, design, coding, and testing.

Step outcomes serve as a measure of progress, such as requirements specifications, design documents, test plans, code reviews, and so on.

The main problem with waterfall flow is that it reduces freedom due to its strict classification. Commitments are made early in the project, making it difficult and costly to adjust to changes in requirements later.

The waterfall approach is generally not feasible in situations where requirements are unclear and can change over the course of a project.

It is estimated to be responsible for 70% of software development failures.

What causes the project to fail?

  1. The demand is not clear in the early period and changes greatly in the later period
  2. Developed features are inconsistent with what the customer expected
  3. Only when the project is well done can there be a demo version (the normal use of the version cannot be guaranteed during development)
  4. Project schedule cannot be guaranteed

I believe 90% of you have experienced the above, and some of you are still suffering from it.

2. Prototype model

Prototype model is the first step is to create a rapid prototype, can satisfy the stakeholders and future users can interact with the prototype, again through the full discussion and analysis with the related stakeholders, finally find out the current system requirements, after fully understanding on the basis of the prototype developed user satisfied products.

The so-called prototype model: to put it bluntly, there needs to be a prototype effect, which can be some modeling graphics, or a simple static interface effect flow developed quickly, or some rapid creation of prototype images.

For example, with the support provided by some open source platforms, we can make some prototype diagrams of requirements process, show the requirements of the required project through the prototype diagram, and present the product process through the prototype diagram.

Here’s an open source platform for creating prototypes for different platforms (mobile, Web, etc.).

www.xiaopiu.com/

I can show the benefits of this platform to my friends through an effect. Here I only show the prototype effect of the mobile terminal. Of course, other friends can see and learn by themselves.

3. Spiral model

The spiral model is a combination of waterfall and rapid prototyping with a strong emphasis on project risk.

It is usually divided into four stages:

  • Make a plan
  • Risk analysis
  • Implementation of the project
  • The customer evaluation

In general, the first version of the prototype is only a reference for communication between the two sides, and as the later version is added and improved, the final goal is reached. This kind of spiral model development is more suitable for large projects.

Potholes in traditional mode

All right, so much for the drawbacks of the traditional development model, which was used before Agile management, and of course has a lot of pitfalls.

I was mainly is to use the waterfall flow pattern in the development, each time to get a new project, it’s almost impossible to understand the project’s overall process and usage scenarios, the first thing to do is to analyze requirements, analysis and understand the requirements document, can try development capabilities, why a try, because even when we through the document to also do not understand is the same as customer want. There were no more meetings, no formal requirements validation meetings.

For example, is a customer demand to communicate with the project manager, so the understanding of the project manager may have certain deviation and customer understanding, but demand is so much, not the specific details, we can’t for every detail and customer face-to-face communication, this will lead to, development has been in accordance with the documents stated in the development of, However, it was not until the completion of the project that I found that the result was different from the customer’s expectation.

You can imagine how low the odds are for a project like this.

Here’s a typical example:

I remember that when I was working on an e-commerce project, it was quite difficult to develop it in the early stage, because the demand was not clear, and I often had meetings with the customer to discuss and confirm the demand. Every time, the customer would orally express their expected functions and effects. However, after several meetings, I found that the customer did not accept what was said in the last meeting, for example: Last time they clearly said that a demand point should be made 1, but this time they said it should be made 2, because there was no clear demand, so they could not debate with the customer too much.

Finally, in order to avoid the occurrence of such things, we considered taking minutes of the meeting, confirmed one by one with the customers in the meeting, and then sent all emails to the relevant personnel after the meeting, which also reduced the occurrence of such things to a certain extent.

It’s not hard to imagine that this kind of development is blind and inevitable, so I’ve done very few successful projects over the years, and even the small successes have taken several times as long as expected.

Because of these drawbacks and flaws, some of them fatal, something new has emerged: the agile development process.

In this situation I began to understand the process of agile development.

When I was at the time of agile development domestic haven’t a few understanding and implementation of agile processes (at least I haven’t heard of a), the company also is very bullish on the block, think it is a blank area, of course, it is a big adjustment, because there is no reference, no comparison, given there in domestic enterprises, So I think I can refer to the agile ideas of some foreign enterprises and some agile materials to make an agile process platform of my own.

To get started with agile processes, we thought of two things to start with:

  1. How to deal with problems efficiently
  2. How to organize effective meetings

Why do we start from these two aspects? This is also based on the current situation of our company at that time.

Problem 1 is that when there are problems in the project, no one takes the initiative to deal with them and track them. As a result, some problems are not discovered until the publication of the book or the project is launched.

Story: Remember very clearly, we do a video player, in fact there are already some resources in development fail to load problem, don’t play, but the developers and testers are considered to be the company network problems, ideally think other network can play, no mind, nor do any record, As a result, many similar video resources could not be played when it was launched, which caused customers to lose confidence in our products.

Although it was finally found that the customer provided the video resource conversion problem, it also reflected our problems. No one was found to deal with and track the problems during product development and testing, which also led to the customer’s greatly discount to our development ability.

Problem 2. Another problem is that there are few organized meetings. There are few regular project requirements discussion meetings, and even when they are held, there are few speakers.

This situation directly affects the communication between colleagues in the company, because there is no communication in meetings, and they rarely communicate with each other. Sometimes, colleagues with problems track the problem, and it is not smooth when discussing with other colleagues, and words like “I did not do this, I did not know” appear from time to time.

After doing these two parts at that time, I found that my work efficiency improved a lot.

We asked the company’s developers and testers to ask two or three questions a day, all under their own name, and to track them until they were done.

This will improve the efficiency of problem solving. At this time, we will find that everyone will start to care about their own problems and take the initiative to deal with them.

We also require a weekly meeting and a daily stand-up meeting.

The weekly meeting is to talk about our work during the week, the overall situation (e.g., which project was published this week, and what is the next step?). Of course, these aren’t debriefs, they’re updates on our work, which is important, because it’s so easy for companies to turn meetings into debriefs that they don’t make any sense.

Stand-up meetings, we were talking about two things:

  1. What was accomplished yesterday?
  2. What are you doing today?

In fact, some of you might say, isn’t that what standing meetings are about in Agile these days?

Actually, no, we only did these two things at that time. As for the problems, we still held separate meetings to discuss them. The meetings were very short, mainly for everyone to talk about their work progress and situation, and let team members know the progress of the project.

Meeting presided over the host of the we take everyone for a week, presided over a week, not only have to get ready for a meeting in advance equipment and facilities, but also good presided over the meeting, such as when the meeting was interrupted by other issues, the host must stop in time, can record the problem, to help them organize another meeting, or let them organize a meeting to discuss separately.

After about three months, I found that the communication between the team was much smoother. Before, every meeting was silent, but now everyone would express their own opinions and ideas.

Everyone’s ability to organize meetings has also been significantly improved. When encountering problems, they will timely pull up meetings to communicate with each other.

Through these two points, I also discovered the benefits and prospects of Agile, and started to start the agile development process as a whole and systematically, from user stories, iterations… Up to now the control of the finishing process.

The above mentioned my experience, why the use of Agile and what problems I solved in the enterprise at that time, there may be many partners have similar problems, let’s focus on the following.

What is an Agile development process?

Agile development concepts

Agile software development, also known as agile development, is a kind of new software development methods gradually attracted wide attention from the 1990s, is a kind of software development ability to cope with the rapid change of demand. Their name, terminology, don’t do the same, ideas, process, relative to the “agile”, more emphasis on the programmer team work closely with business experts, face-to-face communication is more effective than a written document), frequent delivery of a new software version, compact and self organization’s team, is able to adapt to the demand change of coding and team organization method, It also focuses more on the human role in software development.

To put it simply, agile development is a human-centered, iterative, step-by-step development method. In agile development, the construction of a software project is divided into multiple sub-projects, each sub-project is divided into multiple user stories, and the results of each sub-project are tested, integrated and runnable (that is, daily or iteration versions are runnable and ready to publish).

In other words, a large project is broken up into smaller projects that are connected, but also run independently, and completed separately, with the software always in a usable state.

Agile is characterized by iterative development.

Learn about the agile development phase by:

The agile manifesto

In February 2001, the Agile Manifesto was published and the Agile Alliance was formed. The values expressed in the Agile Manifesto fall into four categories:

  • Individuality and interaction over processes and tools
  • Working software trumps detailed documentation
  • Customer cooperation trumps contract negotiation
  • Response changes are higher than compliance plans

What are the Agile development methods?

Like any other project management approach, agile development has a certain approach.

Much has been said about agile, which is actually a guiding ideology, or a way of development, but it does not tell us exactly what kind of process to use for development, let alone how to do agile development process.

Agile management has its own process approach, and Scrum and XP are specific approaches to agile development. We can either adopt Scrum approach or adopt XP approach.

So what’s the difference between these two approaches?

  • Scrum is process-oriented
  • XP is more hands-on

There are two approaches, one is process oriented and one is practice oriented, but in practice, the combination of the two is the best approach. Of course, we will only talk about the preference here, and we will focus on Scrum.

What is Scrum?

Scrum is an agile development framework process pattern, an incremental, iterative development process. Usually used in agile software development.

The original word Scrum comes from a technical term in rugby. Before every sprint in a football game. There will be a scheduled process, but once the sprint starts the team will be randomly assigned based on the original plan.

The passing process requires careful cooperation, unity of belief and clear goal of all members.

This process embodies all the requirements of an efficient and cooperative team.

At the end of the day, agile development is like a crazy football game.

Scrum components:

  1. A development process
  2. Several roles
  3. A set of normative implementation methods

In Scrum, Product requirements are Product Backlogs. All product requirement lists start with a simple idea and are refined (simple to complex) into multiple storylines, each of which is a separate module that can be developed.

Scrum breaks the development process into sprints, each of which represents a two – to four-week development cycle with a fixed length of time.

Scrum Agile Flowchart

What are the aspects of an agile development process?

Above, I talked about Scrum and the concept of Scrum as well as the agile flow chart. So what do we need to do to achieve an agile development process?

To use or practice Agile development, you need to start with 5 meetings. If you have fully mastered these 5 meetings, you can truly master Scrum agile development.

There are three roles in Scrum: PO (Product Owner), Scrum Master, and project member.

Product managers typically start prototyping and writing requirements documentation after requirements analysis and identification. However, in Scrum development mode, there is no need to write too many requirements documents, we will reflect all ideas in the prototype, must be accompanied by corresponding notes, if the developer has any questions in the development can communicate face to face.

This is one of the key points of Scrum: communicate more, and replace documentation with communication. It can be done with less documentation, but not without communication.

If they start out with a prototype, or a prototyping process, they don’t even know how to get started. What’s the solution?

In order for the project leader to work more effectively and the team to work more harmoniously, this leads to the next five Scrum sessions:

  • Requirements clarification Session
  • Project analysis meeting
  • Will stand
  • Judges,
  • Review will be

Here are some examples of each of these meetings. Grab a bench and listen.

Requirements clarification Session

A requirements clarification meeting is a requirement clarification meeting. Some of you may ask, isn’t there a prototype? Just talk about the process. What else is there to clarify? Of course not, clarifying meetings needs to be clarified in the form of “user stories”.

Expressions like:

If I am a user of this product, what functions do I implement and what do I need to do? What’s best for the user.

The feature description might be “what do I want as a user or as an experiencer?” rather than “how do I click on that action?”

To put it simply, the user story can be represented in many ways, and each person’s interpretation will lead to incorrect implementation. At this time, it is necessary to communicate. Only when the project team has determined that such a thing should be done, can it be considered as a requirement without problems.

For a project, almost every project needs to be subdivided into user stories, which can be prioritized and then divided into several iterations based on priority.

Ensure that the cycle of each iteration is very short, usually two or three weeks, and the iteration must be a usable product, may have some functional defects, but it must be a normal use of the product.

Clarification meetings require participation, functional communication and discussion of uncontested requirements. Be sure to reach a consensus.

Clarifying the meeting requires the project manager or project leader to know the meeting is going on, to first explain the general requirements, and then to divide and discuss.

Project analysis meeting

The plan analysis meeting is to subdivide the prototype and user story into tasks based on the results of the clarification meeting in the previous step.

This meeting is usually chaired by the project manager or project leader.

Before this meeting, the developers also know what kind of product they need to develop, so they can divide tasks into prototypes based on each user story.

Of course, these tasks are usually assigned by development, and time is also evaluated by development. We usually take one or more story lines and schedule and divide them according to the agile version iteration.

Such as:

When the front-end development sees this page, it needs to show how many interfaces are connected with data, how many hours are needed for each interface, and how background personnel need to cooperate, which need to be clarified in this meeting. Therefore, for the normal follow-up development, this meeting will be a long process, about 3~4 hours. It is recommended that the development of the front and back ends be carried out separately, so that it is more targeted.

Of course, this meeting should be held in a harmonious and comfortable environment, and team members should not feel pressure or be too restrained. It is suggested that team members show the plan to everyone through TV or video projection, and gather together. Every member should speak and communicate enthusiastically. The most important aspect of non-violent communication is to evaluate your task in a realistic way, without taking words out of context or making any random evaluation.

Will stand

Standing meeting is a meeting that needs to be held every day. Each project member needs to speak in turn, and the content is as follows:

  • What was accomplished yesterday?
  • What needs to be done today?
  • Do you encounter problems that are difficult to advance?

Of course, it should be emphasized that this meeting is not a report meeting, so team members should not think that they are reporting work to the Leader psychologically. Standing meeting is mainly to synchronize their own work and let other team members know what you have done. They will adjust their work situation according to your work situation, and it is easy for the team leader to arrange other plans and work.

The main purpose of this meeting is to synchronize work and cooperate with each other in order to avoid work congestion.

Here’s a very simple example:

Zhang SAN and li si do function development, two fast has certain correlation function, at the time of development need to cooperate to, when zhang SAN have a problem, or planned changes, unable to complete their work, the iteration needs to let bill know and adjust in time, standup can do very well in time synchronization of these problems, avoid obstacles.

Judges,

The main purpose is to demonstrate and review the functions of this iteration, and review the user stories to see whether we have completed the content mentioned in these user stories.

Review meeting need team members to participate in, the best is all about leadership and the boss also take part in, the iterative function for each, after completion of demonstration, to do review for this version of the function, the best everyone speak, say oneself understanding and feelings, to make meeting minutes, finally made and confirmed the following results:

  • What needs to be adjusted
  • How to adjust
  • Adjustment takes time

Minutes need to be taken for the next iteration of optimization through the above points. Review meetings are part of an iterative update process.

Review will be

The review meeting is mainly to analyze the advantages and disadvantages of our team in this iteration, how to improve, and produce corresponding improvement measures.

The following statements can be made:

  • What went right
  • Things that didn’t go well
  • Any suggestions or comments
  • Something to be happy about
  • Something to reflect on

Recall that the main purpose of the conference was the Agile Manifesto:

  • Individuality and interaction over processes and tools
  • Working software trumps detailed documentation
  • Customer cooperation trumps contract negotiation
  • Response changes are higher than compliance plans

Retrospectives are about constantly improving the team and optimizing the workflow.

After the above five important meetings, partners should be able to make good use of these meetings, here I would like to talk about the preparation of these five meetings.

Environment:

  • Have a screen projector ready (preferably a TV)
  • Demo device (mobile phone used for demo, or software linking to computer, etc.)
  • Meeting panel (a removable sketchpad is best for recording key points in the meeting)

Plan:

  • Plan the content points for each meeting
  • Schedule time for each meeting
  • Plan who will lead each meeting
  • Plan who will participate each time

How do projects start using Agile development?

Agile management, people mainly focus on how to practice agile development process in the project, what specific work can be used for agile? Here are a few Pointers on how to use Agile.

Rapid iteration

The requirements, development, and testing of small releases are much easier and faster than the traditional development model, where large releases are made semi-annually or when the project is completed.

Some companies only release 3 or 4 releases a year, the whole process is slow and slow, and the traditional waterfall development model is still used, and these companies do not understand the benefits of agile development, and have misunderstood the benefits of agile development.

It is normal for these formula tasks to release 3-4 releases a year, but it is not possible to release only one release every two weeks.

But now that rapid iteration has become the de facto norm, the key is to ship faster than the current version.

Agile management is one of the ways to improve team effectiveness. To maximize team effectiveness, teams must be small and lean.

In agile development, sprints are set up to iterate on tasks at a sprint per week, which is more efficient and can be adjusted and optimized more quickly.

Involve testers and developers in requirements discussions

Needs discussions are most effective in the form of discussion groups.

Participants include testers and developers, making it easier to define testable requirements, group them, and prioritize them.

It also takes advantage of the complementary nature of team members. Such identified requirements are often more efficient, more active and more engaged than a meeting to discuss requirements.

Don’t focus on the details

When defining requirements, don’t get too bogged down in detail. Reporting requirements in too much detail is an unagile habit and a waste of time. Of course, don’t miss out on great ideas, but don’t go into too much detail, because requirements can change dramatically when the project actually gets off the ground.

There is a common template for writing user stories in agile projects:

As a [user type], I want [requirements] in order to [reasons].

Apply to this example: as a user, I want to digitize my archiving program to enhance communication and share more efficiently.

We can provide you with templates in Excel to update your needs.

Communicate and minimize documentation

Communication is a common problem in any project. Good communication is a prerequisite for agile development. Agile emphasizes the importance of good and effective communication.

Make sure the team communicates on a daily basis. Face-to-face communication is much better than email.

The daily stand-up meetings mentioned above are essential for communication, with several members of the team participating for 15 minutes each day.

Everyone says it in turn:

What was accomplished yesterday? What are you doing today? What issues remain to be discussed?

For some problems blocked in another meeting to discuss.

So the emphasis here on the five agile meetings is very important, communication is fundamental. Agile management advice is good at communication.

Prototype your product

Sketches and models are recommended to illustrate the user interface. Not everyone can understand a complex document, but everyone can read pictures.

Documentation can result in the inability to link a feature or storyline together. In order to avoid this problem, the real operation can be simulated to improve the hard to understand and unclear operation behavior during the simulation operation. This allows you to use the prototype action, which can be used as follows:

For example, there is an open source platform that allows you to create prototypes for different platforms.

www.xiaopiu.com/

How do you assess if your team is agile?

Agile development has no standard practice process to refer to, so it is difficult to determine whether a process is using Agile or not, so how to evaluate the team is agile?

Assess whether the team and its development process are agile based on the atmosphere presented by the team, the status of the project, and the perceptual awareness of the team members. Common methods to evaluate whether the project team is agile are as follows:

  • The team has a common goal, which of course is consistent with the company’s goal, and is full of confidence in this goal;
  • The team has a clear phase goal plan and is known to each member;
  • Team members know the current plan, what to do, when to complete, expected results, etc.
  • Team tasks are low-coupled and closely coordinated;

It’s important to see if each iteration release is smooth and enjoyable, and building and testing is part of the normal behavior.

Go from the basics to agile development.

Of course, agile is a process of slow practice and optimization, and we need to work together to do it well, otherwise everything is empty talk.

When we do anything individually, we will take the initiative to communicate. Instead of being passive, we can effectively improve our work efficiency. However, when everyone in a team takes the initiative to communicate, cooperate with each other, and take the initiative to assume responsibilities and tasks, it is the best embodiment of agility.

A journey of a thousand miles begins with a single step.

Ok, here’s that’s the end of the time about agile, the key is in the project practice of agile development process, to do their work of agile, and slowly and the team together to achieve agile, agile practice work, the next action by everybody, no action is all in vain, you can remember the agile manifesto, start from the part of the daily work, If some of you have questions, you want to know more about Agile, or you have problems, you can follow the public account “Programmer comics programming”, or you can add me to wechat for more in-depth discussion.

Original is not easy, useful on the “attention” once if helped you, to three even, thank you for your support.