Cách tiếp cận Thác đổ và Agile

Một sinh viên viết cho tôi: “Ngày nay nhiều công ti đang dùng cách tiếp cận Agile, tại sao chúng em cần học về vòng đời Thác đổ vì nó không còn tác dụng? Các trường có thể dạy Agile thay thế không? Xin thầy bình luận.”

 

Đáp: Tôi đã viết vài bài về cách tiếp cận Agile và Thác đổ trong blog này, xin xem lại chúng. Về căn bản vòng đời Thác đổ là khái niệm cơ bản của phát triển phần mềm và nếu bạn hiểu rõ nó, bạn có thể làm bất kì cái gì dù bạn chọn Agile hay phương pháp khác. Tôi thường dạy vòng đời Thác đổ cho sinh viên hai năm đầu để cho họ thực sự hiểu khái niệm phát triển rồi đổi sang Agile trong năm thứ ba và thứ tư.

Trong vòng đời Thác đổ, sinh viên học cách làm hợp thức các yêu cầu và lấy phản hồi của người dùng trong từng pha (yêu cầu, thiết kế, viết mã và kiểm thử). Trong những cuộc kiểm điểm này, người dùng, người phát triển và người kiểm thử cộng tác để chắc sản phẩm cuối cùng đáp ứng cho nhu cầu của người dùng. Vì người kiểm thử tham gia sớm, họ thường cung cấp cái vào có giá trị trong yêu cầu trước pha thiết kế và pha viết mã. Để mọi người làm việc cùng nhau trong những pha này sẽ giúp cho sinh viên chuẩn bị làm việc trong “tổ tự quản” của Agile hiệu quả hơn.

Trong vòng đời Thác đổ, tổ được chia thành các vai trò và trách nhiệm nơi các thành viên tham gia tương ứng và công việc phát triển được phân chia thành những nhiệm vụ nhỏ hơn. Đây là chỗ sinh viên học các phân công khác nhau: họ có thể làm việc như người phát triển, người kiểm thử, người quản lí cấu hình, đảm bảo chất lượng v.v. Bằng việc học mọi vai trò, dễ dàng hơn cho họ để vận hành về sau trong Agile vì họ phải thực hiện mọi vai trò như một phần của tổ “tự quản”. Một khi họ hiểu toàn bộ vòng đời Thác đổ và mọi vai trò, họ có thể là “Người chủ Scrum” hay “Người quản lí sản phẩm” hiệu quả nữa.

Trong vòng đời Thác đổ, sinh viên học cách thu lấy yêu cầu từ người dùng và viết nó ra đúng để cho mọi người trong tổ hiểu rõ nó. Nó cũng chuẩn bị cho họ viết câu chuyện người dùng tốt hơn trong Agile nữa. Trong khi làm hợp thức yêu cầu, tổ phần mềm, khách hàng và người dùng thường có nhiều thảo luận để xác định rủi ro và nó cũng chuẩn bị cho sinh viên làm việc trên “tồn dư sản phẩm” và  “tồn dư Sprint” về sau khi họ làm việc trên Agile (phương pháp Scrum).

Dễ nói rằng với phương pháp Agile, bạn không cần học vòng đời Thác đổ nhưng điều đó là KHÔNG ĐÚNG. Bạn phải có hiểu biết rõ ràng về cách phần mềm được phát triển, từng pha và từng công việc về chi tiết TRƯỚC KHI học phương pháp Agile. ĐỪNG lẫn lộn phát triển phần mềm KÉM với Thác đổ, và ĐỪNG nghĩ cách tiếp cận Agile là TỐT HƠN. Từng cách tiếp cận có tính hữu dụng nào đó và bạn PHẢI HỌC CẢ HAI. Ngày nay, công nghệ thay đổi nhanh chóng điều yêu cầu chúng ta phát triển, tích hợp phần mềm nhanh chóng và đó là lí do tại sao Agile được ưa chuộng. TUY NHIÊN không có hiểu biết rõ ràng về vòng đời phát triển phần mềm Thác đổ, bạn sẽ KHÔNG có khả năng làm tốt với Agile. Tôi có nhiều năm làm việc trong cả hai cách tiếp cận, tôi cũng dạy cả hai và tôi tin rằng mọi sinh viên phải biết cả hai và trường phải dạy cả hai cách tiếp cận.

KHÔNG có “phương pháp hoàn hảo” hay “cách thức hoàn hảo” để phát triển phần mềm. Bất kì ai nói Agile là tốt hơn thác đổ hay thác đổ là tốt hơn Agile thì người đó chẳng biết gì. Tốt hơn cả là nói rằng chúng ta PHẢI chọn cách tiếp cận tốt nhất tuỳ theo hoàn cảnh nào đó, môi trường nào đó, và dự án nào đó để chuyển giao phần mềm chất lượng đáp ứng cho mong đợi của khách hàng, dù nó là thác đổ hay agile hay bất kì cái gì khác.

 

—English version—

 

Waterfall and Agile approach

A student writes to me: “Today more companies are using Agile approach, why do we need to learn the Waterfall lifecycle as it does not work? Should schools teach Agile instead? Please comment.

 

Answer: I have written several articles about Agile and Waterfall approach in this blog, please review them. Basically Waterfall lifecycle is the basic concept of software development and if you understand it well, you can do anything whether you select Agile or other methods. I often teach Waterfall lifecycle for students in the first two years so they really understand the development concept then change to Agile in the third and fourth year.

In Waterfall lifecycle, students learn to validate requirements and get users’ feedbacks in each phase (requirements, design, code, and test). During these reviews, users, developers and testers collaborate to make sure the final product meets users’ needs. Since testers participate early, they often offer valuable inputs into requirements before design phase and coding phase. Having everybody works together during these phases will help prepare students to work in “Self-organized” team of Agile more effective.

In Waterfall lifecycle, the team is divided into roles and responsibilities where members participate accordingly and development works are divided into smaller tasks. This is where students learn different assignments: they may work as developers, testers, configuration managers, quality assurance etc. By learning all the roles, it is easier for them to function later in Agile as they have to perform all the roles as part of the “Self-organized” team. Once they understand the entire Waterfall lifecycle and all the roles, they can be effective “Scrum Master” or “Product Manager” too.

In Waterfall lifecycle, students learn how to obtain requirements from users and write it correctly so everybody on the team understands it well. It also prepares them to write better User stories in Agile too. During requirements validation, the software team, customers and users often have a lot of discussions to determine risks and it also prepares students to work on the “Product backlog” and “Sprint backlog” later when they work on Agile (Scrum method).

It is easy to say that with Agile method, you do not need to learn Waterfall lifecycle but it is NOT CORRECT. You must have clear understanding of how software is developed, each phase and each work in detail BEFORE learning Agile methods. DO NOT confuse BAD software development with Waterfall, and DO NOT think Agile approach is BETTER. Each approach has certain usefulness and you MUST LEARN BOTH. Today, technology changes fast which requires us to develop, integrate software quickly and that is why Agile is preferred. HOWEVER without a clear understanding of the Waterfall software development lifecycle, you will NOT be able to do Agile well. I have many years of working in both approaches, I also teach both and I believe that every student must know both and the school must teach both approaches.

There is NO “Perfect method” or “Perfect way” to develop software. Anyone who says Agile is better than waterfall or waterfall is better than Agile than that person knows nothing. It is better to say that we MUST select the best approach depending on certain circumstances, certain environment, and certain project to deliver quality software that meet customers’ expectations, be it waterfall or agile or anything else.