Trong tháng 3, anh Anand Iyengar và anh Gabriel Gavasso đại diện ThoughtWorks Đông Nam Á đã có chuyến công du sang Việt Nam. Nhân cơ hội này, HanoiScrum đã tổi chức buổi thảo luận với họ về chủ đề "10 lỗi khi áp dụng Agile" và một buổi phỏng vấn về một số vấn đề mà cộng đồng Agile Việt Nam quan tâm như cách bắt đầu với Agile, những dấu hiệu để biết đang áp dụng đúng Agile, v.v…

Ảnh buổi phỏng vấn (Từ trái qua phải: Phạm Anh Đới, Gabriel Gavasso và Anand Iyengar)

Đới: Mời Hai anh giới thiệu một chút về mình và công ty ThoughtWorks được không?

Anand: Tôi đã làm việc ở ThoughtWorks hơn 11 năm với nhiều vai trò khác nhau như quản lý và phát triển sản phẩm, bán hàng và hiện thời là Giám đốc điều hành của ThoughtWorks Đông Nam Á.

Gabriel: Tôi tham gia ThoughtWorks ở Brasil và đã làm việc cho ThoughtWorks hơn 3 năm với vai trò quản lý phân tích nghiệp vụ cho các khách hàng ở Hoa Kỳ và Brasil. Tháng 5/2013 tôi chuyển tới làm việc ở Singapore với nhiệm vụ trong vòng 4 năm sẽ xây dựng cộng đồng Agile Đông Nam Á ngoài Singapore như Việt Nam, Thái Lan, Indonesia để ThoughtWorks ở khu vực này sẽ được lãnh đạo bởi người bản địa.

Anand: ThoughtWorks là công ty có ba trụ cột:

• Kinh doanh bền vững. Chúng tôi làm phần mềm cho khách hàng của các dịch vụ như Marketting, Ngân hàng. Khi một khách hàng muốn cung cấp một dịch vụ trực tuyến nào đó, chúng tôi cho thể phát triển cho họ từ đầu. Chúng tôi cũng cung cấp các dịch vụ tư vấn về kiến trúc doanh nghiệp, Agile. Từ đó chúng tôi có kinh phí để nuôi sống công ty và hai trụ cột còn lại.

• Phần mềm xuất sắc. Chúng tôi làm việc với các trường đại học, chúng tôi viết sách về phát triển phần mềm. Chúng tôi đã viết được hơn 60 cuốn sách về Phát triển Phần mềm. Ở Singapore chúng tôi đã làm việc với hơn 9 trường đại học. Chúng tôi tổ chức những sự kiện để quảng bá Agile tới những nước khác nhau, tổ chức Coding Dojo và đóng vai trò quan trọng trong lĩnh vực phát triển phần mềm tự do mã nguồn mở (FOSS). Với tất cả những việc đó chúng tôi muốn mọi người có những nhìn nhận khác về việc phát triển phần mềm.

• Công bằng Xã hội. Chúng tôi muốn góp phần làm cho xã hội trở nên công bằng hơn: chúng tôi hỗ trợ để phụ nữ có việc làm và làm việc trong ngành Công Nghệ Thông Tin (CNTT); hợp tác và hỗ trợ các bác sỹ ở nhiều vùng nông thôn; hay đưa các công nghệ như Android, Tablet vào giáo dục ở những khu vực không có điều kiện; v.v..

Chúng tôi có trụ sở ở rất nhiều nước với hơn 2500 nhân viên, đứng ở vị trí thứ hai về cung cấp dịch vụ tư vấn Agile. Chúng tôi mong muốn dùng phần mềm để thay đổi thế giới hiện thời.

Đới: Các anh có đánh giá gì về tình trạng Agile ở khu vực Đông Nam Á?

Gabriel: Như chúng tôi quan sát ở Singapore và các nước khác trong khu vực thì Agile đang ở giai đoạn đầu. Tôi thấy có tương đối nhiều lập trình viên Scrum, nhưng nhìn chung thì họ còn thiếu sự biết tổng quan về Agile, và vẫn còn rất nhiều việc để làm. Do đó chúng tôi thấy mình có thể góp phần cải thiện Agile ở khu vực này.

Anand: Có một điều chúng tôi thấy ở những nước Đông Nam Á như Việt Nam, Thái Lan là mọi người nhầm tưởng rằng để có thể bắt đầu với Agile thì phải biết tiếng Anh. Do đó chúng tôi nghĩ rằng việc mình phải làm là tạo ra các khách hàng địa phương, để giải quyết những vấn đề của địa phương đó chứ không chỉ là xuất khẩu cho chúng tôi, những người có thể hiểu ngôn ngữ và văn hóa địa phương.

Đới: Đâu là cách tốt để giúp khách hàng áp dụng Agile?

Anand: Để hiểu được quan điểm, tầm nhìn của khách hàng là rất khó, nên cách chúng tôi làm không phải đưa cho họ một ước lượng về thời gian và chi phí về phần mềm họ định làm. Và khách hàng lại rất sợ việc bạn không cung cấp bất cứ tài liệu nào. Bởi thế việc đầu tiên chúng tôi làm với khách hàng là bảo họ: hãy cho chúng tôi 2 tuần, chúng ta sẽ cùng nhau xác định phần mềm bạn muốn. Sau hai tuần đó, chúng tôi cho họ biết chi phí và thời gian ước tính và họ sẽ quyết định xem liệu có chi khoản đó cho dự án phần mềm hay không. Và nếu họ bảo rằng chi phí đó là quá lớn thì chúng tôi sẽ không làm dự án đó nữa. Đó cũng là một lựa chọn tốt, bởi khách hàng của chúng tôi sẽ không phải bỏ ra một khoản tiền cho một phần mềm mà không phù hợp với họ. Do đó chúng tôi làm việc rất gần với khách hàng theo cách tăng trưởng từng phần nhỏ một, kéo họ vào việc đối thoại, đó là quá trình xây dựng niềm tin một cách chậm dãi. Chúng tôi không làm theo kiểu "big bang", mà từng phần nhỏ một dựa trên niềm tin.

Đới: Các anh có nhiều kiến thức và kinh nghiệm trong việc giúp một doanh nghiệp áp dụng Agile vì ThoughtWorks là công ty cung cấp dịch vụ tư vấn Agile, vậy thì đâu là cách tốt nhất giúp một doanh nghiệp CNTT áp dụng Agile?

Anand: Mỗi nhóm Agile cần phải có sự tin tưởng lẫn nhau để làm việc. Nếu không có niềm tin trong nhóm, không có Agile. Nếu bạn không tin tưởng nhóm của mình, thì bạn không nên ở đó hoặc nhóm sẽ phải khác đi.

Gabriel: Tôi cho rằng Agile không phải cho mọi nhóm.

Anand: Agile không chỉ là phát triển phần mềm linh hoạt, là kỹ thuật, mà đó là tư duy, nhận thức, hành vi, bởi khi chúng ta nói về Agile là nói về sở hữu tập thể, mọi người đều sở hữu mã nguồn. Khi tôi muốn phát triển hướng kiểm thử (TDD) và quản lý thường để ra một khoảng đệm để cho nhóm có thể mắc lỗi. Như vậy đây là một quá trình học hỏi, nên mọi người phải có sự tin tưởng. Không có lòng tin, bạn không thể phát triển phần mềm linh hoạt. Hãy thay đổi nhóm của mình, hoặc ra đi để tìm một nhóm khác.

Anand: Như chúng tôi thấy, ở rất nhiều quốc gia, Agile là gắn liền Scrum và Scrum là Agile. Scrum là Agile, nhưng bạn không thể có một nhóm Agile hoàn thiện khi không có những kỹ thuật thực hành ở đó. Scrum là để cho quản lý dự án, như cách định nghĩa user story, nhưng bạn cũng cần rất nhiều kỹ thuật thực hành như phát triển hướng kiểm thử (TDD), tích hợp liên tục (CI), làm việc theo cặp. Bạn không thể nói là mình chỉ làm phát triển hướng kiểm thử và không làm tích hợp liên tục, v.v... Bạn phải làm tất cả những kỹ thuật này, bởi chúng liên quan với nhau. Bạn phải thiết lập cơ sở hạ tầng để thực hiện tất cả những kỹ thuật này. Như tôi nhìn thấy, ở rất nhiều công ty bắt đầu Agile, họ tự làm một mình và gặp phải rất nhiều lỗi. Và quản lý CNTT cho rằng, Agile chỉ mang lại cảm giác tốt. Cách tốt hơn để bắt đầu với Agile là làm cùng một huấn luyện viên. Tôi sẽ làm gì khi tôi bắt đầu một môn thể thao mới? Tôi sẽ cần một huấn luyện viên - người sẽ cho tôi những kiến thức căn bản, và giúp tôi thực hành một thời gian. Sau đó tôi sẽ tự thực hành và tháng sau tôi sẽ quay lại và đề nghị một sự trợ giúp nào đó. Chúng ta cũng nên làm như thế với Agile. Khi bạn có một nhóm Agile nòng cốt, hãy để cho họ làm việc 3 tháng đến 6 tháng và nhóm này sẽ huấn luyện phần còn lại của tổ chức. Hãy làm điều này một cách chậm dãi, đừng áp dụng Agile cho cả 1000 người trong 3 tháng. Từ một nhóm hãy nhân rộng ra một trăm, một trăm nhân rộng ra 300 trăm, từ ba trăm ra một nghìn.

Gabriel: Như tôi nói trong buổi nói chuyện tối qua, hãy làm mọi thứ từng bước một, đừng làm tất cả trong một lần. Hãy để mọi người có kinh nghiệm từng bước một, hãy giúp mọi người tham gia. Và một điều quan trọng là để mọi người có cơ hội mắc sai lầm, từ đó họ sẽ học được. Do đó tôi nói rằng Agile không phải cho tất cả. 

Đới: Trong rất nhiều trường hợp thì những người biết về Agile là những quản lý cấp trung, nhưng bằng cách nào những quản lý này có thể thuyết phục các quản lý cấp cao vì họ chỉ quan tâm tới một số chỉ số mà không phải cách làm việc?

Gabriel: Hãy bắt đầu với những dự án nhỏ và nhóm nhỏ như một dự án thử nghiệm để mọi người có thể học được từ những thất bại nhỏ và nhanh. Sau đó nhóm này sẽ ảnh hưởng tới những nhóm khác và tăng quy mô lên. 

Anand: Từ quan điểm cá nhân, như người đã cung cấp rất nhiều dịch vụ tư vấn, huấn luyện, tôi thấy thì chỉ một trong ba người quản lý cấp trung, cấp cao và người làm thực sự mà không tham gia thì việc chuyển sang Agile sẽ thất bại. Bởi thế cả 3 đối tượng này đều phải đánh cược vào Agile. Nên tôi thấy là quản lý cấp trung cần phải tìm một trong những lãnh đạo cấp cao thực sự đổi mới nhất để thuyết phục. Tôi tin là ở mọi công ty đều có những lãnh đạo như thế. Sau đó hãy chọn một việc gì đó nhỏ như dự án nhỏ, nhóm nhỏ và thời gian làm việc ngắn. Chia nhỏ dự án ra và lấy thành công nhỏ này để thuyết phục lãnh đạo cấp cao.

Gabriel: Như tôi nhìn thấy ở những công ty áp dụng Agile thành công, thì họ tìm ra một quản lý cấp trung để thực thi. Quản lý này sẽ hướng dẫn nhóm làm việc nội bộ với nhau theo cách Agile, sau đó khi cần báo cáo cho quản lý cấp cao thì hãy chuẩn bị tất cả những báo cáo mà họ muốn xem như biểu đồ Gantt, tài liệu thiết kế kiến trúc, v.v... Sau đó hãy báo cho họ biết rằng chúng tôi đang làm Agile và họ sẽ bảo vậy thì bây giờ chúng ta hãy làm Agile. Đó là cách chuyển đổi dễ dàng hơn. 

Anand: Tôi đồng quan điểm với Gabriel. Nếu bạn muốn một dự án thành công thì cần phải có sự đồng lòng của tất cả mọi người. Hãy dành ra một quản lý để chuyển đổi những thứ mà dự án đang có sang các tài liệu mà quản lý cấp cao muốn xem và báo cáo cho họ hàng tuần như phân tích điểm chức năng, biểu đồ Gantt, tài liệu thiết kế kiến trúc. Rồi sau đó họ sẽ nhận ra, sẽ ồ, các anh đang chuyển giao cho khách hàng mỗi tuần, hãy cho tôi xem cách các anh đang làm. Và bạn có thể nói chúng tôi đang Agile.

Anand: Một điều quan trọng nữa là khi bắt đầu hãy dùng một dự án nhỏ và mới thay vì làm một dự án lớn với lượng mã nguồn lớn đã tồn tại. Từ đó bạn sẽ có một thành công nhỏ, sau đó hãy nhân thành công này lên, và làm cho nó lớn dần lên.

Đới: Đâu là những dấu hiệu cho thấy một công ty đang áp dụng sai Agile?

Gabriel: Khi nhóm làm việc yên lặng, đó là một dấu hiệu tệ bởi nhóm Agile phải chia sẻ thông tin, nên họ luôn phải nói chuyện với nhau, họ cần phải có môi trường động.

Anand: Nếu ở những buổi họp đứng, mà mọi người luôn nhìn vào quản lý, và nói điều tôi đã làm hôm qua, điều tôi sẽ làm hôm này, thì đó không phải họp đứng, đó là báo cáo cho quản lý dự án. Trong họp đứng mọi người đối xử với nhau công bằng và chia sẻ thông tin. Ví dụ trong buổi họp này ai nói rằng tôi đang có một vài vấn đề và đang làm mọi việc chậm, cũng giống như ai đó nói rằng hôm qua bạn làm chậm, lý do là gì? Và ai đó sẽ nói là tôi biết đoạn mã nguồn đó, tôi sẽ chia sẻ cho bạn. Như tôi đã nói là trong nhóm Agile chúng ta cần sự tin tưởng, khi đó chúng ta mới có thể nêu vấn đề và chia sẻ chúng. Nếu trong các buổi họp, người quản lý luôn là người bắt đầu, thì đó là sai, nên luôn bắt đầu từ ai đó một cách ngẫu nhiên. Người quản lý cũng nên báo cáo cho nhóm những việc giống như những thành viên khác: tôi đã làm hôm qua là…, tôi sẽ làm hôm nay là... Mọi người nên giúp đỡ quản lý dự án cũng giống như là quản lý dự án giúp đỡ mọi người. 

Trong họp cải tiến chỉ có quản lý hoặc một số người nào đó lên tiếng, đó cũng là những dấu hiệu cho thấy việc áp dụng sai các kỹ thuật của quản lý dự án. Ở buổi họp này tất cả chúng ta cần kiểm tra lại mọi thứ. Hãy gỡ bỏ mọi nỗi lo lắng và sự tin tưởng lẫn nhau là cần thiết. 

Nếu bạn thấy mã nguồn không có kiểm thử, đó không phải là nhóm Agile. Nếu có nhiều nhánh mã nguồn khác nhau, thay vì chúng được tích hợp vài lần một ngày thì lại một tuần một lần, đó chính là điểm sai. Có rất nhiều những dấu hiệu tương tự như thế cho ta thấy rằng nhóm đang làm sai.

Đới: Mọi người thường nói là chỉ những nhóm có kỹ thuật tốt mới có thể áp dụng Agile và nhóm của tôi không phù hợp với Agile. Ý kiến của các anh về việc này như thế nào?

Anand: Sự khác biệt giữa nhà phát triển Agile và phi Agile không chỉ nằm ở các kỹ thuật, như ngôn ngữ lập trình hoặc kỹ thuật lập trình hướng đối tượng, mà ở hành vi. Nếu bạn là Agile thì khi có vấn đề, bạn phải nói là mình có vấn đề. Tôi cho rằng vấn đề lớn nhất là hành vi đã xây dựng trong quá khứ. Bạn có thể dạy người khác hầu hết các kỹ thuật ở một mức độ nhất định. Hành vi là rất quan trọng và khó thay đổi: Trong họp đứng, tôi cần những người dám giơ tay và nói tôi cần sự hỗ trợ, thậm chí cả quản lý dự án cũng thế. Mọi người cần phải nghĩ là tôi có thể mắc lỗi và tôi sẽ học được từ những thứ này và tôi sẽ làm được. Do đó thái đội là thử thách lớn hơn so với các yếu kém về mặt kỹ thuật. 

Gabriel: Một việc rất quan trọng là cần phải tạo ra môi trường giúp mọi người có thể mắc sai lầm, có thể học và chia sẻ, để mọi người nói là tôi không biết, tôi cần sự giúp đỡ. Nhóm Agile cần phải làm việc cùng nhau và tiến bộ cùng nhau. Nhóm Agile cung cấp môi trường rất tự nhiên để học. Bởi thế tôi nói nếu nhóm Agile yên tĩnh thì đó là biểu hiện xấu. Mọi người đang không giúp đỡ, chia sẽ, giải quyết vấn đề và học cùng nhau. 

Anand: Trả lời một cách ngắn gọn thì mọi nhóm đều có thể thử Agile, và khi dựng nhóm thì ta nên tìm những người với hành vi đúng và cả những kỹ năng thực hành. Ta không chỉ nhìn vào mọi người với khả năng kỹ thuật, mà cả vào với những thái độ muốn học, unlearn, và thử điều mới, v.v…

Đới: Hai anh có thể gợi ý cho chúng tôi một số cách giúp đỡ mọi người trong cộng đồng Agile Việt Nam?

Gabriel: Theo tôi thì các bạn đang làm những điều tốt. Hãy mang những người địa phương đã áp dụng Agile với những kinh nghiệm thất bại, thành công và chia sẻ cho cộng đồng. Khi bắt đầu với Agile hãy bắt đầu nhiều với sách, bài viết.

Anand: Hãy chọn một vấn đề nào đó của xã hội VN, hãy kêu gọi những lập trình viên cùng giải quyết bằng một dự án mã nguồn mở. Hãy làm những hoạt động như Coding Dojo, vào một ngày trong tuần để mọi người cùng đến và chia sẻ thực hành, chia sẻ: lập trình cặp, viết mã, thực hành Agile. 

Gabriel: Hãy chọn một vấn đề nào đó, đưa mọi người tới cùng một nơi, và cùng giải quyết một vấn đề, qua đó họ có kết quả để mọi người nhìn, và mọi người cũng có thể thực hành. 

Anand: Ở ThoughtWorks, mọi người khi tới với ThoughtWorks ở Ấn Độ, họ sẽ cùng nhau tới ĐH ThoughtWorks, cùng nhau giải quyết một vấn đề đang tồn tại của địa phương đó, thành phố đó. Bạn có hỗ trợ mọi người tìm ra vấn đề và để mọi người đóng góp 5đô la, 10 đô la cho dự án đó để mua một vài thứ cho dự án. Qua đó bạn cũng có điều gì đó để chia sẻ với cộng đồng.

Đới: Cảm ơn hai anh.