Agile và văn hóa Việt Nam

Bên lề bài viết

Tôi có cơ hội được làm việc với một khách hàng người Nhật trong một thời gian khá dài. Bác ấy là một người khá đặc biệt, và có phần hơi "Tây" so với những thuyết giáo và phong cách vốn là đặc điểm đặc biệt của người Nhật. Bác đã đi làm hơn 20 năm trong nghành phần mềm, tuy nhiên, bác lại là một người rất cởi mở, sẵn sàng lắng nghe và chia sẻ với tất cả mọi người, dù là người mới hay người cũ, dù role của bạn là gì. Đối với tôi, thực sự rất may mắn khi được làm việc với bác khách hàng đó như là team-mates.

Vì sao phải nói như vậy khi mở đầu bài viết, vì thực sự bài viết này là những gì tôi nghe được, học được và được trao đổi với một người nước ngoài yêu-Việt-Nam, từ đó có một cái nhìn khách quan hơn.

Có thể bạn sẽ nghĩ ngay, văn hóa và truyền thống thì liên quan gì đến dự án phần mềm??? Tôi đã từng nghĩ thế, nhưng thật ra, khi ngẫm lại, thực sự là có liên quan. Về Agile, trên diễn đàn đã có rất nhiều tác giả tìm hiểu và viết, để rõ hơn mọi người có thể tham khảo theo các các bài viết:

"[ Agile Software Development, Principles, Patterns, and Practices] Agile Practices: https://viblo.asia/dinhhoanglong91/posts/jamoG8B6Rz8P

"Agile Software Development": https://viblo.asia/nguyen.thi.hong.nhung/posts/oaKYMNPbv83E

Ở bài viết này, tôi chỉ xin nói về khía cạnh Agile và văn hóa Việt Nam.

Những vấn đề đằng sau những câu hỏi đơn giản nhất

Có bao giờ trong cuộc họp, các bạn có suy nghĩ “vì leader/ các anh chị vào trước nói thế nên nó là như thế”?

Có bao giờ các bạn cảm thấy “mình thấy có gì đó không đúng, nhưng đây chẳng phải chỗ để mình có thể phát biểu ý kiến của mình”?

Lý do có thể là vì các bạn trẻ hơn những người khác trong đội. Có thể các bạn chỉ là Programmer hoặc QA trong dự án. Hoặc là giả sử bạn là PM hay Leader, khi dự án có vấn đề, liệu rằng các bạn có từng nghĩ “Nếu mình không làm thì vấn đề này chẳng thể nào giải quyết được” hay không?

Ở đây, chúng ta hãy cùng nhìn nhận về Team building trong 2 nguyên tắc cuối của “12 Nguyên tắc phát triển phần mềm (kiểu) agile”. Những bạn độc giả chưa từng biết đến khái niệm này, tôi mong các bạn có thể tham khảo tại đường link: http://agilemanifesto.org/principles.html.

12 nguyên tắc phát triển phần mềm (kiểu) Agile

(Tôi xin phép lược bỏ các nguyên tắc 1~10)

11. The best architectures, requirements, and designs emerge from self-organizing teams.
Các kiến trúc, yêu cầu, thiết kế tốt nhất được tạo ra từ các team-tự-tổ-chức.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Sau một khoảng thời gian nhất định, nhóm phát triển suy nghĩ về cách để làm việc hiệu quả hơn, từ đó đưa ra những điều chỉnh phù hợp.

Các bạn đã từng nghĩ 2 nguyên tắc này muốn nói về điều gì hay chưa?

Nói to tát hơn, 2 nguyên tắc này bao hàm tư tưởng – cũng có thể coi là niềm tin tuyệt đối với chân lý “thành công bằng cách điều hòa” có cơ sở là “tự do” và “bình đẳng”. Mọi thành viên trong đội đều tự do và bình đẳng, hướng tới thành công của dự án. Tất cả các thành viên cùng hợp tác giải quyết những vấn đề mà dự án phải đối mặt, cải tổ thành tổ chức có khả năng tự xử lý cao hơn nữa.

Nếu các bạn trải qua trạng thái như tôi đã đề cập ở phần đầu bài viết thì nghĩa là các bạn “chưa là Agile” xét từ tư tưởng Agile như thế này:

Việt Nam và Nhật Bản có nhiều nét tương đồng khi chịu ảnh hưởng của hệ thống đạo đức và triết lý Nho giáo. Lời dạy về “Hiếu đễ” trong Luận Ngữ, rằng: phải quý trọng cha mẹ, anh em, kính trọng người trên thì cả người Nhật và người Việt đều ghi sâu trong lòng từ thời thơ ấu. Nói cách khác, lời dạy về “Hiếu đễ” đã khắc sâu vào nhân cách cơ bản của mỗi chúng ta.

Tuy nhiên, có thể thấy rất nhiều trường hợp, tư tưởng này khiến cho việc vận hành team theo Agile trở nên khó khăn.

Từ khi mới bắt đầu đi làm, cho đến thời điểm hiện tại, tuy không thể gọi là lâu dài, nhưng cũng đủ để tôi có một ít nhận xét theo kinh nghiệm bản thân: thường các Project Leader hay Scrum Master, Architect nhiều tuổi hơn các thành viên dự án, vai trò và vị trí của họ cao hơn các thành viên ít tuổi. Ngoài ra, một điều cực kỳ thường gặp, trong tiềm thức hay có xu hướng nghĩ rằng Programmer thì “hiểu về hệ thống” hơn là QA.

Chẳng những thế, những member trẻ tuổi thường có lối suy nghĩ “Chỉ có người có kinh nghiệm mới xử lý được vấn đề này chứ không phải là mình” hay “Mình có phát biểu thì cũng vô ích”. Kiểu suy nghĩ như vậy chính là một dạng tư tưởng được hình thành một cách vô thức trong xã hội Nho giáo.

Tuy nhiên, nó không phù hợp với tư tưởng agile. Tư tưởng agile đòi hỏi cả những member trẻ, cả programmer trẻ, cả QA, tất cả mọi thành viên đều hiểu issue là “vấn đề của team chúng ta”, cùng nhau nỗ lực hợp tác để giải quyết vấn đề. Issue về thiết kế hệ thống khó không phải chỉ là vấn đề của Architect. Vấn đề môi trường test, tái hiện bug chẳng phải là vấn đề chỉ của riêng QA. Quan trọng là Leader, architecter, designer, programmer, QA, tất cả thành viên phải nhận thức được thế mạnh của bản thân, suy nghĩ xem mình có thể làm gì để giải quyết vấn đề và cùng thực hiện công việc.

Hãy Agile !!!

Trong một team kiểu Agile, không tồn tại cái gọi là “vấn đề của người khác”.

Một khi trong suy nghĩ của tất cả mọi người đều hướng về "tinh thần Agile" thì không còn khoảng cách.

Khi làm việc theo Agile, vấn đề của dự án sẽ là vấn đề của tập thể, nhưng trách nhiệm sẽ là của mọi thành viên trong đó.

Theo tôi nghĩ, chúng ta hãy bắt đầu nên bắt đầu thói quen xem xét mỗi vấn đề mà team gặp phải như là vấn đề của mình và hãy đừng ngần ngại nói và hành động những điều mà mình có thể làm được nhé!!!

(Bài viết có sử dụng thông tin và tư liệu từ tạp chí Geek and Tech)