Ramblings about two software development models: Waterfall and Agile

Ramblings about two software development models: Waterfall and Agile

![Ramblings about two software development models: Waterfall and Agile](tan-man-ve-hai-mo-hinh-phat-trien-phan-mem-la-waterfall-va-agile =1200x900)

Introduction

During my studies, in the subject "Analysis and Design of Information Systems," I learned about the Waterfall software development model. The name of this model evoked an image of a powerful waterfall cascading down from top to bottom, suggesting a sequential process that is not easily reversible.

However, in my professional career, I have yet to encounter any company that actually employs this model for software development. Instead, there is another name: Agile.

Agile - Scrum is a name I'm sure many people are familiar with or are currently implementing in their workplace. A cycle (sprint) takes only about 2 weeks to develop and complete a set of features, which are then released to the market and made available to users. The idea behind Agile is to deliver features to customers as quickly as possible, thus satisfying them and making them willing to pay for the product.

What could be more fantastic than Agile? We constantly cycle through new feature lists, "code" and "release"... occasionally taking a cycle to fix bugs and improve functionality. At the end of each sprint, we have a retrospective session where we look back on what we have done well or not so well, learning from it for the next time.

Honestly, as a fresh graduate, Agile seemed like the most amazing method to me. People often say that humans tend to develop strong emotions towards the first thing they encounter. This means that from the very beginning of my exposure to Agile, no matter what other models I came across, Agile always held a special place in my heart.

There was a time when I highly praised Agile, ready to crush other methods like Waterfall in debates. I believed that Waterfall was outdated and incapable of meeting the demands of modern software development.

But recently, I may have gathered enough "evidence" to support a certain truth: "Agile is not the best," or rather, it is often not ideal in most cases.

So, why is that?

Waterfall and Agile

First, let's briefly revisit the concept of the Waterfall model.

Waterfall is a software development model in which the development process resembles a flowing waterfall, with phases executed in a strict sequence without any backtracking or skipping of phases, including requirements analysis, design, implementation, testing, integration, and maintenance.

Waterfall Model

During my professional experience, I have found that requirements analysis is always the most time-consuming stage. It involves making decisions about what needs to be done, combining strategies with vision, plans, and even statistical figures to achieve the desired features.

Therefore, it must be meticulously and cautiously done before moving on to the next stage because once you proceed, it becomes difficult to backtrack. At that point, another department has taken over the requirements and started designing the system and application/software interfaces. What happens if an unexpected issue arises right from the first step?

If the mistake is small and within control, just a matter of rephrasing or adding a few cases that do not affect the main functionality, everything can be accepted. On the other hand, let's assume the Design department receives the requirements and discovers a significant number of issues that, if not addressed, prohibit progress. The waterfall process may collapse in such a situation. We cannot keep going in a loop from Requirements to Design because subsequent steps will never be able to continue.

I believe that many mistakes similar to the above have occurred in the past, which necessitated the emergence of a new approach: Agile.

Agile software development is a flexible method for executing software technology projects; it encourages change during project development and delivers the product to the end-users as quickly as possible.

Agile Model

We no longer have a waterfall, no longer a step-by-step cascade, and no longer fear going back. Now, everything focuses on "delivering the product to the end-users as quickly as possible."

Well, that sounds quite broad. How can we deliver the product to end-users as quickly as possible?

Scrum is a flexible collaborative framework often applied within Agile. According to Scrum, we have a time-limited iteration in which software development occurs continuously, typically lasting 2 weeks to a month. In each iteration, a feature must be completed and brought to the end-users. There are many more rules, but I won't go into detail within the scope of this article.

I believe that Agile is widely popular. If you ask 10 people in the same field, 9 of them will know Agile, and the companies they work for are likely implementing this method. Only one person might say, "I'm free," meaning they are not following any specific model.

In today's fierce competition in technology products, we cannot be certain that our ideas are unique because even a slight delay may result in numerous similar products appearing, even if they haven't been promoted anywhere.

Therefore, we need Agile to quickly release products to users, thereby capturing the market, and then we can leisurely add new features. Is this true? If you have applied Agile and observed a few limitations without openly expressing them, take a moment to think about those drawbacks and see if they align with my observations.

Below are the "evidence" mentioned at the beginning of this article to reinforce the viewpoint that "Agile is not the best" based on over 5 years of my working experience.

  • Ambiguity and lack of information: In continuous and short-term cycles, everything must happen quickly. From creating documentation to grooming sessions to disseminate development goals, sometimes you don't even have enough time to review the documentation for the upcoming features.
  • Too fast-paced and lacking time for reflection: You cannot fully anticipate the impact of what you are about to do on what already exists until you start working on it, when new issues arise.
  • Tendency towards exhaustion and disillusionment: Continuously rotating through features, occasionally even having to accept entirely new requirements, can cause delays or even project failures. The lack of stability in product development can lead to doubts about the product itself.
  • ET and OT: Once the feature list is received, the next step is detailed planning, task allocation, and estimation of completion time. This is not an easy task as it takes a lot of time to "predict" things that are still uncertain. If the deadline is approaching and work is not yet completed, overtime becomes the last resort, resulting in a week of non-stop work.
  • Falling into the construction trap: Have you ever wondered where the feature list comes from? Is it from top management, customers, or the research department? A product brings value to users when it solves their problems. Therefore, the features must align with the customers' needs. We need more interaction with customers to truly understand what they want, and this often takes time and effort. There must be a faster way than trying to understand users' pain points by continuously releasing features and observing their usage. If the usage is high, it means success, and vice versa.
  • Lack of product understanding: Most of the time, when starting a new job, I have a few weeks to get acquainted with new things, such as the culture, environment, product, and even the code... but rarely am I presented with an overall picture of the product I am going to work on. Mostly because the time to get acquainted is limited, and afterwards, you get swept up in the never-ending software development cycle.

At this point, it becomes apparent that Waterfall addresses most of the above disadvantages.

All requirements are clarified right from the beginning, and we have sufficient documentation to work on without the fear of changes. The issue at this stage is only the time plan for completing all the features.

Surveys and evaluations are integral to the initial stage. Surveys help us avoid the construction trap and provide a basis to believe that when a feature is released, it will bring satisfaction to many people.

When all departments have a clear understanding of the product, it creates motivation towards a future where the product is created and the value it brings to users.

Nevertheless, the strength of Waterfall is also its greatest weakness, as it lacks flexibility in software development stages. Most companies I have worked with are in the startup phase, and they have temporary strategies and plans to rapidly release products in order to capture the market.

I'm not here to criticize any particular method; rather, once we recognize the drawbacks, we need to find ways to mitigate them.

Agile encourages more interactions among team members to expedite the development process. Instead of blaming the product research team for unclear requirements or delayed documentation, because everyone is often caught up in the priority feature list for the product's survival, we can proactively ask questions to clarify issues, think critically or point out cases that the product team may have missed. Remember, once Agile is chosen, the most important thing is how to release the product to users as quickly as possible.

To avoid falling into the construction trap, ask more questions related to the product during the Grooming or Planning phase. Require numbers that speak and, if possible, ask why certain upcoming features are necessary. This helps everyone have a broader view of the value the product brings to end-users.

Lastly, always be prepared for continuous changes.

Conclusion

In conclusion, this article is a personal reflection on the advantages and disadvantages of the Waterfall and Agile software development methods. While Waterfall requires a solid foundation, Agile is more suitable for flexible changes. They are suitable for different work environments, and through this article, I hope readers will not fall into the same mistakes as I did by overrating one method over the other from the very beginning.

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.
Author

Hello, my name is Hoai - a developer who tells stories through writing ✍️ and creating products 🚀. With many years of programming experience, I have contributed to various products that bring value to users at my workplace as well as to myself. My hobbies include reading, writing, and researching... I created this blog with the mission of delivering quality articles to the readers of 2coffee.dev.Follow me through these channels LinkedIn, Facebook, Instagram, Telegram.

Did you find this article helpful?
NoYes

Comments (8)

Leave a comment...
Avatar
Ẩn danh11 months ago
Nếu nhóm của bạn cảm thấy mệt mỏi với sự thay đổi và mông lung khi không có tài liệu, kế hoạch rõ ràng, có lẽ nhóm bạn nên thêm nó vào quy trình của mình, mình nghĩ dù bạn dùng gì thì cũng cần sự rõ ràng và thống nhất. Mình thấy cái này (https://designsprintkit.withgoogle.com/) có thể giúp ích cho nhóm của bạn. Nhân tiện vì comment được sắp xếp theo cái mới nhất, mình thấy đưa ô nhập lên trên thì sẽ tốt hơn
Reply
Avatar
Xuân Hoài Tống11 months ago
Rất cảm ơn về sự gợi ý. Thực ra cuối các buổi retro, team cũng đã nêu ra rất nhiều lần rồi và... như bạn biết đấy, chỉ khắc phục được một phần... Một quy trình có vấn đề có lẽ cũng phụ thuộc vào nhiều yếu tố, cả khách quan, chủ quan và mình nghĩ nhiều nhất là yếu tố con người. Các công ty mình góp mặt hầu như đều bị một vấn đề như thế, thời gian đầu cảm thấy rất ức chế, chán... nhưng sau đó thì dần hiểu ra và mình không đổ lỗi cho ai cả mà cách tốt hơn là tìm cách để giải quyết những vấn đề đó.
Avatar
Ẩn danh11 months ago
mình hiểu quan điểm của bạn, mình thấy mối phương pháp đều cho thấy sự phù hợp trong các phạm vi, quy mô khác nhau, không nhất thiết mình phải áp dụng chỉ một cho tất cả. Mình thấy dẫn chứng bạn đưa ra có chút thiên kiến về một phương pháp, những vấn đề bạn đề cập cho agile hoàn toàn vẫn gặp trong Waterfall, nên đã đề cập đề mọi người có cái nhìn đa chiều hơn. cảm ơn bạn về bài viết
Reply
Avatar
Xuân Hoài Tống11 months ago
Vâng, chắc chắn là mỗi phương pháp luôn tồn tại ưu và nhược điểm, và chúng ta cần là chọn ra được giải pháp phù hợp. Mình cũng không phủ nhận mặt tích cực của Agile, tuy nhiên chúng ta hoàn toàn có thể cóp nhặt được những gì tốt trong mỗi cái để "biến" thành của riêng. Thực ra bài viết nói nhiều về Agile hơn bởi vì hầu hết thời gian làm việc của mình đều dựa trên phương pháp này, rồi từ đó rút ra được những thứ có trong bài viết. Tuy vậy đó không hoàn toàn là quan điểm của cá nhân, mình cũng có hỏi và quan sát đồng nghiệp trong cùng môi trường. Đa phần họ đều cảm thấy mệt mỏi với sự thay đổi và mông lung khi không có tài liệu, kế hoạch rõ ràng. Cảm ơn vì những góp ý của bạn để bài viết được hoàn thiện hơn.
Avatar
Ẩn danh11 months ago
chiến lược thay đổi đâu có phụ thuộc vào phương pháp pháp triển. Khi bạn đang áp dụng Waterfall, nhu cầu người dùng hay chiến lược phát triển vấn có thể thay đổi mà, cái duy nhất khó thay đổi là watefall, lúc đó những gì bạn phân tích xong đã không còn phù hợp với thị trường, nó vấn đảm bảo bạn làm ra sản phẩm như bạn đã xác định, nhưng lúc đó, sản phẩm đó có còn đúng với nhu cầu thị trường. Giá trị của Agile là linh hoạt để thích ứng với sự thay đổi
Reply
Avatar
Ẩn danh11 months ago
Các vấn đề trong bài dường như đến từ việc nhóm đã hiểu sai ý nghĩa của nhanh trong Agile, dẫn đến đã loại bỏ vài bước trong CTPT khi triển khai Agile. Nhanh chuyển giao tới người dùng chứ không phải nhanh là bỏ qua giá giai đoạn khi phát triển
Reply
Avatar
Xuân Hoài Tống11 months ago
Qua đó, chúng ta thấy được ưu và nhược điểm của từng phương pháp. Một sprint có thể coi là một waterfall rất nhỏ? Có thể có...hoặc không. Đơn giản vì thời gian diễn ra của nó quá ngắn, chúng ta không có thời gian tổ chức tài liệu, kế hoạch khảo sát cục diện hay thực hiện một chu trình hoàn chỉnh như waterfall được, nơi mà các bước phải được ổn định nhất có thể. Nói như thế không phải là Agile không chỉn chu mà đó là sự linh hoạt, không cứng nhắc như waterfall. Sự dẻo dai của agile giúp cho đội phát triển phần mềm biến đổi linh hoạt tùy theo nhu cầu thị trường, đổi lại nó sẽ khiến cho các thành viên trong đội phải rèn luyện một tinh thần thích ứng cao độ.
Avatar
Xuân Hoài Tống11 months ago
Mình hiểu ý của bạn đang muốn đề cập đến, dù là phương pháp phát triển phần mềm nào thì mục đích cuối cùng vẫn là đưa sản phẩm đến với người dùng cuối, chỉ có điều là quá trình đó diễn ra như thế nào. Theo như cách trình bày vấn đề của bạn, "Bản chất Agile vẫn dùng Waterfall để phát triển" thì mình cảm thấy không đồng quan điểm cho lắm. Hãy đi qua khái niệm của Agile, phương pháp này khuyến khích sự thay đổi và tương tác, hay nói cách khác là tùy cơ ứng biến, trong khi bạn đang thử nghiệm tính năng này thì vì một lý do nào đó mà thay đổi chiến lược thì hoàn toàn có thể tạm gác lại và làm cái mới. Waterfall thì ngược lại, mọi thứ đã được lên kế hoạch từ đầu rất chỉn chu và tất cả quá trình được diễn ra tuần tự mà không có bất kì sự xáo trộn nào cho đến khi sản phẩm được ra mắt.
Avatar
Ẩn danh11 months ago
Vì khối lượng công việc và giá trị chuyển giao nhỏ hơn, nên thời gian phát hành tới người dùng sẽ nhanh hơn, nhanh có được phản hồi từ người dùng. đây mới là ý nghĩa của nhanh trong Agile. Thay vì chỉ có 1 CTPT tại một thời điểm như Waterfall truyền thống, Agile có thể làm nhiều CTPT cùng một thời điểm nên với một phần mềm lớn chúng ta có thể đưa nhiều team vào phát triển độc lập, cái mà Waterfall truyền thống không cho phép
Reply
Avatar
Ẩn danh11 months ago
Cả Waterfall truyền thống vs Agile hay Scrum đều thực hiện các CTPT, chúng chỉ khác nhau về khối lượng công việc và giá trị chuyển giao tới khách hàng.
Reply
Avatar
Ẩn danh11 months ago
Agile và Scrum: với khối lượng tính năng đồ sộ xác định được, chúng ta xác định một lượng tối thiểu các tính năng cần để có thể phát hành (MVP). Sau đó cứ mối Sprint chúng các xác định vài tính năng rồi thực hiện 1 CTPT lên đó.
Reply
Avatar
Ẩn danh11 months ago
Bản chất Agile vẫn dùng Waterfall để phát triển, chỉ khác nhau về phạm vi, giá trị chuyển giao tới người dùng. Chu trình phát triển( CTPT - các bước chính ): Phân tích thị trường, xác định yêu cầu - thiết kế, phát triển - kiểm thử, phát hành Waterfall truyền thống: chúng ta xác định sản phẩm cần làm và thực hiện chỉ 1 CTPT. Sau đó phần mềm thay đổi, chúng ta tổng hợp lại và thực hiện 1 CTPT mới trong 1 khoảng thời gian (thường theo năm)
Reply