Tạm biệt Agile
(lewiscampbell.tech)- Phương pháp Agile từng thống trị ngành phần mềm đang được nhìn nhận lại theo hướng phê phán: trên thực tế nó chỉ là tập hợp các nguyên tắc mơ hồ và việc đóng gói lại những vấn đề vốn đã được giải quyết từ trước
- Thế đối lập với Waterfall phần lớn chỉ là ảo tưởng; các khái niệm cốt lõi như phát triển lặp và sự tham gia của khách hàng đã xuất hiện trong các nghiên cứu từ thập niên 1970
- Agile luôn được định nghĩa như điều đối lập với mô hình Waterfall, nhưng những giới hạn của mô hình này đã là điều được biết đến rộng rãi từ những năm 1970
- Sự xuất hiện gần đây của mô hình ngôn ngữ lớn (LLM) đang khiến phát triển dựa trên đặc tả (Spec-Driven Development) trở nên quan trọng trở lại, kéo theo sự trỗi dậy của phát triển lấy tài liệu làm trung tâm
- Khẩu hiệu của Agile là “phần mềm chạy được quan trọng hơn tài liệu toàn diện”, nhưng nay đang chuyển thành nhận thức rằng “tài liệu toàn diện tạo ra phần mềm chạy được”
- Đã đến lúc vượt qua sự mơ hồ mà Agile để lại để quay về với những nguyên tắc rõ ràng và cách tiếp cận mang tính kỹ nghệ
RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, hãy yên nghỉ. Chúng ta còn chưa từng thực sự hiểu rõ về ngươi.
Và tôi nói điều đó theo đúng nghĩa đen — vì chưa từng có ai thực sự rõ nó là gì.
Vấn đề bản sắc của Agile
- Agile là một làn sóng lớn quét qua toàn bộ ngành phần mềm, nhưng trên thực tế lại là một khái niệm lan rộng trong khi ý nghĩa vẫn mơ hồ
- Mỗi khi có người đặt câu hỏi, câu trả lời lặp đi lặp lại luôn là: “đó không phải Agile thật sự”
- Nếu thực sự đọc Tuyên ngôn Agile (2001), gần như không có chỉ dẫn cụ thể nào; nó chỉ dừng ở mức những châm ngôn mơ hồ như “hợp tác với khách hàng quan trọng hơn đàm phán hợp đồng”
- Những nguyên tắc như “chào đón thay đổi yêu cầu ngay cả ở giai đoạn cuối của phát triển” là phi thực tế về mặt thương mại
- Dưới lập luận về “True Agile”, các vấn đề trong thực tế làm việc thường bị né tránh như thể chúng không liên quan đến bản thân bản tuyên ngôn
- Nếu cả ngành công nghiệp Agile cũng không thực hành Agile đúng nghĩa, và bản thân tuyên ngôn lại thiếu ý nghĩa rõ ràng, thì phải đặt câu hỏi Agile thực chất là gì
“Bóng ma thác nước đang ám phần mềm”
- Agile luôn chỉ được định nghĩa bằng thứ mà nó không phải — tức Waterfall; theo logic đó, nếu không làm Agile thì bạn đang làm Waterfall, mà Waterfall thì không hiệu quả
- Nhưng việc Waterfall không hiệu quả đã được biết đến từ năm 1970, và Winston W. Royce đã giải thích chính xác lý do vì sao
- Royce khuyến nghị một phương án thay thế gồm: bắt đầu từ thiết kế chương trình, xây dựng nguyên mẫu phần mềm để tinh chỉnh yêu cầu, và duy trì sự tham gia chính thức, sâu sát, liên tục của khách hàng
- Tất cả những điều này về sau được tuyên bố là đổi mới của Agile, nhưng thực ra đã được viết ra từ năm 1970, tức ngay năm sau cuộc đổ bộ lên Mặt Trăng
- Chú thích 1: Các lập trình viên của máy tính dẫn đường Apollo đã làm nên kỳ tích đó như thế nào khi không hề có story point, cũng chẳng biết nguyên tắc “sự quan tâm liên tục đến xuất sắc kỹ thuật giúp tăng tính linh hoạt”?
Bài báo Bell-Thayer năm 1976 và lịch sử của phát triển lặp
- Bài báo của Bell và Thayer năm 1976 là tài liệu đầu tiên sử dụng thuật ngữ “Waterfall”, và chính thuật ngữ này được dùng như một ví dụ về điều không nên làm
- Kết luận từ nghiên cứu thực chứng của bài báo đó: các lỗi trong yêu cầu chỉ thực sự bị phát hiện trong quá trình phát triển phần mềm khi người ta cố gắng đáp ứng yêu cầu bằng thiết kế
- Phát triển lặp không phải điều mới mẻ, mà đã được liên tục tinh chỉnh trong nhiều thập kỷ trước cả Agile
- Ngay cả trước khi tuyên ngôn được cho là đã giải phóng ngành công nghiệp, Waterfall cũng không phải kỹ thuật tiên tiến, và cũng không ai nghiêm túc nghi ngờ tính hiệu quả của yêu cầu và đặc tả
Sự trỗi dậy của phát triển dựa trên đặc tả và thời kỳ hậu Agile
- Với sự phổ biến của LLM, xu hướng các lập trình viên quay lại viết đặc tả (specification) đang mạnh lên
- Vì LLM dễ thất bại trước đầu vào mơ hồ, việc mô tả vấn đề một cách rõ ràng đang trở thành cách giúp tạo ra mã đúng hơn
- Nếu Agile nhấn mạnh “phần mềm chạy được quan trọng hơn tài liệu toàn diện”, thì phát triển dựa trên đặc tả đưa ra mệnh đề ngược lại: “tài liệu toàn diện tạo ra phần mềm chạy được”
- Royce đã chỉ ra từ năm 1970 rằng “tài liệu hóa, đặc tả và thiết kế là cùng một khái niệm cho đến trước khi viết mã; nếu tài liệu kém thì thiết kế cũng kém”
- Ông nhấn mạnh rằng nếu không có tài liệu thì cũng không có thiết kế
- Khi nhìn lại các nghiên cứu năm 1970 và 1976, có thể thấy Tuyên ngôn Agile năm 2001 đã không mang lại một góc nhìn mới nào
- Agile chỉ đơn thuần thay thế cách tiếp cận kỹ nghệ sẵn có bằng định nghĩa mơ hồ và lớp vỏ đóng gói thương mại, chứ không tạo ra tiến bộ thực chất
- Các bài báo của những kỹ sư thời đó mang ý nghĩa rõ ràng hơn nhiều
- Trong bối cảnh phát triển phần mềm vẫn tiếp tục thay đổi và tiến hóa, đã đến lúc tiễn Agile vào lịch sử và chuyển sang một góc nhìn mới
- Cần quay lại với những nguyên tắc rõ ràng và tư duy kỹ nghệ mà các kỹ sư nghiêm túc của quá khứ đã để lại
21 bình luận
Tôi không hiểu vì sao mọi người lại xem phương pháp luận như kinh thánh. Tôi nghĩ ngay cả tác giả gốc cũng chỉ khác về định hướng, còn về tính giáo điều thì cũng chẳng khác là bao.
Có vẻ kết luận hơi quá đà. Việc thương mại hóa hay hình thức hóa có thể là vấn đề, nhưng không phải những công cụ như sprint hay backlog đã trở nên vô dụng. Chúng cũng đã giúp hình thành văn hóa họp hành mang tính ngang hàng và tập trung vào mục tiêu. Đúng là SDD đã trở nên quan trọng hơn, nhưng chính đặc tả đó vẫn có thể được viết nhanh theo cách cộng tác với AI, nên về bản chất vẫn là agile. Chỉ là sprint kéo dài 2 tuần đã được rút ngắn xuống còn vài giờ, còn bản chất của việc mài giũa lặp đi lặp lại thì vẫn y nguyên.
Tôi đồng ý.
Chỉ riêng việc phá bỏ cơ chế ra quyết định theo chiều dọc và cải tiến lặp lại theo các chu kỳ ngắn cũng đã để lại cho chúng ta một thông điệp lớn rồi (đương nhiên các kỹ thuật/công cụ quản lý dự án cũng vậy).
Có vẻ kết luận rằng 'bản thân Agile đã không thể mang lại những góc nhìn mới, đồng thời quy chụp toàn bộ những người ủng hộ Agile thành các fan cuồng Agile một cách mù quáng' là hơi cực đoan.
Tôi đồng cảm. Agile vẫn còn nguyên giá trị. Có vẻ như đây là những lời nói vu vơ của những người chưa từng làm việc thực tế.
Đúng là một bài viết ngớ ngẩn. Cốt lõi là ngay cả
speccũng phải được viết theo cách agile... Agile là phản ứng nhanh trước những thay đổi trong yêu cầu của khách hàng và thích nghi với chúng.Chính vì những người có sự hiểu lầm sai lệch và những tưởng tượng hời hợt về agile như thế này mà cả agile lẫn văn hóa phát triển đều đang đi sai hướng.
"Viết spec theo kiểu agile" bản thân nó nghĩa là gì vậy?
Cốt lõi của bài viết đó ngay từ đầu là tác giả cũng không biết agile là gì. Người ta chỉ toàn nói agile có những đặc tính này, phải làm thế kia thế nọ, nhưng đến giờ tôi vẫn chưa thấy bài nào chỉ ra rằng đây là một sản phẩm được tạo ra bằng phương pháp agile. Ngay cả khi đọc Tuyên ngôn Agile tôi cũng vẫn thấy mơ hồ. Hay là thử cho xem một ví dụ đi?
Đây là nội dung cơ bản xuất hiện trong hầu hết các sách về các phương pháp Agile như Extreme Programming của Kent Beck, Scrum của Jeff Sutherland, v.v. Bạn cũng có thể xem user story. Có vẻ như phần lớn mọi người không thực sự biết rằng nền tảng của Agile là các sprint ngắn và demo để nhanh chóng thích ứng với yêu cầu của khách hàng.
Là ý 3, 4. Việc viết spec thật chi tiết có độ sâu gần như vô hạn. Điều quan trọng là phải có một mức độ phù hợp với tổ chức. Nếu nhìn lại lịch sử các dịch vụ thành công đã được tạo ra như thế nào, tôi được biết rằng trong 99% trường hợp, một yếu tố chính là không dồn quá nhiều sức vào việc viết spec thật chính xác. Tức là không bị sa lầy vào đó. Chỉ cần nhìn cách những thứ như Summoners War, Dungeon & Fighter, Zigbang hay Lineage được tạo ra là hiểu.
Nếu chu kỳ waterfall chỉ diễn ra trong một ngày thì sao?
Dạo gần đây tôi thấy những trường hợp như thế này thường xuyên hơn.
Thật kinh khủng là đây dường như là thứ tôi thấy thường xuyên nhất...
Ở trong nước, Agile chẳng hơn cũng chẳng kém gì một công cụ để gây áp lực tiến độ lên các lập trình viên.
Ngoài việc phát hành theo chu kỳ ngắn thì tôi không biết còn lại điều gì của Agile nữa.
Backlog hay sprint cũng đã tồn tại trước đó dưới những hình thức khác, còn việc giao tiếp với khách hàng thì có nhiều điểm không khớp với thực tế. Cuối cùng, tôi nghĩ rằng so với Agile, việc cải thiện DevOps đã mang lại nhiều tiến bộ hơn cho phát triển phần mềm.
Theo một số tiêu chí thì ai cũng đều agile cả. Có lẽ chưa từng có thời đại nào như bây giờ, khi chúng ta triển khai nhanh và nhận phản hồi nhanh đến vậy.
Bản thân bài viết này đã không hề agile!
Vì không phải là không có lúc cần đọc code, nên ở góc độ này câu nói "code hơn tài liệu" có vẻ vẫn đúng; còn vì tài liệu với vai trò là chỉ thị thì phải được LLM, chủ thể triển khai, đọc hiểu, nên ở góc độ đó tôi cũng đồng ý. Vì vậy, kết luận có lẽ là cả hai đều quan trọng cùng lúc phải không.
Vấn đề của các sản phẩm do LLM tạo ra hiện nay là khoản nợ tích lũy ở giai đoạn vận hành. Để vận hành liên tục thì lập trình viên vẫn phải can dự vào code, và để làm được điều đó, tôi nghĩ rằng cho đến hiện tại code vẫn phải có khả năng thay thế cho tài liệu.
Nếu cẩn trọng nêu ý kiến phản biện thì, tôi cho rằng code không thể thay thế tài liệu. Programming language vẫn chưa có được độ phong phú trong biểu đạt và khả năng truyền tải như ngôn ngữ tự nhiên, và thực tế thì ai có thể đọc hết từng ấy code chứ?
Mong muốn có được thứ code có thể thay thế tài liệu chỉ là một niềm hy vọng và ước ao, nhưng đó là một Tháp Babel không thể với tới.
Thà chăm chỉ làm OOAD còn có vẻ tốt hơn.
Ngược lại, tôi cũng cho rằng việc ngôn ngữ tự nhiên thay thế code là điều khó xảy ra. Ngôn ngữ tự nhiên tuy nhanh hơn code nhưng lại quá trừu tượng. Để tính toán, cuối cùng vẫn phải lấp đầy các chi tiết, và có vẻ ngôn ngữ tự nhiên khó có thể đảm nhận vai trò này.
Khi viết phần mềm, vấn đề không hẳn là tính trừu tượng mà là sự mơ hồ. Ngôn ngữ tự nhiên về bản chất là mơ hồ. Nó cũng có thể đa nghĩa nữa. Vì vậy có lẽ những nỗ lực viết code bằng ngôn ngữ tự nhiên không hoạt động tốt. Trong tình huống như thế này, chuyện ngôn ngữ tự nhiên thay thế code lại càng là điều khó mà nghĩ tới.
Tôi đồng cảm với ý kiến mà bạn đã nói. Rõ ràng có những phần không thể thay thế bằng code. Theo nghĩa đó, nếu giải thích hơi khác đi một chút, điều tôi muốn nói là code có tính dễ đọc cao sẽ giúp không cần phải tạo ra tài liệu. Vì tài liệu tích tụ khi phần mềm kéo dài theo thời gian cũng tạo ra gánh nặng nhận thức cho lập trình viên. Điểm cốt lõi là giảm bớt việc phải qua lại giữa code và tài liệu. Tôi nghĩ không thể chỉ để lại mỗi code. Tôi cũng cho rằng điều đó có thể khác tùy theo bối cảnh và tình huống đang đối mặt. Cảm ơn bạn đã để lại bình luận.
Ý kiến trên Hacker News
Agile đã cho thấy một hiện tượng thú vị
Nếu thất bại, người ta sẽ diễn giải theo kiểu “chưa làm đủ”
Tôi cũng thấy cùng một mô thức đó ở cloud, microservices, chính sách thắt lưng buộc bụng — nguyên nhân thất bại luôn là do triển khai chưa đủ, chứ bản thân cách tiếp cận thì tuyệt đối không bao giờ sai
Nếu một đội thử Agile mà không hiệu quả, lập luận phòng thủ sẽ xuất hiện: “đó không phải Agile thật sự”. Rốt cuộc, Agile trở thành một khái niệm không thể thất bại
Agile Manifesto chỉ nói về giá trị và nguyên tắc. Vấn đề là văn hóa tổ chức cố ép nó thành một quy trình
Một cấu trúc khiến người ta nhìn lại nội tâm khi thất bại không hẳn là điều xấu. Xét ở khía cạnh thúc đẩy tự phản tỉnh thay vì đổ lỗi cho bên ngoài, đó thậm chí có thể là một hệ thống lành mạnh
Roadmap đã hứa với khách hàng và khả năng phản ứng linh hoạt rất khó cùng tồn tại. Thực tế chỉ là các tổ chức thiên về kế hoạch đang bắt chước Agile mà thôi
Nếu thất bại thì kết luận lại là “đáng lẽ phải dùng agent nhiều hơn”. Nghe như câu đùa “token thì không bao giờ là đủ”
Tôi đã bắt đầu sợ sự hình thức hóa của Agile
Tôi từng vận hành thành công một đội khoảng 40 người, nhưng Agile thật ra có thể tóm gọn trong đúng bốn câu — con người, phần mềm hoạt động được, hợp tác với khách hàng, và phản ứng với thay đổi
Vấn đề là ‘Agile’ viết hoa rốt cuộc lại biến chất thành một quy trình cứng nhắc
Khi số người tăng lên, việc đồng bộ mục tiêu trở nên khó khăn và cuối cùng vẫn cần kiểm soát cùng thủ tục
Thậm chí còn hạn chế cả quyền tạo ticket, hoàn toàn xa rời tính linh hoạt
Thiếu tài liệu thì không thể bảo trì, và cuối cùng trượt sang kiểu phát triển YOLO
Agile ở các tập đoàn lớn mà tôi từng làm đều là dối trá
Một đồng nghiệp từng nói: “nếu làm trước việc của sprint sau thì lúc nào cũng xong đúng hạn”.
Nói cách khác, Agile vận hành như một hệ thống tạo ra chỉ số hơn là công việc thực tế
Quản lý chỉ nhìn thấy các con số đi lên là hài lòng, còn sản phẩm thì bị hạ xuống thành phụ phẩm của thống kê
Rất đáng để đọc lại nguyên văn Agile Manifesto
Đó là điểm đồng thuận duy nhất. Cần nhớ rằng waterfall trước Agile đã tệ đến mức nào
Nó là vũ khí chấm dứt thời kỳ bị ép buộc vào lịch cố định và đầu ra cố định
Vì nếu đội ngũ làm việc tự chủ thì vị trí của họ sẽ bị đe dọa
Như Kent Beck từng nói trong “Extreme Programming”, Agile là nỗ lực để tránh sự chuyên chế của ảo tưởng toàn năng
Waterfall ngày xưa cố dự đoán mọi thứ ngay ở giai đoạn thiết kế, và phớt lờ học hỏi lẫn phản hồi
Nhưng theo thời gian, nghi thức và hình thức của Agile lại che lấp bản chất của nó
Tôi vẫn thích Agentic programming, nhưng rốt cuộc điều quan trọng vẫn là vai trò của con người trong việc nối kết ngữ cảnh
Bài gốc khiến tôi thấy rối
Bài đó nói Agile không tạo ra điều gì mới, rồi lại khẳng định Agile đã chết vì LLM viết code
Nhưng cốt lõi của Agile là thừa nhận đặc tả không hoàn chỉnh và cải tiến lặp đi lặp lại
Nguyên tắc này vẫn còn nguyên giá trị
Agile chỉ là một biến thể trong số đó, vấn đề chỉ là có quá nhiều cách triển khai tệ
Sản phẩm tốt rốt cuộc vẫn ra đời từ vòng lặp đặc tả → học hỏi → chỉnh sửa
Các thủ tục như Backlog Grooming, Sprint Review lại thành ra ức chế thay đổi
Phát triển dựa trên spec có lẽ sẽ không tồn tại lâu
Làm ra phần mềm chạy được rồi lặp tiếp vẫn nhanh hơn — rốt cuộc lại là sự trở về của Agile
Chất lượng spec đã tốt hơn, và review cũng dễ hơn code
Xem liên kết GitHub
Trong manifesto không hề có những từ như Daily Standup hay Agile Coach
Bản chất của nó là “đừng micromanage lập trình viên”
Tức là thông điệp hãy cung cấp môi trường và sự tin tưởng cho những cá nhân có động lực
Những người sáng lập như Kent Beck, Martin Fowler ban đầu chỉ định tạo ra các hướng dẫn linh hoạt
Nhưng theo thời gian, nó bị thương mại hóa, và những kẻ theo đuổi một cách cuồng tín xuất hiện khiến sự hỗn loạn càng lớn
Thành công hay không rốt cuộc vẫn phụ thuộc vào năng lực và thái độ của con người
Độ dài sprint cũng phải điều chỉnh theo hoàn cảnh, và nếu không có spec thì chính đội ngũ phải tự tạo ra
Ngay cả trong thời đại AI, nếu có những người biết dùng Agile một cách khôn ngoan thì nó vẫn còn giá trị
Tôi từng thắc mắc chính xác “viết spec” nghĩa là gì
Tất cả các dự án Agile tôi từng làm đều có tài liệu thiết kế, và ticket được sinh ra từ các tài liệu đó
Kiểu phát triển dựa trên ticket mà không có tài liệu nghe như địa ngục
Ai cũng diễn giải theo ý mình
Cách tiếp cận xoay quanh ticket lại gần với Agile thuần túy hơn
Agile giả thì coi tài liệu do PO hoặc PM tạo ra như thể đó là chân lý
Cách làm mà bạn nói mới chính là thứ gần nhất với ý nghĩa ‘viết đặc tả’ mà tôi muốn nói tới