Robert “Uncle Bob” Martin là một trong những nhà phát triển có tầm nhìn xa đã tham dự hội nghị The Lodge tại khu nghỉ dưỡng trượt tuyết Snowbird tại Utah Tháng Hai/2001 để thảo luận về các phương pháp phát triển phần mềm lightweight khác nhau hiện thời. Kết quả của hội nghị này được biết đến đó là Tuyên ngôn Agile (Manifesto for Agile Software Development).
Trớ trêu thay, Tuyên ngôn Agile, trong đó giá trị chào đón và phản hồi với các thay đổi, có vẻ là điều duy nhất trong ngành phát triển phần mềm đã không hề thay đổi kể từ khi nó ra đời. Và thậm chí nếu văn bản này cần phải được cập nhật, cũng không có gì trong Tuyên ngôn Agile cho phép điều đó. Phải chăng Tuyên ngôn Agile là thứ không-agile nhất về phát triển? Hay những khái niệm của nó là bất hủ, là linh hoạt mãi mãi, và không cần phải thay đổi?
Tôi đã hỏi Bod để làm sáng tỏ về những gì thực sự đã xảy ra trong hội nghị tại Snowbird, xem ông ấy đánh giá thế nào về di sản của Tuyên ngôn sau 15 năm, và tương lai của phát triển phần mềm nói chung. Nội dung sau đây được viết dựa trên cuộc trao đổi này của chúng tôi.
Hội nghị tại Snowbird
Hội nghị đã bắt đầu với một lời kêu gọi hãy hành động, cụ thể là viết một bản tuyên ngôn, mặc dù không ai biết nó sẽ trông như thế nào, hoặc nó sẽ là một tài liệu lớn hay nhỏ.
Để khởi đầu cho cuộc thảo luận, tất cả những người tham dự viết ra các vấn đề quan trọng nhất đối với họ lên các tấm thẻ chỉ mục. Sau đó họ sắp xếp những tấm thẻ đó theo chủ đề và tìm những vấn đề được đề cập nhiều. Trong suôt các thảo luận tiếp theo, một ai đấy, có lẽ là Ward Cunningham, đã có được cảm hứng để viết ra bốn câu mà sau đó đã trở thành Tuyên ngôn, với quan điểm là họ không phủ nhận những điều ở bên phải, nhưng thấy những thứ bên trái có giá trị hơn. Đây là sự thấu hiểu nhóm, và nó đạt được rất nhiều sự đồng thuận. Bob nói “Đó là điều đã gây ngạc nhiên cho nhóm,” “bởi vì chúng tôi đã không đồng ý với bất cứ điều gì! Chúng tôi đã không bỏ phiếu; có được chỉ là do đồng thuận. Khi bốn câu được viết lên bảng, tất cả chúng tôi nhìn vào chúng và nói, ‘A đây rồi!’”
Sự bất đồng nhất đã qua đó là những gì để gợi lại nó. Bản thân tên của hội nghị là “Hội nghị các Phương pháp Lightweight,” nhưng không ai thích thuật ngữ “lightweight.” Sau khi đề xuất và thảo luận về một số lựa chọn để thay thế cho từ này, họ đã giơ tay đồng ý với gợi ý dùng từ “agile” của Jim Highsmith. Đó là lần bỏ phiếu duy nhất trong suốt hội nghị.
Bản Tuyên ngôn đã ra đời ngay trong ngày đầu tiên của hội thảo. Ngày thứ hai, nhóm mở rộng phạm vi của Tuyên ngôn với 12 nguyên tắc, chúng được đàm phán sau đó qua email, quá trình này diễn ra trong vài tháng.
Các di sản ngạc đáng nhiên của Tuyên ngôn Agile
Những người tham dự đã có một vài kỳ vọng sau hội nghị. Họ đã nghĩ rằng một số người đã đọc Tuyên ngôn, và có lẽ một số bài viết đã được công bố, nhưng nó đã mờ nhạt, giống như nhiều phong trào khác trong phần mềm. Nhưng thực sự đã rất khác. “Thật kinh khủng, nó đã vượt quá bất cứ điều gì mà tôi đã kỳ vọng”, Bob nói. “Đồ thị áp dụng tiếp đi lên với tốc độ rất nhanh, với ngày càng nhiều người làm agile.” Hầu hết mọi người trong cộng đồng IT đã tham gia vào ít nhất một vài thử nghiệm về agile, và tốc độ áp dụng tiếp tục tăng. Bob dự đoán rằng đường cong tăng trưởng sẽ tiếp tục hướng tới điểm mà mọi người đều sẽ dùng agile, mặc dù nó sẽ mất chừng 20 đến 30 năm. Chúng ta không còn sống tới đó nữa.
Điều đó cho thấy rằng, ngày nay agile không giống với agile đã được thảo luận tại hội nghị nữa. Đã có một sự chuyển hướng sang lĩnh vực kinh doanh, và các ngành khác với công nghệ, điều đã được xem là rất quan trọng tại hội nghị. Bob nhớ lại Kent Beck đã nói tại hội nghị Snowbird rằng động cơ của anh ấy phía sau eXtreme Programming, hay XP, “là để hàn hàn gắn sự phân chia giữa lập trình, hay công nghệ, với kinh doanh. Và sự phân chia đó không được hàn gắn, ít nhất là không chủ đạo bởi.” Cộng đồng agile đã được chuyển giao bởi các quản lý dự án (PM) và các ScrumMaster (SM), điều này có nghĩa rằng khía cạnh công nghệ phương trình của Beck đã bị bỏ rơi bởi một phần lớn của phong trào agile. Bob thực sự lo ngại về điều này. Các chuyên gia công nghệ đã tạo ra phong trào software craftsmanship (nghề thủ công phần mềm) để điều chỉnh cân bằng, do đó các khái niệm lập trình cặp (pair programming), phát triển hướng kiểm thử (test-driven development -TDD), và kiểm thử chức năng ngày càng phổ biến trong các nhóm phát triển, mặc dù họ bị che khuất bởi sự coi trọng quản lý dự án (PM) điều mà dường đã làm choáng ngợp mọi người.
Trong khi cộng đồng phần mềm đã có sự tập trung vào agile trong những năm gần đây với quy mô rộng, Bob đã nói rằng hội nghị đã không chú tâm một cách rõ ràng đến agile với quy mộ mở rộng. Mặc dù ông ấy hoài nghi về khái niệm. “Tôi nghi ngờ một số thứ khi áp dụng agile với quy mô lớn. Điều có thể là chỉ nên áp dụng agile ở quy mô nhỏ, và thậm chí trong một tổ chức lớn bạn thực hiện một loạt các nhóm agile rất nhỏ.”
Tương lai của agile
Như tôi đã lưu ý trước đó, Tuyên ngôn Agile đã không thay đổi sau 15 năm ra đời. Tôi đã gợi ý Bob rằng có thể nguyên tắc thứ ba nên cập nhật lại, bởi vì nó giới hạn tần suất chuyển giao phần mềm sau “một vài tuần.” Ngày nay, DevOps và các chu kỳ chuyển giao liên tục – cho phép một số nhóm phát hành nhiều phần mềm trong một ngày – không khiến khoảng thời gian hai-tuần nghe vẻ khá kỳ quặc chăng? “Vào thời điểm năm 2001, chúng tôi có thể không hình dung làm mọi thứ nhanh hơn một vài tuần,” Bob nói. “Tom Gilb là một người có thể trong cộng đồng, nhưng anh ấy đã không bày tỏ tại hội nghị. Chúng tôi đã nghĩ rằng hai tuần là một giới hạn thấp và không ai bận tâm để thách thức điều này, và đó rõ ràng là đã thiển cận.”
Tuy nhiên, Tuyên ngôn không có khả năng thay đổi. Để bắt đầu, không có quy trình tại chỗ để cho phép nó được thay đổi, và không có điều khoản nào được đưa ra để cho phép thay đổi nó. “Nghĩ về Tuyên ngôn khi kêu gọi phải hành động tại một thời điểm, và không có một kịch bản về cách xử lý,” Bob nói. “Nó là một thời điểm chứ không một kỷ nguyên.”
Hiện nay: Chúng ta có cần các tiêu chuẩn về đạo đức không?
Những người tham dự hội nghị Snowbird là một số lãnh đạo tư tưởng lúc đó và tiếp tục có ảnh hướng lớn. Có ai ngoài Bob nghĩ rằng chúng ta nên chú ý đến ngày hôm nay không? Thay vì chỉ rõ các tên tuổi, ông ấy giải thích rằng ông lo ngại phát triển phần mềm không có một vị thế nghề nghiệp và thiếu một bộ thống nhất về tiêu chuẩn nghề. Chúng ta đã biết phần mềm động chạm đến tất mọi lĩnh vực cuộc sống và đã trở nên gắn kết với xã hội của chúng ta, chúng ta không thể sống mà không có nó.
“Phần mềm đang được viết bởi một lượng lớn những người mà không hề đồng thuận với một tiêu chuẩn đạo đức. Vì vậy chúng ta thấy những thứ giống vụ bê bối của Volkswagen, đó là điều vô cùng đáng sợ. Nếu điều đó mà tiếp tục, xã hội của chúng ta rất có khả năng phải đòi hỏi một số quy định. Và nếu xã hội chỉnh lý chúng ta trước khi chúng ta điều chỉnh bản thân mình, nó sẽ là một thảm họa. Do đó tôi muốn đặc biệt chú tâm đến những người đang tập trung vào những vấn đề về trách nhiệm của chúng ta với xã hội. Đạo đức của chúng ta là gì? Sự chuyên nghiệp của chúng ta là gì? Những lập trình viên, chúng ta là ai? Chúng ta phải có những quy tắc gì, và chúng ta làm sao để thực thi chúng?”
Một lát cắt thời gian
Bức ảnh nền trong website Tuyên ngôn Agile là một bức ảnh được chụp bởi Ward Cunningham, về một số người tham dự Snowbird đang vây quanh một cái bảng trắng. Nhưng bức ảnh đã được xử lý, để không thấy gì được viết trên bảng trắng. Bob đã nói với tôi đó là nội dung của bản Tuyên ngôn, ở thời điểm hoàn chỉnh hoặc khá gần thời điểm đó.
Năm ngoái, ông ấy đã ở Utah và quay lại The Lodge tại Snowbird. Ông ấy đã thấy căn phòng giống như năm 2001. Ông ấy đã viết nội dung của Tuyên ngôn lên chiếc bảng cũ và chụp một bức ảnh về nó. Ông ấy vui vẻ chia sẻ bức ảnh với tôi vậy nên tôi có thể công bố nó ở đây để tất cả chúng ta cùng chiêm ngưỡng.
[ms_section background_color=”#ddc49b” background_image=”” background_repeat=”repeat” background_position=”top left” background_parallax=”no” border_size=”” border_color=”#dd8500″ border_style=”none” padding_top=”10px” padding_bottom=”10px” padding_left=”10px” padding_right=”10px” contents_in_container=”no” top_separator=”” bottom_separator=”” class=”” id=””]Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện.
Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:
Cá nhân và sự tương tác hơn là quy trình và công cụ;
Phần mềm chạy tốt hơn là tài liệu đầy đủ;
Cộng tácvới khách hàng hơn là đàm phán hợp đồng;
Phản hồi với các thay đổi hơn là bám sát kế hoạch.
Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái.[/ms_section]
Malcolm Isaacs – techbeacon.com – Dịch: Nguyễn Việt Khoa
