In defense of Agile [Part II]

 

Tiếp tục với chủ đề này, chúng ta sẽ tiếp cận tiếp với những luận điểm khác không hay ho lắm về Agile từ những senior developers.

Công ty tạo giá trị qua cơ cấu tổ chức vững chắc & chặt chẽ

Về luận điểm này, mình muốn lùi lại một chút và bàn về một vài vấn đề liên quan tới việc phát triển phần mềm.

Chúng ta đều biết phần mềm đã và đang thay đổi cả thế giới. Nhiều công ty hiện tại phải đối mặt với thực tế là họ đã phớt lờ công nghệ quá lâu và bây giờ đang bị bỏ lại sau lưng. Đây là hệ quả của một lối tư duy cũ mà nhiều người vẫn đang dùng: command & control, cấu trúc tổ chức dạng bậc thang, phải làm đúng những gì sếp bảo,...

Mọi người thường lấy Facebook và Netflix như là những hình mẫu lý tưởng. Và họ thường cũng nói về cơ cấu tổ chức phân cấp chặt chẽ và rõ ràng của hai công ty trên như một mục tiêu để hướng đến. Nhưng cả hai đều không hoạt động theo cấu trúc chặt chẽ như vậy. Thực tế thì Facebook có thể được mô tả như một mô hình vô chính phủ cho developer. Nơi mà các developer được quyền quyết định mình muốn làm cái gì tiếp theo. Bạn không có Project manager, bạn ko cần Product Owner, Scrum Master hay đại loại gì như thế. Bạn chỉ có những người commit code mà thôi.

Nghe tuyệt vời đúng không ?  Nó đâu đó giống như thiên đường mà các senior dev hay kiếm tìm. Nhưng nó rõ ràng không phải là văn hóa command & control, mà đấy cũng là điều các senior dev cũng hay mong muốn.

Mô hình ở Facebook có vẻ theo kiểu vô chính phủ, nhưng mà không hề hỗn loạn. Các developer ở đấy được tin tưởng để tự do phát triển vì họ đều siêu thông minh và là những developers có trình độ và kinh nghiệm nhất định, nếu không muốn nói đấy là tập hợp của những developer ở trình độ cao nhất thế giới. Có được như vậy vì Facebook là một nơi rất hấp dẫn để làm việc. Netflix cũng vậy. Họ có thể thuê những người giỏi nhất ở vị trí của mình.

Vậy còn những ai không thể thuê được những người tốt nhất như vậy? Câu trả lời thật ra là tất cả các công ty. Vì chính Facebook và Netflix cũng không thế cứ muốn có ai là cũng có được. Tại sao ư? Lí do chính là Kinh tế. Báo chí viết nhan nhản về việc cách những kĩ sư được trả lương khủng khiếp như thế nào ở thung lũng Silicon như là một cách trân trọng tuyệt vời cho tài năng của họ, nhưng chúng ta cũng cần biết thêm là Steve Jobs cùng băng đảng các CEO ở thung lũng Silicon đã bắt tay với nhau để "dìm' mức lương của các developers, bằng cách không trả quá cao hơn dải lương của nhau. Vậy đây không phải chỉ đơn thuần là trân trọng tài năng.

Từ kinh nghiệm của mình thì đa phần các công ty đang chơi đùa với những con số khi bàn đến công nghệ. Nó là một giải pháp thuần kế toán cho một vấn đề mà họ không hiểu:

Hãy đầu tư một khoản vào phần này và nếu nó không ổn thì chúng ta sẽ cắt nó đi

Đây là một khoản đầu tư khá là không rõ ràng, hơi bi quan và rõ ràng là không phải câu trả lời cho việc phát triển phần mềm. Nó cũng dễ khiến doanh nghiệp gặp phải những "thánh chém", "thánh nổ", những lập trình viên giỏi nói hơn làm, những chuyên gia không có thực tế. Tệ hơn nếu họ có thể nắm quyền điều khiển và khiến tất cả lụi bại. Trừ khi bạn phải thực sự nhúng tay vào, và đáng buồn là đa phần các CEO của những công ty ngoài lĩnh vực công nghệ không biết tí gì về công nghệ.

Có một khảo sát ở Anh đã thông kê là 52% FTSE 100 CEO xuất thân là dân tài chính kế toán, so với chỉ 4% xuất thân là dân công nghệ, mặc dù rất nhiều công ty trong danh sách niêm yết đấy là những công ty công nghệ. Có những giai thoại kinh ngạc truyền tai nhau như một giám đốc đã từng phát biểu:

Database sập thì sao ? Đấy là vấn đề của Oracle, không phải của chúng ta

Những người như vậy không thích Agile. Và rất nhiều người như vậy đang được giao chịu trách nhiệm cho mọi vấn đề, nhấn mạnh lại mà mọi vấn đề của doanh nghiệp.

Scrum và maturity

Mình muốn nói về Scrum một chút. Vì các phàn nàn về Agile thường chỉ đích danh Scrum. Tám năm về trước, khi lần đầu tiên mình được tiếp xúc với Scrum, mình rất thích nó, nhưng thời gian có thể làm thay đổi nhiều thứ. Hiện giờ mình thấy Scrum chủ yếu được coi như một kho các phương pháp mà mọi người hi vọng nó sẽ giúp các công ty lớn giảm dần văn hóa command & control. Vậy là Scrum dần trở thành một "liều thuốc" cho những tổ chức lớn, nhưng có hiệu quả công việc kém.

Những Scrum practitioner mình gặp thường than phiền về phải làm việc với những developer kém chất lượng. So sánh ra thì nó rất tương phản với Facebook hay Netflix, kể cả khi họ không thuê được những người tốt nhất thì họ cũng thuê được những người giỏi. Nhiều công ty lớn cũng than phiền về việc mình đang có nhiều nhân viên kém. Nhưng chúng ta cũng cần đặt lại câu hỏi. Họ chất lượng kém ngay từ đầu hay là vì công ty mà họ có chất lượng kém ?

Scrum là một phương thức để xây một hệ thống nhằm hoạt động sản xuất và quản lý một team với cả người giỏi lẫn người kém. Nhưng cá nhân mình nghĩ nếu tập trung vào quá vào Scrum thì sẽ làm thảm họa, vì lúc đó họ sẽ dừng suy nghĩ mà chỉ cần quan tâm là đây có phải là Scrum hay không ? Nếu không đúng theo Scrum thì chúng ta không nên làm thế. Và nó rõ ràng đó không phải là cách để trở nên tốt hơn, theo tinh thần Agile

Dường như có cả một tôn giáo xung quanh Scrum, các giáo dân bảo với nhau là bạn cần một Scrum master và họ phải có tố chất riêng cũng như tập trung hỗ trợ các developer và không cần phải code. Bạn cần triển khai theo sprint, mỗi sprint phải kéo dài 2 tuần. Mỗi sprint phải bắt đầu bằng một buổi Sprint planning, nếu không thì mọi người chả biết làm gì trong sprint đó.

Những suy nghĩ trên thật ra là vớ vẩn hết. Thật đấy. Bạn không cần thiết phải cần một nhân sự riêng đảm nhận vai trò Scrum master cho team, thực tế việc có một SM trong team dường như còn làm các thành viên lười tìm cách giải quyết vấn đề hơn. Nhưng đặt trong tình huống khi bạn có những developer đã trải qua việc bị quản lý chặt chẽ ngày qua ngày, thì việc có một SM theo hướng servant leader sẽ giúp team dần học cách tự giải quyết vấn đề.

Sprint cũng là một phương thức hoàn toàn kỳ cục để sản xuất phần mềm. Nó luôn tạo ra tình huống mà bạn không thể bàn giao sản phẩm đủ nhanh, nó cũng khuyến khích developer giấu code, tạo ra nhiều nhánh hơn cần thiết và khiến mọi người bận rộn hơn. Khá là vô dụng. Nhưng đặt trong bối cảnh developer bị trải qua một kế hoạch công việc quá dài ngày qua ngày, tuần qua tuần thì có lẽ việc có những vòng lặp ngắn và nhanh sẽ giúp mọi người bám sát vào mục tiêu hơn.

Sprint planning cũng hơi thừa thãi, vì việc ước lượng thực sự là khó một cách kinh ngạc và theo một cách nào đó là hơi ngu ngốc và mọi người dường như luôn bị ám ảnh bởi nó.Nhưng có lẽ, chỉ là có lẽ thôi nhé, trong một ngành mà các project plans chủ yếu là bốc thuốc theo kiểu top down từ PM hoặc AM, và tốn rất lâu để làm cũng như nhiều khi mơ hồ và không chính xác, thì đây có thể là cách giúp mọi người hiểu rõ phạm vi công việc, mình đang phát triển cái gì, cả khía cạnh tech lần product

Vậy nên ừ có thể Scrum rất chán, nhưng nhiều lúc nó cũng có ích.

Còn nhiều nữa

Thật đấy, trong quá trình làm digital transformation cho nhiều nơi, mình nhận được rất nhiều quan điểm trái chiều về Agile nữa, ví dụ như:

Mục tiêu của công ty là phải làm ra tiền

Không nhất thiết phải đặt mục tiêu quan trọng nhất là kiếm tiền nếu bạn làm cho các tổ chức dịch vụ công, hoặc phi lợi nhuận. Tiền bạc là mục tiêu cho nhiều đơn vị và tổ chức, nhưng nhiều công ty phần mềm không để tiền bạc quyêt định cách họ hoạt động.

Phần mềm sẽ thay thế mọi thứ, xin lỗi những ai không phải là developer nhé

Nhưng mà thực tế thì việc thiết kế lập trình cơ bản, ví dụ như website cũng sẽ bị thay thể bởi AI. Vậy nên cũng sẽ phải xin lỗi một số lượng developer trong đấy luôn

Agile team là một lũ 10 ông ngồi bới móc lẫn nhau

Hoặc đó có thể là những buổi brain storming, crtical thinking để cùng giải quyết các vấn đề đang gặp phải. Cái đó tùy thuộc vào bạn.

Có rất nhiều những ý kiến như này nữa, về việc văn hóa Agile không hiệu quả ở những tổ chức lớn, hay không hiệu quả khi không có được con người, rồi tài liệu không được quan tâm và hoàn thành đúng mức. Các bạn đã và đang làm theo Agile methodologies sẽ hiểu những vấn đề mình bàn trên đây.

Ai code tốt hơn người đó thành công hơn.

Cái này cũng rất vớ vẩn nốt. Steve Jobs. Không biết code. Tim Cooks. Không biết code. Rất nhiều CEOs ngoài kia nữa. Đều không biết code. Có phải sản phẩm code tốt hơn thành công hơn hay không ? Chưa chắc. Có phải người code tiên phong sẽ là người thành? Cũng không nốt.

Làm nhanh để phá vỡ các giới hạn

Điều này của Agile không mang áp dụng cho các ngành nghề bình thường khác được. Bạn không thể đến nói một điều tương tự như này khi cung cấp các sản phẩm y tế: Xin lỗi, chúng tôi muốn làm nhanh những tính năng này trên thiết bị mới để xem thị trường phản hồi như nào rồi điều chỉnh cho lần sản xuất tiếp theo. Bạn cứ thử làm thế xem rồi xem mình còn kinh doanh được không.

Lập trình viên là vua của mọi nghề

Cái này thì thôi, mình không muốn nhắc lại những câu đùa về nó nữa.

Developer quá tuổi 30 là chuẩn bị về vườn

Thật ra thì rất nhiều cao nhân đang định hướng sự phát triển của ngành IT đều hơn 30 tuổi. Ken Thompson, Rob Pike, Joe Armstrong, Richard Stallman, Ulrich Drepper, mình có thể kể thêm nhiều nữa.

Mình không có ý nói rằng các lập trình viên giỏi nhất đều là mấy ông già, chỉ một vài người như vậy thôi. Nhưng chả ai có thể khẳng định hơn 30 tuổi là sẽ bị đào thải và hết thời cả.

Lập trình viên nên là developer chuyên nghiệp, được đào tạo từ đại học ra

Nếu thế thật thì thế giới lập trình sẽ đáng buồn và khiếm khuyết. Larry Wall là một nhà ngôn ngữ trước khi tạo ra Perl. Joe Armstrong thì là một nhà vật lý. Nhiều người đến từ nhiều domain khác nhau, và sử dụng lập trình để giải quyết bài toán của họ. Đó chẳng phải là điều thú vị nhất của lập trình ư ?

Kết

Đây là suy nghĩ cuối của mình. Không phải là Agile vớ vẩn và gây khó khăn cho developer hay kết quả tệ của tổ chức của bạn. Vấn đề là việc không hiểu ý nhau giữa những người đang chạy theo Agile. Vậy nên phủ nhận Agile cũng không phải là cách để cải thiện hay mang lại một kết quả tốt hơn.

Vậy nên các senior developers, hãy ngưng nói về việc Agile tệ như thế nào. Thay vào đó, hãy cùng ngồi lại với Biz owner, Product owner và làm việc cùng với nhau để cải thiện khâu phát triển sản phẩm của mình. Việc đó tất nhiên không dễ, ngược lại là đằng khác. Nó cũng khác rất nhiều việc lập trình phần mềm. Nhưng nó đáng có được sự quan tâm như vậy.


Comments