Write at the top:
The agile development model is more suitable for project-based systems, and the waterfall development model is more suitable for product-based systems, with multiple iterations after design
The above is my personal understanding, different opinions are welcome to discuss together
When developing software, the first project implementation decision that is often faced is "which development methodology should we use?" This is a topic that generates much discussion (and heated debate). If you have not used this method before, a proper understanding of development methodology and theory is necessary; simply put, it is a method of organizing software development work. This has nothing to do with a style of project management or a specific technical approach, although you'll often hear the terms mixed up or used interchangeably. The two basic methods that are most popular are: waterfall development and agile development. Both methods are available, well-established methods.
Now, when it comes to Agile Model and Waterfall Model, many people think that agile development is the trend of project implementation in the future, and waterfall implementation is too old-fashioned and outdated. In addition, it is true that some multinational companies such as Sony and Lenovo are also using agile methods to implement some projects. But in fact, we see that the vast majority of companies are still implementing projects in a waterfall manner. This article mainly briefly introduces the differences and advantages and disadvantages of agile and waterfall.
Agile development and waterfall development
1. Waterfall model
The waterfall model is a method in which a project is decomposed into limited stages to develop software. Development should move to the next phase only when its previous phase has been reviewed and validated. In the waterfall model, the stages do not overlap. In this approach, the sequence of events is this:
- Requirements are collected and documented
- Design
- Code and unit testing
- System testing is performed
- User acceptance testing (UAT) is performed
- Any issues are resolved
- Finished product is delivered
From the perspective of the waterfall development model, it still seems to have a very reliable working logic. A project or project is divided into multiple stages, and corresponding resources are invested in each stage to complete the work of this stage. From each stage to the next stage, there are clear input and output products. After different stages carry out work activities according to the input they need, they will produce their own stage output and put it into the work of the next stage. If you are not at ease, you can add an approval link to each stage, so that each link can be reliably approved before being invested in the next link.
The SDLC waterfall model is generally used in these situations: requirements are stable and do not change frequently; the application is small; there are no unclear or unclear requirements; the environment is stable; the tools and technologies used are stable; not dynamic; resources are available.
2. Agile model
Agile is an iterative, team-based development method. This approach emphasizes rapid delivery of applications as complete functional components. All time is divided into "sprints (often called iterations)" by "fixed timeboxes". Instead of creating tasks and schedules. Each iteration cycle has a defined duration (usually in weeks) and contains a running list of deliverables planned at the beginning of the iteration. Deliverables are prioritized based on business value as determined by the customer. If all planned work in an iteration cannot be completed, the work will be reordered and this information will be used for future iteration planning. When the work is complete, it can be reviewed and evaluated by the project team and the client through daily builds and iteration demos. Agile relies on a very high level of customer involvement throughout the project, especially during these reviews.
From Agile's point of view, in many cases, we cannot understand all the content, or even if we understand it, we cannot guarantee that the content will not change. So first, according to the main path, after completing the main functions, we will continue to iterate to improve our work, so that when we make changes, the workload we overturn is also small, and we can quickly complete new requirements change. Through such continuous changes and reconstructions, we can obtain a product that is relatively satisfactory to customers.
Many students who support agile will say that compared with the waterfall method, the risk of agile risk is much smaller. Because of its focus on delivering small, well-tested, independent, valuable features. Risk is thus spread - if one function goes wrong, it shouldn't affect another. In this regard, we still plan our work in iterations, and we still release at the end of each iteration. Waterfall, on the other hand, lacks communication and iterations with the business, so if a requirement change is discovered late in the project, the project may fail or need to be restarted. This picture also seems to explain the dilemma that waterfall development often faces.
Under the banner of holding high efficiency and embracing change, it seems that agile mode is the best development mode. In contrast, the waterfall mode, in such shouts, seems a little unable to keep up with the pace, reflecting the old and rigid.
"Waterfall" against "Agile"
Agile itself is not a project management framework, nor is it a "methodology". It is a set of principles and values related to product development, especially Internet products are often developed using agile methods. However, there are methodologies based on agile principles which are product development methodologies rather than project management frameworks.
When it comes to demand changes, Waterfall can also go through demand changes, submit a change application, and follow the steps step by step to plan the workload. Although it is slower than Agile, my whole process is reliable! Why do you say that the waterfall is rigid and out of date?
It seems that there is nothing wrong with Waterfall's approach. Why don't we follow these steps to complete our work? Such a process sounds so reliable. Look, I have clear stages; look, I have clear approvals; look, I have clear change processes. With so many projects developing in the waterfall mode, it has proven to be an effective implementation method, hasn't it?
In addition, waterfall projects criticized by agile often fail, usually when very serious errors occur. This actually only happens if you have very poor control over the project. It is also incorrect that waterfall projects do not have iterations and multiple feedbacks from users - many projects can confirm the operation process through product prototype diagrams and business departments, but this method is not used in many projects.
Focus collision
agile mode, one iteration every two weeks, each iteration can deliver certain functional modules, allowing users to see the deliverables earlier, although only part of it, it also allows users to put forward their own opinions, when changes occur , developers can also make changes in the next iteration, allowing users to confirm again.
From this point of view, the collision between the two is a huge change in the timeliness of delivery and the cost of facing changes. Waterfall is relatively late in the delivery stage, and the delivered modules are relatively complete. When faced with changes, the impact range of changes is relatively large, and the cost of changes is extremely high. The later the stage of problem discovery, the higher the cost of solving the problem. In this way, the advantages of agile over waterfall in such a scenario are reflected.
Time and cost seem to be the two main considerations for Agile and Waterfall when choosing. The future can better guide future choices, and the advantages and disadvantages of agile and waterfall are listed in more detail below.
The advantages of agile development:
• The staged results of development will be reviewed as early as possible in the development process, and the risk of the project will be reduced;
• It is applicable to the situation where the requirements are not clear, because the requirements are not clear, so it needs to be gradually developed in the process of continuous iteration Clarify requirements.
• High flexibility, requirements can be changed at almost any time;
• Agile encourages frequent communication between developers and business users, unreasonable demands of business users and misunderstandings of developers will be reflected in these frequent communications Constantly review and update,
• Agile collaboration is usually much higher and can usually develop higher quality products;
• Suitable for fast-changing projects, especially CRM system projects for front-end business personnel are easier to adapt to business changes And change.
I Disadvantages of agile development:
• Agile concept acceptance is not too high, the first attempt may not be very successful
;
High level of collaboration and regular communication between developers and users. Business and IT personnel need to do a lot of preparatory work before communication, but in many cases the time for business communication cannot be guaranteed; •
When there are suppliers from Party B, agility will face greater challenges. Clients often want to understand their project input as early as possible. It is difficult to estimate project time and cost;
• In an agile project, the biggest problem may be that the business department never wants to have a final deadline.
I Advantages of waterfall development:
• In well-managed projects, waterfall can provide early confidence in delivery;
• Project team members do not need to communicate frequently in the same place
; A more appropriate approach;
• Waterfall projects use tools to model and manage these interfaces and dependencies if there are many interfaces and dependencies outside the base product development.
Disadvantages of waterfall development:
• Many enterprises and business people are really not easy to define requirements clearly in the early stage, and the assumed requirements based on early planning may have great risks; • The risk
of communication is much higher - especially many projects are There is a one-way communication in the early stage, and the expectations of the project and business personnel in the later stage are very different;
• The risk of waterfall projects is generally high, because the requirements based on invalid assumptions may make the project expand infinitely. So you see a lot of waterfall projects costing over budget or delayed.
Conclusion:
Agile and waterfall implementation methods are still very different. Waterfall can now be applied to almost any type of project, especially large ones. Agile methods have become more and more popular in the past two years, and we have begun to see a large number of agile methods adopted in enterprises (even the Department of Defense and federal agencies), especially the current SaaS software, such as Salesforce, SAP, etc. with their own development platforms It is very easy to build initial prototypes and quickly iterate on SaaS products. But in general agile cannot completely replace waterfall, it just gives us another good choice.
Hybrid Agile approaches that combine Agile and Waterfall methods are also now common for organizations. Once we have decided which basic method to use, we can further refine the process to best suit our project goals. In the end, while the way we work is important, delivering a reliable, maintainable product that meets our customers' needs is what counts.