20 năm Agile: cuộc nổi loạn thất bại
(simplethread.com)<p>- Đã 20 năm trôi qua kể từ khi Agile Manifesto (Tuyên ngôn Agile) được công bố, và hiện có hai sự thật rất rõ ràng:<br />
1. Agile đã thắng ở việc gắn nhãn tên gọi. Không ai muốn bị gọi là non-Agile<br />
2. Nhưng trong việc thực thi Agile, kết quả còn kém xa so với ý tưởng mang tính cách mạng của các nhà sáng lập<br />
- “Ai cũng nói mình làm Agile, nhưng gần như chẳng có mấy ai thực sự Agile.” Vì sao lại thành ra như vậy?<br />
<br />
[ Whence The Manifesto : Tuyên ngôn bắt đầu như thế nào ]<br />
- Tháng 2/2001, một nhóm gồm 17 chuyên gia phần mềm đã họp tại một khu nghỉ dưỡng trượt tuyết ở Utah<br />
- Sau vài ngày thảo luận, họ cùng nhau viết nên “Agile Software Development Manifesto”<br />
<br />
- Điểm quan trọng là họ là những “practitioner (người làm thực tế)”. Họ không phải PM, CTO hay VP Eng. Họ là developer, programmer, scientist và engineer. Khi đó họ vẫn đang trực tiếp viết code, hợp tác với các bên liên quan để giải quyết vấn đề. Điều này thực sự rất quan trọng.<br />
- Một điểm khác là Agile Manifesto không được tạo ra từ con số 0. Nhiều người trong số họ đã có sẵn các phương pháp do chính mình tạo ra hoặc đang truyền bá. <br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming <br />
<br />
- Tất cả mọi người trong nhóm đều có nhiều kinh nghiệm phát triển phần mềm, và họ đang tìm kiếm thứ có thể thay thế quy trình phát triển phần mềm nặng nề, thiên về tài liệu, vốn là dòng chủ đạo của thị trường khi đó.<br />
- Trọng tâm của tuyên ngôn là bốn giá trị cốt lõi<br />
<br />
“Chúng tôi đang khám phá những cách tốt hơn để phát triển phần mềm, bằng cách trực tiếp làm việc đó và giúp người khác làm việc đó. Thông qua công việc này, chúng tôi đi đến chỗ coi trọng:<br />
- cá nhân và tương tác (Individuals and interactions) hơn quy trình và công cụ (processes and tools)<br />
- phần mềm chạy được (Working software) hơn tài liệu toàn diện (comprehensive documentation)<br />
- hợp tác với khách hàng (Customer collaboration) hơn đàm phán hợp đồng (contract negotiation)<br />
- phản hồi với thay đổi (Responding to change) hơn làm theo kế hoạch (following a plan)<br />
Tức là, dù những thứ ở vế trái cũng có giá trị, chúng tôi đánh giá cao hơn những thứ ở vế phải.”<br />
<br />
[ A New Hope : Hy vọng mới ]<br />
- Từ góc nhìn của năm 2021, thật dễ để xem các thực hành phát triển phần mềm hiện đại là điều hiển nhiên, nhưng vào năm 2001 những ý tưởng này cực kỳ cấp tiến.<br />
- Bắt đầu phát triển phần mềm trước khi thu thập toàn bộ yêu cầu và đánh giá mọi tính năng ư? Điên rồi!<br />
- Một điều quan trọng đang dần bị quên đi là lúc ban đầu Agile công khai và mang tính đối đầu với quản lý một cách mạnh mẽ.<br />
<br />
- Ví dụ, Ken Schwaber, đồng sáng lập Scrum, từng chủ trương loại bỏ toàn bộ project manager; không chỉ rút PM khỏi dự án mà còn nên xóa bỏ hẳn nghề đó khỏi cả ngành.<br />
<br />
“Chúng tôi nhận ra rằng vai trò của project manager là phản tác dụng trong những công việc phức tạp và sáng tạo. <br />
Tư duy của project manager, thể hiện qua project plan, <br />
không phải là tập hợp trí tuệ của mọi người để giải quyết vấn đề theo cách tốt nhất, <br />
mà là giới hạn sự sáng tạo và trí tuệ của mọi người vào những gì được viết trong kế hoạch.”<br />
<br />
- Scrum master gần như không có quyền lực, cũng không có quyền biểu quyết trong các vấn đề. Họ là servant leader*, bảo vệ nhóm và dọn chướng ngại vật, nhưng không quản lý nhóm. <br />
→ servant leader: nhà lãnh đạo phục vụ, hỗ trợ sự trưởng thành và phát triển của cấp dưới, xây dựng niềm tin giữa lãnh đạo và cấp dưới để họ tự nguyện đóng góp vào mục tiêu của tổ chức <br />
- Trong XP ban đầu cũng có Tracker và Coach, hoạt động theo cách tương tự. <br />
<br />
- Alistair Cockburn, người tạo ra Crystal và kiến trúc Hexagonal, gần đây từng nói như sau trong một thread trên Twitter <br />
“Scrum đã tạo ra một thỏa thuận cực lớn trong vùng đất thù địch:<br />
- ban điều hành có thể đổi hướng theo ý mình 12 lần một năm, sau mỗi sprint<br />
- team có được một tháng hoàn toàn yên tĩnh, không bị ngắt quãng hay đổi hướng, để làm những suy nghĩ và công việc nặng ký <br />
- team có thể tuyên bố trong buổi Bid (để xác định ưu tiên) những gì có thể và không thể làm trong một tháng, mà không bị ban điều hành can thiệp<br />
- chưa từng có ban điều hành nào có được một thỏa thuận tốt hơn thế<br />
- cũng chưa từng có team phát triển nào có được một thỏa thuận tốt hơn thế<br />
”<br />
(Ghi chú dịch giả: thread này bắt đầu từ câu hỏi “Ý tưởng rằng scrum team phải hoàn thành 100% tất cả item được phân vào sprint thì đến từ đâu vậy? Điều đó thật vô lý.” Tôi khuyên nên đọc toàn bộ thread gốc.)<br />
<br />
- Tôi là certified scrum master và đã làm việc trong các team Agile hơn 15 năm, cũng đã đọc nhiều cuốn sách nổi tiếng trong lĩnh vực này, nhưng chưa từng thấy ý tưởng về Scrum được giải thích rõ ràng và súc tích đến vậy. <br />
- Scrum được tạo ra để hoạt động trong môi trường thù địch. Nó là một dạng khế ước giữa các developer cần thời gian để suy nghĩ, khám phá và những nhà quản lý mang tính áp đặt.<br />
<br />
[ The Empire Strikes Back : Đế chế phản công ]<br />
- Ở một khía cạnh nào đó, Agile là một phong trào lao động từ cơ sở. Nó bắt đầu từ những người làm thực tế rồi lan lên tới cấp quản lý. Vậy làm sao nó thành công được?<br />
- Một phần là vì số lượng developer tăng lên và giá trị họ mang lại cho doanh nghiệp cũng tăng theo<br />
- Lý do lớn hơn là mô hình phát triển waterfall truyền thống không còn vận hành hiệu quả<br />
- Khi phần mềm trở nên phức tạp hơn, tốc độ kinh doanh nhanh hơn và người dùng hiểu biết hơn, việc lên kế hoạch trước cho mọi thứ trở thành điều bất khả thi.<br />
- Việc chấp nhận phát triển lặp là hợp lý, nhưng với những nhà quản lý vốn quen lập kế hoạch cho mọi thứ thì điều đó hơi đáng sợ. <br />
<br />
- Đến giữa những năm 2000, giới quản lý vẫn chưa thực sự chấp nhận điều này. <br />
- Rồi bắt đầu xuất hiện kiểu suy nghĩ: “Thử cái ý tưởng điên rồ mà đám engineer cứ nói mãi xem sao. Đằng nào chúng ta cũng không kịp deadline, có thể tệ đến mức nào nữa?”<br />
- Nhưng bất ngờ là nó bắt đầu hoạt động. Ban đầu team có hơi co cụm lại (và chậm), nhưng dần dần khi hiểu ra kiểu mẫu nào phù hợp với từng team thì tốc độ bắt đầu tăng lên.<br />
- Sau vài sprint, họ nhận ra sức mạnh của phần mềm chạy được, của hợp tác, của việc dành thời gian để kiểm tra và thích nghi, và của việc ưu tiên những điều đó lên trên mọi thứ khác.<br />
<br />
- Trong khoảng 5 năm, Agile chuyển từ một phương pháp “nghe nói tới” thành thứ mà ai cũng biết, dù không phải ai cũng quen thuộc. <br />
- Năm 2005, Agile và TDD là yếu tố tạo khác biệt thực sự <br />
- Đến năm 2010, các team phần mềm hiện đại hầu như đều làm Agile dưới hình thức nào đó.<br />
- Ít nhất là trong ngành tư vấn, đó từng là một bong bóng. Dù các tập đoàn lớn vẫn luôn chuyển động chậm hơn.<br />
<br />
“Chúng ta đã làm được! Chúng ta đã thắng! Hãy cùng chúc mừng”<br />
Đó là phần kết của câu chuyện, và bạn có thể đóng tab trình duyệt lại rồi.<br />
<br />
“Winning was easy, young man. Governing’s harder.”<br />
“Chiến thắng thì dễ, chàng trai trẻ. Cai quản mới khó hơn.” <br />
→ George Washington như được khắc họa trong vở nhạc kịch Hamilton<br />
<br />
- Đáng tiếc là, cũng như nhiều cuộc cách mạng khác, lịch sử của Agile đã không diễn ra theo cách mà những người sáng lập hình dung.<br />
→ Hóa ra việc ưu tiên “cá nhân và tương tác” là một khái niệm khó đem đi bán hoặc thuyết phục. Bán quy trình và công cụ thì dễ hơn nhiều.<br />
(Ghi chú dịch giả: ở đây Sell mang nghĩa thuyết phục người khác hiểu và chấp nhận hơn là bán theo nghĩa thương mại, nên được giữ nguyên.)<br />
→ Hóa ra “phần mềm chạy được” khó làm ra hơn các kế hoạch phi thực tế và đống tài liệu dày cộp.<br />
→ “Hợp tác với khách hàng” đòi hỏi sự tin tưởng và vulnerability, nhưng điều đó không phải lúc nào cũng có trong kinh doanh.<br />
→ “Phản hồi với thay đổi” thường bị đặt dưới sức nặng của giới quản lý, những người phải lập kế hoạch dài hạn và duy trì kiểm soát.<br />
<br />
“Hóa ra khi Agile không được thực hiện đúng cách thì nó thường trông như hỗn loạn”<br />
<br />
- Nhưng điều đó không có nghĩa bốn giá trị này là sai<br />
- Nó có nghĩa là để mọi thứ vận hành đúng thì cần một chút nỗ lực, và cần cả sự can đảm để chấp nhận rằng phần mềm vốn dĩ lộn xộn và hỗn độn. <br />
- Cần phải hiểu và tin rằng, nếu tiếp tục học hỏi, thích nghi, cải thiện và phát hành, cuối cùng bạn sẽ đến được một nơi tốt hơn rất nhiều so với waterfall — một nơi trung thực hơn, thực tế hơn và năng suất hơn nhiều.<br />
<br />
“Phong trào Agile không phải là phản-phương-pháp (anti-methodology). <br />
Thực tế, nhiều người trong chúng tôi muốn khôi phục lại niềm tin vào từ ‘methodology’. Chúng tôi muốn khôi phục lại sự cân bằng. <br />
Chúng tôi đón nhận modeling, nhưng không phải để nhét sơ đồ vào một kho công ty phủ bụi. <br />
Chúng tôi chấp nhận documentation, nhưng không phải những cuốn sách dày hàng trăm trang, không được bảo trì và hầu như chẳng ai dùng. <br />
Chúng tôi có lập kế hoạch, nhưng nhận thức được giới hạn của kế hoạch trong môi trường biến động mạnh. <br />
Những ai gắn nhãn những người ủng hộ XP, Scrum hay các phương pháp Agile khác là ‘hacker’ thì đơn giản là không hiểu định nghĩa gốc của các từ ‘methodology’ và ‘hacker’. ”<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Đây chính là những điểm quan trọng. Chúng ta vẫn lập kế hoạch và viết tài liệu, và vẫn phải nghiêm túc với Agile. Đây là câu chuyện về sự cân bằng.<br />
- Nhưng nếu tổ chức của bạn đang chật vật với chuyển đổi Agile và rơi vào hỗn loạn, thì khi ai đó ném cho bạn một chiếc phao cứu sinh như chứng chỉ, quy trình hay công cụ, bạn rất dễ nhảy sang đó.<br />
- Giới quản lý hiểu quy trình và công cụ tốt hơn rất nhiều so với “team tự tổ chức”. <br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One trở lại ]<br />
- Đến đây thì cấu trúc ba hồi của tôi hơi sụp đổ một chút. Vì tôi không thấy có những quân nổi dậy dũng cảm nào quay lại mà không mang tên Agile<br />
(Ghi chú dịch giả: tác giả đang mượn tên loạt phim Star Wars để nói rằng không có thứ gì khác không phải Agile thực sự xuất hiện thay thế.)<br />
<br />
- Các vendor công cụ, tư vấn quy trình và chuyên gia thường hứa hẹn những điều mà họ tuyệt đối không thể cung cấp.<br />
- Đó là lý do chúng ta có SAFe (Scaled Agile Framework for Enterprise), Scaled Scrum và các phiên bản Agile cho doanh nghiệp khác.<br />
- Những framework này không được tạo ra với ác ý, và có lẽ trong bối cảnh phù hợp chúng cũng có giá trị nhất định.<br />
- Nhưng tôi sẽ không gọi chúng là Agile<br />
- Nếu bạn cố mở rộng một phương pháp đặt trọng tâm vào cá nhân và tương tác, thì sớm muộn cũng phát sinh vấn đề và các giá trị nguyên bản của phương pháp đó sẽ bị tổn hại.<br />
<br />
- Một bài viết nổi tiếng do Ron Jeffries, người ký tên vào Tuyên ngôn Agile và đồng sáng lập XP, viết năm 2018<br />
<br />
“Developer nên từ bỏ Agile.<br />
Nếu các ý tưởng ‘Agile’ không được áp dụng đúng cách, kết quả sẽ là can thiệp nhiều hơn vào developer, ít thời gian làm việc hơn, áp lực cao hơn và yêu cầu ‘đi nhanh hơn’. Điều này không tốt cho developer, và cuối cùng cũng không tốt cho công ty. Bởi vì khi ‘Agile’ không được làm đúng, nó thường dẫn đến nhiều defect hơn rất nhiều và tiến độ chậm hơn so với những gì thực sự có thể đạt được. Thường thì những developer giỏi sẽ rời bỏ các công ty như vậy, và kết quả là doanh nghiệp trở nên kém hiệu quả hơn cả trước khi áp dụng ‘Agile’. ”<br />
<br />
- Một bài viết nổi tiếng khác do Dave Thomas, một người ký tên khác và đồng sáng lập Pragmatic Programming, viết năm 2014 <br />
<br />
“Agile đã chết. (Agility muôn năm)<br />
Từ ‘Agile’ đã bị bóp méo (subvert) đến mức gần như mất hết ý nghĩa, và cộng đồng Agile nhìn chung đã trở thành nơi để các consultant và vendor bán dịch vụ và sản phẩm. Khi Manifesto trở nên phổ biến, từ Agile đã biến thành một nam châm hút lấy tất cả những gì có người ủng hộ, có giờ tính phí hoặc có sản phẩm để bán, và vì thế nó đã trở thành một thuật ngữ marketing. <br />
<br />
Vì vậy, tôi nghĩ đã đến lúc cho từ ‘Agile’ nghỉ hưu.”<br />
<br />
[ Retro : Quay lại quá khứ ]<br />
- Điều thực sự đáng buồn là nhìn thấy các developer trẻ xem Agile như một công cụ để hạ thấp họ, để giới quản lý ép ra những cam kết phi thực tế, và để thúc đẩy developer phải làm việc thêm rất nhiều giờ.<br />
- Agile duy nhất mà họ biết là một cơ chế kiểm soát áp đặt lên họ, chứ không phải một công cụ trao quyền mà lẽ ra họ từng vui vẻ đón nhận.<br />
- Nhưng tôi hy vọng việc bắt đầu thảo luận về lịch sử và tầm nhìn ban đầu sẽ giúp chúng ta nhớ lại cách mình nên tiến về phía trước. <br />
<br />
- Dù vậy, tin tốt là các nguyên tắc của Agile Manifesto ngày nay vẫn sáng suốt và phù hợp như cách đây 20 năm. Ngay cả những người bị xem như kẻ “ly giáo” giả định như Jeffries hay Thomas cũng vẫn nghĩ vậy.<br />
<br />
- Trong bài viết đã nhắc ở trên, Jeffries nói như sau <br />
“Tuy nhiên, các giá trị và nguyên tắc của Manifesto for Agile Software Development vẫn là cách tốt nhất mà tôi biết để xây dựng phần mềm, và dựa trên trải nghiệm dài và đa dạng của mình, dù sử dụng phương pháp nào trong các tổ chức lớn hơn, tôi vẫn sẽ đi theo các giá trị và nguyên tắc đó.”<br />
<br />
- Tôi đồng ý với quan điểm này<br />
- Nói về Agile lúc này không còn là điều thời thượng hay ngầu nữa. Agile giờ đã nhàm chán. <br />
“Mọi người đều làm Agile mà, đúng không?”<br />
- Bây giờ là thời điểm hoàn hảo để nhìn lại 20 năm qua và tự đặt cho mình vài câu hỏi <br />
→ Điều gì đã làm đúng?<br />
→ Điều gì đã làm sai?<br />
→ Lần tới bạn muốn làm khác đi như thế nào?<br />
- Trong vài tháng tới, tôi dự định sẽ quay lại với 12 nguyên tắc Agile nguyên bản, đặt chúng vào đúng bối cảnh ý nghĩa ban đầu và cân nhắc giá trị của chúng trong môi trường phát triển phần mềm hiện tại <br />
<br />
“Hy vọng của tôi là, bằng cách nghiên cứu các nguyên tắc sáng lập, chúng ta có thể học từ quá khứ và, như Dave Thomas nói, ngay cả khi từ bỏ ‘Agile’ thì vẫn giữ được ‘Agility (tính linh hoạt, tính thích ứng nhanh)’.”</p>
3 bình luận