Tuyên ngôn Agile là một trong những văn bản có tác động lớn rất lớn tới cuộc sống của tôi trong gần 15 năm qua. Kể từ dự án đầu tiên sử dụng User Story, đọc sách của Mike Cohn cho đến những ngày phát triển cộng đồng HanoiScrum, Agile Vietnam, mở các hội thảo Agile vào đầu 2010s, thúc đẩy đào tạo agile software development tại khối giáo dục FPT, sau đó là hoạt động đào tạo-tư vấn tại Học viện Agile, Tuyên ngôn Agile đã đồng hành trên từng bước đi.
Tôi biết rằng rất nhiều người cũng “chịu ơn” Agile nhiều vì nó đã làm thay đổi nhân sinh quan, thay đổi cách làm, mang lại kết quả tuyệt vời trong công việc và cuộc sống của họ.
Tôi đã viết “Agile mọi thứ” và nhiều lần đề cập tới điều này trong nhiều diễn đàn.
Hết năm 2020 đầy biến động này, Agile Manifesto sẽ tròn 2 thập kỉ ra đời, cũng là 2 thập kỉ Agile tác động thay đổi thế giới. Nó đã đi một chặng đường dài để tạo tác động lớn. Bạn và tôi lại cùng giở Tuyên ngôn Agile và cùng đọc lại để ôn cố tri tân, có lẽ cũng hữu ích.
| Tuyên ngôn Agile 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à 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ác với khách hàng hơn là đàm phán hợp đồng; Phản hồi với 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. |
Chuyện dịch Tuyên ngôn ra tiếng Việt
Là người đầu tiên dịch Agile Manifesto ra tiếng Việt, và theo dõi những bản dịch sau đó của một vài người khác, tôi rất để ý đến cách chuyển ngữ. Tôi nhận thấy một số bản dịch lỗi, có lẽ là do hiểu sai Tuyên ngôn với việc dùng chữ “thay vì” chứ không phải “hơn là” trong câu “cá nhân và tương tác thay vì quy trình và công cụ”. Dịch ra như thế là do chuyển ngữ sai từ “over” (hơn là) thành “thay vì”. Có lẽ nguyên do là không đọc kĩ dòng cuối của văn bản: bên phải vẫn có giá trị, nhưng bên trái có giá trị hơn. Viết “thay vì” thì tức là vứt cái bên phải đi, như thế là hỏng. Ví như phủ nhận sạch trơn quy trình và công cụ, phủ nhận việc tài liệu hóa, phủ nhận việc làm kế hoạch. Vận dụng kiểu đó thì chỉ có thể dẫn đến thảm họa trong thực tiễn thôi. Một số bản dịch thậm chỉ chỉ dịch bốn dòng ở giữa khiến cho ý nghĩa của văn bản vốn đã rất tinh gọn không còn nguyên vẹn được nữa.
Khi dịch văn bản này vào khoảng 2010, tôi có tranh luận với một anh bạn ở chữ “cá nhân” (individual). Bạn tôi, là một người rất mực thông minh đã gợi ý nên dịch là “con người” cho nó dễ hiểu. Tôi suýt nghe theo, nhưng nghĩ lại thấy thật không đủ tốt khi dịch “Con người và tương tác…”. Nó làm sai ý của Tuyên ngôn. “Cá nhân” tức là người trưởng thành có thể tự chịu trách nhiệm, tức là tự chủ, được trao quyền. “Cá nhân” kết hợp với “Tương tác” thì ra hoạt động đội nhóm hiệu quả (team). Cho nên, dịch trung thực với nguyên tác là “Cá nhân” thì mới giữ được cái ý tinh tế gốc. Đấy là chưa kể trong “12 nguyên tắc phía sau Tuyên ngôn” có ghi nguyên tắc số 5: “Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.” Một đội gồm toàn cá nhân không có động lực, bảo gì làm nấy, hết việc ngồi chơi chờ giao việc mới, hoặc tệ hơn là “bảo ngồi lại nằm”, thì rất khó hoàn thành được việc gì ra hồn. Chữ “cá nhân” nó đắt hơn chữ “con người” chung chung. Càng quan sát các nhóm làm việc, tôi càng thấy vai trò của cá nhân thật là quan trọng. Cá nhân thiếu năng lực, thiếu nhiệt tình, tư duy tiêu cực thì đội nhóm phải “gánh” đủ thứ. Agile là cách thức tốt hơn để các cá nhân được đóng góp nhiều hơn cho mục tiêu chung của nhóm chứ không phải là loại bỏ vai trò và trách nhiệm cá nhân trong đội hình.
Trong văn bản này có câu đầu rất đắt, nhưng hình như ít được chú ý. “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“. Tuyên ngôn ra đời từ thực tiễn, thực hành và giảng dạy. Agile không ra đời từ “bàn giấy” mà tự thực địa và tinh thần chia sẻ. Đó cũng là tinh thần thần empiricism (thực nghiệm) của Agile.
Những Tuyên ngôn phái sinh
Sau 20 năm, đã có nhiều thảo luận về Tuyên ngôn Agile, và có nhiều người đặt vấn đề “làm mới”. Ngoài các phiên bản tuyên ngôn “nhái” trong các lĩnh vực marketing, giáo dục… thì cũng có những nỗ lực làm mới Tuyên ngôn Agile. Thực tế là có những phiên bản mới được đề xuất, như Tuyên ngôn Nghề thủ công Phần mềm được nhiều người kí vào.
| Tuyên ngôn Nghề thủ công Phần mềm Với tư cách của những Nghệ nhân Phần mềm đầy khao khát, chúng tôi đang nâng tầm ngành phát triển phần mềm chuyên nghiệp bằng cách thực hành và giúp đỡ người khác học tập bí quyết nhà nghề. Qua đó, chúng tôi đã đi đến đề cao: Không chỉ phần mềm chạy tốt, mà còn phần mềm tinh xảo. Không chỉ phản hồi với thay đổi, mà còn tạo giá trị liên tục. Không chỉ cá nhân và tương tác, mà còn cộng đồng chuyên nghiệp. Không chỉ cộng tác với khách hàng, mà còn mối quan hệ đối tác bền chặt. Trong khi theo đuổi các giá trị ở bên trái, chúng tôi đã nhận thấy các giá trị được liệt kê ở bên phải là không thể thiếu được. |
Hoặc Hậu Tuyên Ngôn Agile do Kent Beck phóng tác (2011), với bốn điểm cốt lõi được bổ sung các ưu tiên mới:
| Tầm nhìn nhóm và kỉ luật, hơn là cá nhân và tương tác (hơn là quy trình và công cụ) Học hỏi có kiểm chứng hơn là phần mềm chạy tốt (hơn là tài liệu hóa đầy đủ) Khám phá khách hàng hơn là cộng tác với khách hàng (hơn là đàm phán hợp đồng) Kiến tạo thay đổi hơn là phản hồi với thay đổi (hơn là bám sát kế hoạch) |
Ngay cả bản thân tôi, có lúc tôi cũng muốn chế ra một cái Tuyên ngôn Agile phiên bản cá nhân với một số chỗ được chỉnh sửa (khá là cơ học) cho phù hợp với đời sống rộng mở hiện nay, đại để như sau:
| Triết lí Linh hoạt giúp mọi người hoàn thành công việc, với ưu tiên: Cá nhân và tương tác hơn là quy trình và công cụ, Giải pháp hiệu quả hơn là tài liệu hóa đầy đủ, Cộng tác với khách hàng hơn là đàm phán hợp đồng, Thích ứng chủ động với 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 các mục bên trái quan trọng hơn. *** Những triết lí bên trên được cụ thể hóa bằng 12 nguyên tắc chỉ đường cho hành động như liệt kê dưới đây: 1. Ưu tiên cao nhất là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các giá trị cho họ. 2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình hợp tác. Cách làm việc phải tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. 3. Thường xuyên chuyển giao giá trị tới khách hàng, từ vài ngày, vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn. 4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau liên tục trong suốt dự án. 5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. 6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. 7. Giá trị chuyển giao được là thước đo chính của tiến độ.Các quy trình linh hoạt thúc đẩy phát triển bền vững. 8. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn. 9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt. 10. Sự đơn giản là căn bản. 11. Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự quản có đủ năng lực. 12. Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. |
Tuy vậy, như bài nghiên cứu “Back to the future: origins and directions of the “Agile Manifesto” – views of the originators” chỉ ra, bản thân các tác giả của Tuyên ngôn Agile không mặn mà gì với việc cập nhật văn bản này cho hợp mốt, sau 2 thập kỉ. Họ coi đó là một phần của lịch sử, và phần lớn những gì được viết ra cũng không cần sửa để có thể phù hợp với thời đại ngày nay. Cũng theo nghiên cứu này, Tuyên ngôn Agile không ra đời từ một phát “đột khởi” năm 2001, mà là một quá trình tiệm tiến từ những năm 1930s, tích lũy các tri thức trong suốt các thập niên sau đó, nhất là các thập niên 1980s, rồi tiếp đến là một lộ trình dài tiến hóa từng phương pháp gọn nhẹ (light weight) riêng rẽ trong thập niên 1990s, để rồi hội tụ lại trong một văn bản mô tả triết lí cốt lõi Agile vào đầu thế kỉ mới.
Sau thời điểm ra đời Tuyên ngôn Agile, các tác giả của nó cũng không thể tưởng tượng được sự phổ biến nhanh chóng (cả theo hướng tích cực lẫn tiêu cực) như hiện nay. Agile ngày nay đã không còn là của riêng các lập trình viên nữa, mà còn của mọi người.
Do đó, nếu ai đó thấy thích “sống kiểu linh hoạt” (being agile) thì có thể lấy Tuyên ngôn như là điểm bắt đầu và lựa chọn cho mình nguyên tắc cơ bản thay vì tìm tới nó như là văn bản đầy đủ, cập nhật và mang tính “cẩm nang”. Dù gì thì chúng cũng nhấn mạnh tới các ý tưởng cơ bản về trao quyền, bỏ bớt tính quan liêu trong làm việc, hợp tác hiệu quả các bên (đội kĩ thuật – kinh doanh – khách hàng) để chuyển giao giá trị sớm và thường xuyên cho khách hàng, học hỏi nhanh và phản hồi chủ động và hiệu quả với sự thay đổi của môi trường bên trong bên ngoài. Đó là những “giá trị” lớn trong bối cảnh phức hợp và biến động thường xuyên (như một hai thập kỉ gần đây, và sắp tới).
Những mẩu vụn Agile khác
Agile và agile
Khởi thủy chỉ có agile với chữ a viết thường. Nó ám chỉ một cách làm việc linh hoạt, gọn nhẹ và tạo ra kết quả. Nó ám chỉ cái “tinh túy” linh hoạt với nội hàm như được mô tả trong Tuyên ngôn. Sau thì lại sinh ra Agile viết hoa, ám chỉ một họ các phương pháp/kĩ thuật, hoặc một dòng tư duy về làm phần mềm và quản lí/lãnh đạo. Nó trở thành nhãn hiệu. Nhờ có nhãn hiệu, lại được quảng bá mạnh, cộng với một cộng đồng chuyên môn ngày càng dày, người ta chỉ còn viết Agile. Thậm chí nhiều cái tên phương pháp có thể gắn chữ Agile, nhưng chưa chắc nó đã giữ trong mình cái linh hồn linh hoạt như cũ. Nó được gắn vào để “bán hàng”.
Ngay cả cái tên một tổ chức Học viện Agile thì chữ A viết hoa, đôi khi bị người ta gọi nhầm mãi “cái bọn Agile” mà không cần biết gì về cái nghĩa gốc “agile”-linh hoạt khởi thủy cả. Agile ở chỗ này là một danh từ, một thương hiệu, một cái tên để gọi. Nhưng thương hiệu này vẫn còn liên quan, vì nó là tổ chức nghiên cứu, giảng dạy, và tư vấn về Agile.
Scrum và XP và hơn thế nữa
Ở thời điểm 2000 thì Scrum chưa phổ biến. Phương pháp linh hoạt nổi tiếng nhất thời kì ấy là XP chứ không phải Scrum. Nhưng sau 1 thập kỉ thì đã khác hẳn: XP ít được nhắc đến dần trong khi Scrum thì nổi lên. Sau 2 thập kỉ thì người ta thậm chí nhầm Scrum chính là Agile, và Agile chỉ có mỗi Scrum. Thống kê của VersionOne (nay là Digital.ai) hằng năm về tình hình vận dụng Agile, thì quá 3/4 các nhóm khai mình đang dùng phương pháp Scrum.
Sự lớn mạnh của Scrum góp công lớn vào việc mở rộng biên giới Agile ra khỏi phạm vi đội phần mềm. Do được thiết kế như là một khung quản lí tổng quát, Scrum có thể được lắp vào hầu như mọi lĩnh vực. Nó đã mang được các giá trị Agile vào từng ngóc ngách của cuộc sống. Nhưng sự chú ý quá nhiều vào phương diện tổ chức công việc có thể khiến cho sự chú ý vào phương diện kĩ thuật có thể bị giảm đi trông thấy. Và đó cũng là thứ nhiều người lo ngại về một phong trào.
Trong khi có hàng tá khóa đào tạo Scrum, chứng chỉ Scrum đã trao cho hàng nghìn người, thì ở Việt Nam trong 2 thập kỉ qua, sự thảo luận về XP, các hội thảo về XP rất ít. Các cuộc đào tạo chuyên môn đang nghiêng về phần ScrumMaster, Quản trị dự án Agile, mà thiếu vắng phần kĩ thuật sản phẩm, công nghệ. Đây có thể là một “khiếm khuyết” thị trường, vì các lực thị trường dẫn đến không khuyến khích trao đổi và cải thiện tri thức về kĩ thuật. Không có kĩ thuật mạnh, thì dù quản lí có tốt cũng không thể tạo ra sản phẩm có giá trị lớn được. Đó là cái nền.
Ta cứ tưởng đã hết chuyện để nói về Agile rồi, nhưng sự thật là vẫn còn lâu mới đến ngày đó.
Mở rộng ra, nhiều mong muốn chủ đạo của các tác giả khi khởi thảo Tuyên ngôn Agile cho tới nay dường như vẫn còn là chuyện chưa được hiện thực hóa:
- Agile phải thúc đẩy sự môi trường an toàn cho các nhà phát triển sáng tạo giá trị (các developer vẫn chịu sức ép lớn từ phía kinh doanh)
- Agile phải nuôi dưỡng được những nhà lập trình yêu nghề, tinh nghề, và tạo ra sản phẩm tuyệt hảo (tình trạng nghề lập trình vẫn là nghề còn mới, chưa “chín”, craftsmanship chưa được coi trọng)
- Agile phải kéo những bên liên quan gần nhau hơn (thực tế là các bên còn chưa ngồi lại với nhau)
Chưa kể sự thiếu vắng khả năng tích hợp phần phát triển sản phẩm với với phần còn lại trong một tổ chức (kinh doanh, tổ chức, quản trị….) để hình thành đầy đủ một lối làm việc mới trơn tru.
Ở ta, còn ít diễn đàn và thảo luận về DSDM, LSD, Business Agility, Agile Leadership, Agile Management, Agile Organziation…
Thực tế đang đòi hỏi lỗ hổng về “chuyên môn Agile” cần phải được lấp đầy dần.
Việt Nam linh hoạt
Từ 10 năm trước đã có Agile Vietnam như là một cộng đồng sinh hoạt đã khá sôi nổi. Hằng năm vẫn diễn ra sự trao đổi học thuật giữa AgileVietnam và một số ít ỏi chuyên gia thế giới (trong số đó có cả những người gạo cội như Ken Schwaber, Bas Vodde, Martin Fowler, Mary Poppendieck…) nhưng chủ yếu theo hướng “tiếp thu” một chiều.
Độ phủ của Agile lên riêng ngành IT chưa lớn. Cả đội kĩ thuật lẫn quản lí phần lớn vẫn còn lạ lẫm và lóng ngóng với Agile. Trong các ngành khác, Agile vẫn còn ngấp nghé đứng ngoài cửa.
Sau một thập kỉ, có lẽ cộng đồng cần bước chuyển lớn chăng. Nhất là trong thời đại chuyển đổi số, tốc độ thay đổi chóng mặt hơn, và khuôn mặt thời đại TUNA\VUCA dễ cảm nhận hơn bao giờ hết.
Cần một một cuộc phổ cập Agile về chiều rộng, và một sự phát triển sâu về chuyên môn Agile cho từng lĩnh vực. Một cuộc agile-hóa sâu rộng.
Tham khảo và đọc thêm:
