Nói lời tạm biệt với Agile

14 tháng 4 năm 2026

RIP Agile, chúng tôi hầu như không biết bạn.

Và ý tôi là theo nghĩa đen - bởi vì không ai biết rõ nó là gì.

Agile tràn vào ngành của chúng tôi như một cơn sóng thần. Nhưng bất cứ khi nào nó được hỏi, một giọng nói (có lẽ phát ra từ một khoảng trống trên mây?) sẽ luôn nói với chúng tôi rằng "à, nhưng đó không phải là Agile đích thực - Tuyên ngôn không nói gì về Daily Standups cũng như các Huấn luyện viên Agile". Tuy nhiên, nếu một người đọc Tuyên ngôn Agile (2001), nguồn gốc của Kỷ nguyên Phần mềm Mới đã khai sáng của chúng ta, người ta chắc chắn sẽ nhận thấy rằng nó thực sự không cho chúng ta biết nhiều điều gì. Tốt nhất thì đó là một chuỗi những câu nói vô vị ("Sự hợp tác của khách hàng trong việc đàm phán hợp đồng") và tệ nhất là nó không thể thực hiện được về mặt thương mại ("Hoan nghênh các yêu cầu thay đổi, thậm chí là trong quá trình phát triển muộn").

Vậy nếu Ngành Agile không thực hiện Agile đúng cách và bản tuyên ngôn gần như vô nghĩa thì chính xác thì nó là gì?

"Một bóng ma đang ám ảnh Phần mềm, bóng ma của Thác nước"

Agile luôn được xác định chủ yếu theo những gì không phải - và những gì không phải là Thác nước. Nếu bạn không thực hiện Agile thì bạn đang thực hiện Thác nước và Thác nước không hoạt động.

Ngoại trừ việc chúng tôi biết rằng Thác nước đã không hoạt động kể từ năm 1970; và Winston W. Royce đã trình bày chính xác lý do, thay vào đó đề xuất chúng tôi:

Bắt đầu bằng việc thiết kế chương trình.
Tạo nguyên mẫu của phần mềm để thu thập thông tin nhằm tinh chỉnh các yêu cầu.
Sự tham gia của khách hàng ("sự tham gia phải chính thức, chuyên sâu và liên tục").

Tất cả những điều này sau đó được cho là những đổi mới của Agile. Trên thực tế, chúng được viết vào năm sau cuộc đổ bộ lên mặt trăng.¹

Và ngay cả trong thập kỷ đó, đây không phải là tác phẩm duy nhất rời xa Waterfall. Một bài báo năm 1976 của Bell và Thayer - bài báo đầu tiên đặt ra thuật ngữ "Thác nước"² - cho chúng ta biết ở phần cuối của một nghiên cứu thực nghiệm:

Các loại vấn đề được phát hiện trong yêu cầu đã thay đổi trong suốt quá trình thực hiện dự án phát triển phần mềm. Các nhà phát triển hệ thống thường chỉ xác định được sự thiếu hụt yêu cầu khi họ cố gắng đáp ứng các yêu cầu bằng một thiết kế.

Vì vậy, rõ ràng là việc phát triển lặp lại không phải là mới và sẽ tiếp tục được cải tiến hơn nữa trong những thập kỷ trước Agile³. Thác nước không phải là hiện đại trước khi Tuyên ngôn giải phóng chúng ta. Và không ai thực sự nghi ngờ về tính hiệu quả của các yêu cầu và thông số kỹ thuật.

Phát triển dựa trên thông số kỹ thuật

Dù tốt hay xấu, sự sẵn có của LLM giá rẻ được đào tạo trên bộ dữ liệu lập trình khổng lồ đã thay đổi cách nhiều người trong chúng ta lập trình máy tính và được cho là đã thay đổi hệ tư tưởng của phần mềm.

Một sự phát triển tích cực rõ ràng sau đó là phần mềm các chuyên gia đang viết thông số kỹ thuật một lần nữa. LLM - giống như nhiều người trong chúng ta - không hoạt động tốt với sự mơ hồ và việc chỉ định các vấn đề đang chứng tỏ là một công cụ hiệu quả để tạo mã chính xác. Agile nói với chúng tôi "Phần mềm hoạt động dựa trên tài liệu toàn diện". Phát triển theo hướng đặc tả đang nói với chúng ta rằng "Tài liệu toàn diện sẽ tạo ra phần mềm hoạt động được". Và thực sự, LLM hay không, không có gì mới dưới ánh mặt trời. Quoth Royce:

Cho đến khi bắt đầu mã hóa, ba danh từ này (tài liệu, thông số kỹ thuật, thiết kế) biểu thị một thứ duy nhất. Nếu tài liệu tệ thì thiết kế tệ. Nếu tài liệu chưa tồn tại thì tức là chưa có thiết kế, chỉ có mọi người nghĩ và nói về thiết kế, dù có giá trị nào đó nhưng không nhiều.

Đọc năm 1970 và 1976, người ta phải hỏi năm 2001 thực sự mang đến cho chúng ta điều gì. Agile được định nghĩa một cách mơ hồ và được tiếp thị là giải quyết một vấn đề đã được giải quyết cách đây nửa thế kỷ bởi các kỹ sư nghiêm túc có bài viết hợp lý hơn. Khi lĩnh vực của chúng tôi tiếp tục thay đổi - và chúng tôi hy vọng sẽ phát triển - đã đến lúc nhìn mọi thứ bằng một góc nhìn mới mẻ và ném Agile vào thùng rác lịch sử nơi nó thuộc về.

Chú thích cuối trang

Người ta tự hỏi làm thế nào mà các lập trình viên của Máy tính Hướng dẫn Apollo lại đạt được thành tích như vậy, lập trình mà không có Điểm Câu chuyện cũng như không biết rằng "Liên tục chú ý đến sự xuất sắc về mặt kỹ thuật và thiết kế tốt sẽ nâng cao tính linh hoạt". ↩
Tất nhiên được sử dụng làm ví dụ về những việc không nên làm. ↩
Tôi rất muốn đưa một số tài liệu tham khảo đến "No Silver Bullet" của Freed Brook vào đây nhưng tôi cố gắng giữ những bài đăng này ngắn gọn. Tôi cũng có Mô hình xoắn ốc của Boehm trong danh sách đọc của mình. ↩

Nghĩ rằng tôi có thể giúp công ty của bạn? Liên hệ hoặc truy cập trang web tư vấn của tôi!