Tạm biệt Agile: Khi sự mơ hồ không còn chỗ đứng trong kỷ nguyên AI

Tạm biệt Agile: Khi sự mơ hồ không còn chỗ đứng trong kỷ nguyên AI

RIP Agile, chúng ta hầu như không hiểu gì về nó. Và tôi nói theo nghĩa đen - vì không ai thực sự rõ ràng về định nghĩa của nó.

Agile đã ập vào ngành công nghiệp phần mềm như một cơn sóng thần. Tuy nhiên, bất cứ khi nào nó bị đặt câu hỏi, một giọng nói (có lẽ phát ra từ khe hở của những đám mây?) sẽ luôn luôn bảo chúng ta rằng: "À, nhưng đó không phải là Agile đích thực - Tuyên ngôn không hề đề cập đến các cuộc họp đứng hàng ngày (Daily Standups), cũng như các Huấn luyện viên Agile (Agile Coaches)". Thế nhưng, nếu đọc Tuyên ngôn Agile (2001) - nguồn gốc của Kỷ nguyên Mới rực rỡ của phần mềm - ta sẽ thấy nó thực ra không cho chúng ta biết nhiều điều gì. Tốt nhất, nó là một chuỗi những câu nói sáo rỗng ("Hợp tác với khách hàng hơn là đàm phán hợp đồng"), và tệ nhất là nó không khả thi về mặt thương mại ("Chào đón những thay đổi về yêu cầu, ngay cả khi ở giai đoạn muộn của quá trình phát triển").

Vậy nếu "Ngành công nghiệp Agile" không làm Agile đúng cách, và bản thân tuyên ngôn lại gần như không có ý nghĩa, thì nó rốt cuộc là gì?

"Một bóng ma đang ám ảnh Phần mềm, đó là bóng ma của Waterfall"

Agile luôn được định nghĩa chủ yếu dựa trên những gì nó không phải - và những gì nó không phải chính là Waterfall. Nếu bạn không làm Agile, bạn đang làm Waterfall, và Waterfall Không Hoạt Động.

Trừ khi chúng ta đã biết Waterfall không hoạt động từ năm 1970; và Winston W. Royce đã giải thích chính xác lý do tại sao, khuyến nghị chúng ta nên thay thế bằng cách:

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

Tất cả những điều này sau đó đều được tuyên bố là những sáng tạo của Agile. Trên thực tế, chúng đã được viết vào năm sau khi con người đặt chân lên mặt trăng.

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

Các loại vấn đề được phát hiện trong yêu cầu đã thay đổi trong vòng đời của một 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 sót trong yêu cầu khi họ cố gắng đáp ứng các yêu cầu đó bằng một thiết kế cụ thể.

Rõ ràng là phát triển lặp lại (iterative development) không phải là điều mới mẻ, và nó tiếp tục được tinh chỉnh thêm trong nhiều thập kỷ trước khi Agile ra đời. Waterfall không phải là kỹ thuật tiên phong trước khi Tuyên ngôn giải phóng chúng ta. Và không ai nghiêm túc nghi ngờ 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 (Spec-Driven Development)

Cho tốt hay xấu, sự sẵn có của các Mô hình Ngôn ngữ Lớn (LLM) giá rẻ được đào tạo trên các tập 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ó thể nói là đã dịch chuyển tinh thần của ngành phần mềm.

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

Cho đến khi bắt đầu viết mã, ba danh từ này (tài liệu, thông số kỹ thuật, thiết kế) đều chỉ một thứ duy nhất. Nếu tài liệu kém thì thiết kế cũng kém. Nếu tài liệu chưa tồn tại thì thiết kế cũng chưa tồn tại, chỉ có những người đang suy nghĩ và nói chuyện về thiết kế, điều này có giá trị một chút, nhưng không nhiều.

Khi đọc các tài liệu từ năm 1970 và 1976, ta buộc phải tự hỏi năm 2001 thực sự mang lại cho chúng ta điều gì. Agile được định nghĩa một cách mơ hồ và được tiếp thị như là giải quyết một vấn đề đã được giải quyết từ nửa thế kỷ trước bởi những kỹ sư nghiêm túc mà các bài báo của họ có ý nghĩa hơn nhiều. Khi lĩnh vực của chúng ta tiếp tục thay đổi - và chúng ta hy vọng là phát triển - đã đến lúc nhìn nhận mọi thứ dưới một góc độ mới, và đặt Agile vào thùng rác của lịch sử nơi nó thuộc về.