Tấn: Chào anh, anh có thể mô tả phương pháp phát triển phần mềm đang được sử dụng ở công ty của anh?

Alex: Ở Ibelis chúng tôi sử dụng một triết lý rất Agile đó là tối đa hóa việc giao tiếp, sự hợp tác, minh bạch và tính hiệu quả. Chúng tôi sử dụng iteractive (phương pháp lặp), đó là cách tiếp cận dựa vào nhóm (Team) để phát triển từ đó đạt được những kết quả cao mà có thể giảm thiểu được rủi ro và thời gian.

Tấn: Vậy Ibelis đã trở nên agile như thế nào?

Alex: Vào năm 2010, tôi phát hiện ra khá nhiều vấn đề với phương pháp mà chúng tôi áp dụng ở Ibelis. Vấn đề là chúng tôi “chuyển động” quá chậm. Chúng tôi không thể xử lý tốt những thay đổi trong các phần mềm. Để mà quay trở lại với vấn đề đó và thay đổi nó quả thực là rất khó khăn và “gian nan”, đặc biệt là phải thay đổi những lỗi nhỏ nhặt mà mọi người dễ mắc phải. Mà để có được một mô hình làm việc trong lĩnh vực phần mềm sẽ phải mất hàng thế kỉ, đến lúc đó, tóc tôi đã nhuốm bạc mất rồi. Đó cũng là lúc tôi nhận thấy mình cần theo đuổi một chiến lược khác. Một chiến lược mà có thể giúp chúng tôi đạt được mục tiêu nhanh hơn và an toàn hơn.

Do đó, tôi tìm đến hỏi “bác Google”, cái gì đang là phương pháp tiếp cận phát triển phần mềm tốt nhất hiện nay? Và “bác” trả lời tôi ngay lập tức với từ “Agile”. Lúc đó, tôi đã tự nói với mình rằng: “nghe có vẻ hay ho hơn waterfall đấy”. Bên cạnh đó, bản thân tôi đã không thích cái từ “waterfall”, nó nghe có vẻ là chúng ta đang “rơi xuống” (fall) chứ không phải là tiến lên phía trước.  Tôi cũng không quá khắt khe trong việc này, nhưng thiết nghĩ, tại sao chúng ta nên rơi (fall) chứ?

Bản thân từ Agile đã có nghĩa gì đó rất “nhanh chóng” (fast), đó thực sự là thứ mà tôi đang tìm kiếm (bởi chúng tôi đang di chuyển quá chậm). Và rồi tôi dành thời gian khoảng ba đến bốn tháng tìm kiếm thông tin về nó nhiều nhất có thể để giúp tôi tự học được. Ngoài ra tôi cũng có một bản copy cuốn sách “Agile Software Development Principles, Patterns and Practices” của tác giả Robert C.Martin. Cuốn sách này đã giúp tôi sáng tỏ nhiều điều về Agile. Cuốn sách rất tuyệt vời nhưng tôi phải mất khá nhiều thời gian để đọc hết nó bởi vì thời gian này tôi đang làm hàng tỉ việc. Bằng cách đọc các  phương thức Agile khác nhau, tôi đã học về Scrum và biết nó có sức mạnh lớn cỡ nào và  nó đang làm nhiều điều tuyệt vời cho nhiều công ty lớn khác.

Sau đó, tôi tiếp tục tìm kiếm mọi thông tin về Agile và Scrum. Ngay lập tức tôi biết rằng tôi cần phải chuyển đổi Ibelis sang cách tiếp cận bằng Agile và Scrum ngay lập tức.

Còn tại sao lại là Scrum ấy à?

Thật sự Scrum rất hấp dẫn đối với tôi. Scrum có thể giải quyết được những vấn đề mà tôi đang gặp phải như khi yêu cầu (của khách hàng) thay đổi, những dự án quá phức tạp, dài hơi, khó làm. Với những cái dự án đó, chúng tôi không bao giờ có thể hoàn thành được.T hời hạn hoàn thành dự án thì không đạt được bởi các thành viên trong nhóm hay bị xao nhãng bởi rất nhiều công việc khác.

Vào khoảng tháng 10 năm 2010, tôi được biết một khoá học về Scrum sẽ được tổ chức ở thành phố Hồ Chí Minh vào tháng 2 năm 2011. Ngay lập tức tôi quyết định phải tham gia khoá học đó. Tất cả mọi thứ tôi biết về Scrum chỉ là những thứ tôi đọc được, còn về việc thực hành Scrum như thế nào tôi không hề có một khái niệm gì. Do đó, tôi biết rằng tôi cần phải có sự tương tác với mọi người. Bên cạnh đó, lý thuyết có thể đem lại cho bạn một nền tảng kiến thức nhất định, nhưng thực hành mới là thứ quyết định.

Khi mà tôi tham dự khoá học đầu tiên về Scrum Master tại Hồ Chí Minh, tôi gặp rất nhiều người tuyệt vời. Họ có cùng tư tưởng với tôi về việc đạt được những kết quả tương tự ở công việc hàng ngày của họ. Khoá học thực sự rất tuyệt vời. Kể từ đó, cuộc đời tôi bước sang một trang mới. Tôi quyết định xây dựng một Agile Philosophy của riêng tôi và bắt đầu áp dụng nó cho Ibelis.

Tấn: Theo quan sát của tôi thì có vẻ như anh đặt nặng yếu tố “triết lí” quá.

Alex: Một khi bạn đã có được một hệ tư tưởng (mindset) phù hợp, thì những thứ khác tự nó sẽ vào đúng chỗ. Dĩ nhiên là nếu nhóm (team) mà kém cỏi thì hệ tư tưởng cũng không giúp ích được gì. Nhưng mọi thứ đều bắt nguồn từ mindset.

Tấn: Anh có thể nói rõ hơn về mindset mà anh xây dựng?

Alex: Đối với tôi, mindset là cách mà ta tư duy. Triết lí là một bộ những quy tắc, chuẩn mực để hướng dẫn bạn đưa ra sự lựa chọn phù hợp.

Tấn: Tôi quan sát thất là có nhiều công ty nói rằng họ là agile và họ ủng hộ agile, nhưng thực tế họ lại ưa thích và thực hành waterfall. Anh thấy thế nào?

Alex: Thực sự là rất khó để agile một trăm phần tram. Thực tế là rất nhiều người nói rằng họ là Agile nhưng mà cách khi họ làm việc thì lại mâu thuẫn với agile.

Tấn: Tuần trước tôi có viếng thăm một công ty với khoảng gần 100 lập trình viên. CEO là một người rất thích các ý tưởng về agile và Scrum. Nhưng ông ấy vẫn quản lí chặt chẽ đến từng việc nhỏ của nhân viên dưới quyền, comment từng dòng lệnh cho họ.

Alex: Ý anh là quản lí vi mô (micromanage) ấy à?

Tấn: Vâng.

Alex: Ái chà! Có vẻ như đó là bởi vì vị trí của ông ấy. Và bởi vì ông ấy đã làm như thế suốt nhiều năm trời rồi. Và việc để “mất kiểm soát” có vẻ như là không dễ dàng gì. Ông này có vẻ cần phải gửi đi huấn luyện lại để có thể vượt qua được nghịch cảnh mang  tên “quản lí vi mô”. Tôi cũng đã từng vướng phải chuyện tương tự. Rất khó để thay đổi tư duy trừ khi việc đó là rất có giá trị. Nếu người ta thấy việc thay đổi trị giá rất rất nhiều tiền, thì sự thay đổi sẽ diễn ra nhanh chóng hơn.

Tấn: Vậy làm thế nào anh biết được nhân viên của mình có tư tưởng agile hay không?

Alex: Vấn đề là khi mà chúng ta ở một thời điểm nào đó, rất dễ xảy ra tình trạng ta lệch hướng nhưng các quy tắc, chuẩn mực sẽ luôn giữ ta đi đúng hướng.

Tấn: Công ty anh đã đạt được những lợi ích gì (liên quan tới khách hàng, tổ chức, kỹ thuật) kể từ khi công ty anh trở nên linh hoạt?

Alex: Thật sự để trả lời câu hỏi này sẽ phải mất vài tiếng. Lợi ích là gì? Hãy bắt đầu với lợi ích cho “khách hàng”. Hiện nay, chúng tôi có những bản demo sản phẩm mà không cần phải đợi tới hai năm. Chúng tôi (luôn) có thể đưa cho họ một bản demo để họ xem trước. Do đó, khách hàng của chúng tôi không cần phải tưởng tượng xem phần mềm của chúng tôi trông như thế nào. Đây thật sự là một bước tiến lớn của chúng tôi.

Hiện nay chúng tôi đang có thể đạt được các giá trị kinh doanh ở mọi phân đoạn (iteration). Chúng tôi có thể hoàn thành một Sprint lại và nói “này anh, chúng tôi có một sản phẩm, có thể nó không hoàn hảo, nhưng nó là một sản phẩm”. Sự hoàn hảo đạt được khi mà mọi thứ được làm đúng với sự hiểu biết tốt nhất của chúng ta thông qua những chu trình lặp đi lặp lại.

Về mặt kĩ thuật, chất lượng thì đã được cải thiện đáng kể nhờ việc team xử lý những công việc nhỏ trong một khoảng thời gian ít hơn. Trách nhiệm phải giải thích  cho việc triển khai những sản phẩm có thể chuyển giao được (shippable) là một phần của tinh thần nhóm. Trong trò chơi Rugby (bóng bầu dục), một khi đã ở trên sân bóng, dù bạn ở vị trí nào đi chăng nữa, tất cả chúng ta đều có một mục tiêu chung, đó là chiến thắng. Chúng ta không có thời gian để giận dữ và nói rằng vị trí của tôi là ở phòng ngự, tôi không muốn ở khu vực tấn công. “Một đội” tức là ai cũng có một mục đích chung. Ở Ibelis, chúng tôi biết được rằng “Một đội” là phải có một mục tiêu chung, đó là cung cấp những sản phẩm chuyển giao được.

Tấn: Vậy theo anh, những yếu tố chính để thành công trong việc thực hiện Agile là gì?

Alex: Trước tiên, bạn cần có một triết lý đúng đắn trong tổ chức của mình. Bởi vì chúng tôi chỉ là một công ty nhỏ và không tổ chức công ty theo kiểu phân cấp nên những người đứng đầu khá dễ dàng trong việc thiết lập các chuẩn mực (standard). Ở những tổ chức lớn, những người quản lý ở trên phải có tư tưởng Agile trước tiên, rồi sau đó phải truyền tải nó cho cả công ty. Nói cách khác, vị trí của lãnh đạo trong việc phát triển Agile là rất quan trọng.

Thứ hai, nhóm làm việc là một yếu tố thiết yếu hết sức quan trọng cho sự thành công. Bạn cần một nhóm “đa năng”, họ có đầy đủ mọi thứ mà cần phải tạo ra những sản phẩm gọi là “sản phẩm chuyển giao được” và có thể tin cậy giao phó công việc cũng như chịu trách nhiệm hoàn tòan với công việc đó.

Thứ ba, tối thiểu hóa rủi ro thông qua nỗ lực của nhóm hợp tác. Nhóm làm việc sẽ có khả năng quản lý và ước lượng một cách từ từ, đồng thời giúp cho việc loại bỏ các rủi ro tiềm ẩn.

Thứ tư đó là cho nhóm của mình thấy được sự cần thiết như thế nào đối với việc đạt được những mục tiêu của công ty. Có thể cho họ thấy đó là những khóa huấn luyện kĩ năng, hay các ưu đãi của công ty, v.v.

Thứ năm, bắt buộc phải tạo ra một môi trường làm việc mà mọi người đều có vai trò như nhau trong một nhóm hơn là việc “chỉ tay năm ngón” vào từng cá nhân. Điều này cực kỳ khó đạt được nếu như nhóm của bạn không có trình độ như nhau. Bởi từng thành viên trong một nhóm rất cần giúp đỡ lẫn nhau để có thể đạt được mục tiêu chung, mục tiêu cuối cùng.

Phản hồi từ phía khách hàng là chìa khóa thành công.  Ai sẽ quan tâm tới việc chúng ta xây dựng phần mềm nhanh cỡ nào nếu như không có ai sẽ sử dụng nó? Chúng ta phải lắng nghe khách hàng của chúng ta và tạo ra những sản phẩm phải dựa trên nhu cầu thực sự của họ hơn là việc xây dựng một thứ mà sẽ không ai dùng trừ chúng ta. Nó giống như câu nói ở trong marketing đó là “chúng ta bán cái thị trường cần, chứ không phải cái chúng ta cần”.

Sự tin tưởng cũng rất quan trọng. Nếu bạn không tin mọi người thì mọi người sẽ không tin bạn. Bạn cần phải tin tưởng nhóm của bạn cũng như việc nhóm cần phải tin tưởng bạn. Sự thích nghi và minh bạch cũng vậy. Hãy lắng nghe những yêu cầu, những mệnh lệnh và thích ứng với phầm mềm một cách phù hợp. Bạn phải hòan toàn minh bạch, trung thực và luôn hướng về phía trước. Đây thật sự là một trong những yêu cầu quan trọng khi tôi “sàng lọc” những người dự tuyển cho nhóm của tôi.

Tấn: Thực tế, công ty anh đã học agile như thế nào?

Alex : Thực hành, đọc, chia sẻ và tương tác với mọi người có tư tưởng agile giống mình. Bằng cách sử dụng cách thức tiếp cận của Socrates đó là đưa ra những câu hỏi có ý nghĩa và hữu dụng. Còn chuyện mất bao lâu để học được agile? Tôi nghĩ là sẽ mất cả đời mới học được. Bản chất con người luôn vận động không ngừng và họ sẽ không dừng học hỏi, tìm tòi những thứ mới. Mà một triết lý sẽ phải mất một đời người mới có thể làm chủ được.

Tấn: Anh có thể cho biết thêm về cách tiếp cận Socrates của anh được không?

Alex: À, tôi thích hỏi các hỏi các câu hỏi có ý nghĩa và khuyến khích mọi người cũng làm như vậy.      Tôi luôn khuyến khích mọi người phá vỡ tôn ti, thứ bậc. Anh biết đấy, nhờ việc hỏi mà chúng ta có hiểu biết, và, chúng ta trưởng thành nhờ học như vậy.

Tấn: Nhưng theo quan sát của tôi thì việc tiếp cận kiểu Socrates không dễ ở Việt Nam, mọi người có vẻ không thích bị hỏi nhiều. Đó cũng là nguyen nhân dẫn đến việc tôi cũng phải viết một vài dòng về kĩ thuật hỏi đáp kiểu như thế trên blog cá nhân để giúp mọi người làm quen với nó.

Alex: Đúng rồi, ở Việt Nam, mọi người thường không hay hỏi theo kiểu như vậy. Ví như trong một buổi thuyết trình, khi tôi bắt đầu hỏi theo kiểu như vậy, đáp lại chỉ là mấy ánh nhìn lạ lẫm. Và họ thường đánh mắt sang người khác thay vì tham gia vào quá trình hỏi đáp kiểu như vậy.

Tấn: Anh có thể khuyên mọi người học Scrum như thế nào không?

Alex: Tham dự vào những event của cộng đồng Agile Việt Nam để biết được Scrum ở thế giới thực như thế nào. Bạn cũng có thể học được ở Hà Nội Scrum (cười). Nhưng nếu tôi là bạn, thật sự muốn học Scrum thì trước tiên tôi sẽ đọc những kiến thức cơ bản về Scrum và đặt ra câu hỏi: Tại sao, Khi nào và Khởi đầu như thế nào. Rồi sau đó tìm cho mình một khóa học, khóa huấn luyện và tham gia vào cộng đồng agile.

Tấn: Tại sao anh lại cho rằng tham gia cộng đồng là cách học tốt?

Alex: Không có phương pháp nào học nhanh hơn bằng cách trao đổi những ý tưởng của mình cho người khác. Khi tham gia vào cộng đồng, nếu không ai biết một điều gì đó sẽ là một thử thách dành cho mọi người. Và chắc chắn sẽ có ai đó không chịu ngồi yên và muốn tiến xa hơn, đạt được nhiều thứ hơn và chia sẻ kết quả đó cho mọi người. Tôi nghĩ rằng cộng đồng có thể giúp đỡ nhau nhiều nhất, đó cũng là lý do tại sao tôi trở thành một phần của cộng đồng AgileVietnam.

Tấn: Vậy theo anh nghĩ cái gì là khó học và khó thành thạo nhất? (những thứ mà anh hay nhân viên của anh phải cố gắng rất nhiều để học)

Alex: Đó là khi gặp phải những tư tưởng cứng đầu, rất khó có thể kế thừa được tinh thần trách nhiệm. Ước lượng cho Sprint luôn là một trong những thử thách khó dành cho nhóm, rất khó đạt được sự “liên chức năng” (cross-functional). Thực sự tôi đang có một thời gian khá khó khăn trong việc tìm được đúng người cho nhóm, và không may là, nếu bạn không có người phù hợp, Scrum sẽ không bao giờ hiệu quả.

Tấn: Anh có dự định sẽ làm gì với Agile\Scrum trong thời gian sắp tới ở Ibelis?

Alex: Phát triển, cải thiện, thích nghi, học hỏi thêm nữa và …(cười) tôi sẽ nói với anh khi anh mời tôi món Phở Hà Nội nổi tiếng mà tôi vẫn đang chờ đợi một cách kiên nhẫn để tìm hiểu nó (cười).

Tấn: Vâng, xin cảm ơn anh. Tôi sẽ mời anh món Phở ngon nhất Hà Nội khi anh đến. Cảm ơn anh đã dành thời gian chia sẻ với Hanoi Scrum.

Thông tin thêm:

Ibelis Corporation là công ty công nghệ thông tin toàn cầu, cung cấp những giải pháp cải tiến cho các doanh nghiệp. Đặc biệt các giải pháp của công ty được thiết kế phù hợp dành cho việc tạo ra và quản lý  thương hiệu doanh nghiệp trực tuyến.  Agile chính là triết lý của công ty, toàn bộ nhân viên trong công ty luôn được khuyến khích sử dụng triết lí này. Hiện nay Ibelis có mặt ở Montreal - Canada và Tp.Hồ Chí Minh - Việt Nam. Và Alex hiện đang là một trong những thành viên tích cực nhất của Agile Vietnam nhằm thúc đẩy sự phát triển của Agile tại Việt Nam.

Trước khi sáng lập Ibelis, Alex từng là CTO cho JPay Inc. tại Miami, Flodia, Mỹ. Ở Jpay, Alex tạo ra và quản lý Electronic Inmate Payment System và Mail Processing System cho những doanh nghiệp có dịch vụ chuyển tiền cho hệ thống nhà tù liên bang của chính phủ Mỹ ( US Government State Prison Systems).

Thomson Reuters, trước đây được biết đến với tên gọi Thomson Corporation đã mua lại Praxis Press nơi mà Alex đóng một vai trò then chốt cho sự phát triển của công nghệ quản lý nội dung y tế cho các chuyên gia y tế tiên phong của các tổ chức y tế trên khắp nước Mỹ)

Thực hiện phỏng vấn: Dương Trọng Tấn

Việt hóa và viết bài: Dương Thu Hương

Review: Phạm Minh Hoạt.