Tiếp nối sự kiện đầu tiên vào ngày 16/05 trong chuỗi sự kiện [IT Success] Webinar, Webinar thứ hai của ITviec tập trung đào sâu hơn vào từ khóa “Năng suất” trong quá trình phát triển phần mềm. Hãy cùng xem lại bản ghi Recording và Transcript sự kiện chi tiết nhé! 

Phiên Thảo luận – Tối ưu năng suất qua các góc nhìn khác nhau

Chị Ninh Phạm (Host):

Thưa quý vị, với 1 dự án phần mềm, thì việc lựa chọn công nghệ cũng như kiến trúc giải pháp là 1 yếu tố vô cùng quan trọng. Điều đó đặt nền tảng cho 1 dự án phát triển phần mềm, và cũng quyết định sự phù hợp là dự án đó có thể vận hành một cách trơn tru để có thể tối ưu được thời gian cũng như là hiệu suất của dự án hay không. Để hiểu rõ hơn được điều này dưới góc nhìn kỹ thuật, Ninh rất muốn nghe những chia sẻ của các Diễn giả.

Xin chào Diễn giả Nguyễn Bá Dũng. Dưới góc nhìn của một người làm rất chuyên sâu về mảng kỹ thuật, thì Dũng có thể chia sẻ với các khán giả tham gia chương trình ngày hôm nay về việc lựa chọn công nghệ và các kiến trúc giải pháp có ảnh hưởng như thế nào tới năng suất của dự án phần mềm hay không?

Anh Nguyễn Bá Dũng:

Dạ em cảm ơn chị Ninh. Trước hết Dũng chào tất cả mọi người tham gia sự kiện ngày hôm nay, chúc mọi người 1 buổi tối tốt lành và sẽ enjoy buổi chia sẻ ngày hôm nay. 

Quay lại với câu hỏi, việc lựa chọn công nghệ cũng như là giải pháp thật ra rất quan trọng đối với năng suất của đội ngũ. Nó có thể là 1 chìa khóa để tối ưu năng suất làm việc, nhưng nó cũng có thể là 1 vấn đề vô cùng nhức nhối nếu như chúng ta đưa ra những lựa chọn sai lầm, không hợp lý và phù hợp với đội ngũ của chúng ta. May mắn 1 điều là với sự phát triển của công nghệ ngày nay rất mạnh mẽ, nó đưa ra cho chúng ta rất nhiều sự lựa chọn và chúng ta có thể dễ dàng lựa chọn giải pháp kiến trúc, cụ thể là như sau. 

Các ngôn ngữ lập trình phổ biến hiện nay thì hầu hết đã trở nên rất linh hoạt vì các ngôn ngữ đó đã có thể hỗ trợ nhiều hình mẫu lập trình hơn (e.g. PHP bắt đầu bằng Procedural Programing, nhưng bây giờ cũng đã dần hỗ trợ theo hướng đối tượng rồi và với những version gần đây – OOP nhiều hơn; hay C# bắt đầu là ngôn ngữ lập trình theo hướng đối tượng thì đang dần hỗ trợ thêm functional programming). Cho nên các đội ngũ của chúng ta nếu cảm thấy phù hợp với PHP hay C# thì hoàn toàn có thể sử dụng và apply cho các business requirements với nhiều hình mẫu lập trình khác nhau.

Bên cạnh đó có 1 điểm vô cùng quan trọng khi lựa chọn công nghệ, đó là sự quen thuộc của công nghệ đó đối với đội ngũ, luôn luôn cần phải được ưu tiên cao. Vì năng suất của đội ngũ sẽ luôn được đảm bảo nếu như những kỹ sư được làm việc với những công cụ hay những công nghệ mà họ đã quen thuộc từ trước. Việc sử dụng những công nghệ xa lạ hoặc là quá ít phổ biến sẽ mở ra cho chúng ta những thử thách rất lớn. VD như chi phí cao cho những buổi huấn luyện sâu rộng cho team kỹ sư, hoặc 1 số rủi ro tiềm tàng từ các kỹ sư trong quá trình làm việc – họ phải làm quen với những công nghệ, những ngôn ngữ mới thì nó cũng rất là khó khăn và thử thách đối với họ. 

Cho nên đứng dưới góc độ của Dũng thì Dũng sẽ chỉ tập trung vào 2 tiêu chí lớn nhất để khi lựa chọn công nghệ, làm sao để tối ưu năng suất được tốt nhất cho đội ngũ của mình:

Thứ nhất là công nghệ mà Dũng chọn sẽ phải hiện đại và phổ biến ở thời điểm hiện tại. Lí do là để đảm bảo chúng ta sẽ luôn có sự hỗ trợ từ phía những nhà phát triển, tức là chúng ta sẽ luôn có những bản cập nhật mới, những bản vá sửa lỗi khi mà phần mềm đó không còn chạy hiệu quả nữa thì mình sẽ luôn được hỗ trợ, và nếu chúng ta có thắc mắc thì luôn có sự hỗ trợ từ cộng đồng lập trình viên trên toàn thế giới.

Thứ hai, như có nói ở trên thì công nghệ bắt buộc phải quen thuộc với đội ngũ lập trình. Vì nó mang lại nhiều lợi ích cũng như giảm thiểu nhiều rủi ro trong quá trình phát triển phần mềm. 

Tuy nhiên cũng có trường hợp/câu hỏi là chưa có team, thì chúng ta có thể dựa vào tình hình của thị trường lao động để chúng ta lựa chọn. VD như chúng ta có thể chọn PHP nếu như sau khi chúng ta research trên thị trường và thấy là thị trường đang có nhiều kỹ sư lập trình giỏi về PHP, chúng ta hoàn toàn có thể start với PHP được. 

Bên cạnh việc lựa chọn công nghệ đúng đắn, thì 1 yếu tố đối với Dũng cũng rất là quan trọng mà ảnh hưởng cực kỳ lớn tới năng suất team, đó là những công cụ tự động hóa. Những công cụ tự động hóa là những công cụ sẽ giúp cho lập trình viên có thể tập trung vào việc phát triển và sáng tạo phần mềm của họ. Và những công cụ sẽ tự động hóa các công đoạn lặp đi lặp lại trong quá trình phát triển phần mềm của mình, VD như quality checks (kiểm tra chất lượng), deployments (triển khai) hay system monitoring (giám sát hệ thống) nên được xử lý tự động.

Ngày nay với sự phát triển của văn hóa DevOps, chúng ta đã có rất nhiều công cụ có sẵn để giúp đỡ việc cài đặt các công cụ tự động hóa này một cách dễ dàng và sẽ giúp cho đội ngũ chúng ta tăng năng suất cực kỳ nhanh luôn. 

Chị Ninh Phạm (Host):

Cảm ơn Dũng với các chia sẻ rất chi tiết và chị nghĩ cũng rất là thực tiễn nữa. 

Vậy thì ngày nay, khi nói đến kiến trúc Module hóa, thì chúng ta hay nhắc đến kiến trúc Microservices. Vậy thì đối với các dự án phần mềm, với những dự án nào có thể đi theo hướng event driven hay là kết hợp với Microservices phase. 

Câu hỏi đặt ra là liệu với các dự án phần mềm thì hệ thống nào cũng phù hợp với kiến trúc Microservices hay không? Dũng có thể chia sẻ chi tiết hơn về phần này được không?

Anh Nguyễn Bá Dũng:

Microservices thật sự là 1 kiến trúc vô cùng hiện đại và đã được nhiều công ty công nghệ sử dụng, nhất là các công ty lớn như là Google, Netflix hay Amazon. Bên cạnh đó thì Microservices cũng được hỗ trợ bởi nhiều công nghệ mới, và nó đang cực kỳ phát triển ở thời điểm hiện tại. Tuy nhiên, theo quan điểm của Dũng thì Microservices không phải luôn luôn là sự lựa chọn tốt nhất, vì những lí do như sau. 

Lí do đầu tiên và cũng là lớn nhất là vấn đề về mặt chi phí. Chi phí để phát triển Microservices rất lớn. Chúng ta vừa tốn về mặt thời gian cũng như về mặt effort để cho việc thiết kế ban đầu, thì Microservices yêu cầu thiết kế ban đầu phải rất chuẩn chỉ ngay từ lúc đầu luôn. Ngoài ra khi cần thay đổi cũng sẽ rất mất thời gian vì phải thay đổi nhiều services khác nhau để đảm bảo những services đó vẫn có thể integrate được với nhau tốt, còn ngoài những service contract.

Bên cạnh đó, chi phí vận hành và chi phí hạ tầng ban đầu cho Microservices cũng cực kỳ lớn, vì chúng ta sẽ phải chạy trên những con máy khác nhau để có thể deploy được nhiều services khác nhau, và kiến trúc như vậy hầu như chỉ khả thi với các hệ thống triển khai trên cloud platforms thôi, vì như vậy thì mới dễ dàng được. Còn nếu chúng ta triển khai trên máy mà work station là máy vật lý thì sẽ thực sự là 1 thử thách rất lớn với đội ngũ IT.

Lí do thứ 2 cũng quan trọng không kém là về mặt phức tạp. Microservices là 1 kiến trúc vô cùng phức tạp và đòi hỏi đội ngũ kĩ thuật có chuyên môn rất cao để đảm bảo chất lượng của sản phẩm đầu ra. Theo Dũng quan sát thì điều này vẫn đang là một thử thách khá lớn đối với thị trường lao động ở VN hiện nay, vì chúng ta hiện vẫn đang quen thuộc với những công nghệ phổ biến trong những năm gần đây. Những công nghệ về Microservices vẫn còn khá mới với thị trường của chúng ta, chúng ta sẽ cần 1 khoảng thời gian nữa để thị trường lao động của mình có thể làm quen được với những công nghệ này, có thể nâng chuyên môn của mình lên để đáp ứng được với yêu cầu của Microservices. 

Ngoài ra 1 điểm cũng khá quan trọng với các doanh nghiệp là Team size – tức là số lượng thành viên trong đội ngũ. Microservices chỉ phù hợp với đội ngũ lớn vì sẽ có rất nhiều vai trò cần người có chuyên môn giỏi nhất đảm nhiệm vì mỗi service nó là 1 chuyên môn khác nhau, thì mình cần người phải giỏi về chuyên môn đấy để nằm. Đó là 1 thách thức cũng rất là lớn. VD như payment service cần được chịu trách nhiệm bởi một team strong về xử lý payment, phải biết cách integrate với nhiều ngân hàng khác nhau hoặc các payment ways khác nhau. Vì vậy nếu bạn chỉ có một team nhỏ, không nên chọn đi với Microservices. 

Tóm tắt lại, nếu một doanh nghiệp không có quá nhiều tiền, cụ thể hơn là các doanh nghiệp start-up, cũng như không có đội ngũ kĩ thuật đủ lớn và mạnh, Microservices có lẽ không phải là một hướng đi tốt cho doanh nghiệp của chúng ta vào thời điểm đó.

Ngược lại, thì chúng ta hoàn toàn bắt đầu 1 dự án bằng những bước nhỏ, nhưng chúng ta sẽ follow hết tất cả những best practices. Ví dụ như chúng ta sử dụng web framework hoặc là ngôn ngữ nào thì có thể follow theo best practices tương ứng, cũng như tuân thủ những nguyên tắc mà ngôn ngữ lập trình hoặc framework đưa ra, thì lúc đó chúng ta vẫn có thể đảm bảo được delivery nhanh, có thể tạo ra sản phẩm nhanh và chất lượng sẽ ở mức có thể chấp nhận được.

Và dần dần khi doanh nghiệp lớn dần lên thì chúng ta có thể scale cái mô hình sản phẩm của chúng ta hơn. Keyword ở đây vẫn là cần phải follow theo best practices, và tuân thủ tất cả các nguyên lý phổ biến của lập trình theo hướng đối tượng, chính là Solid Principles. Đây là điều mà chúng ta cần tuyệt đối tuân thủ khi sử dụng ngôn ngữ lập trình theo hướng đối tượng. 

Chị Ninh Phạm (Host):

Cảm ơn Dũng vì các chia sẻ vô cùng cụ thể.

Các bạn thấy là trong phần chia sẻ của Dũng, có 1 phần cũng rất là hữu ích, đó là về tự động hóa quy trình. Đây là 1 trong những giai đoạn mà có thể nói là với 1 dự án phần mềm,  thì về cơ bản sẽ trải qua các life circle khác nhau. Và trong đó có 1 giai đoạn rất quan trọng, đó là tự động hóa quy trình, tức là giai đoạn mà mình đưa các công cụ vào để tự động hóa, và nó sẽ giúp làm giảm thời gian và manual task của con người ở trong đó, giúp mọi người có nhiều thời gian hơn cho những công việc mang tính cải tiến hơn.

Ninh rất muốn Dũng có thể chia sẻ thêm về các công cụ liên quan đến Automation dưới góc độ của Dev cũng như là Test, để mọi người có thể hiểu hơn về các công cụ Best Practices gần đây được không?

Anh Nguyễn Bá Dũng:

Đây là 1 điểm mà Dũng thấy rằng rất nhiều team hoặc là dự án mới hầu như bị bỏ qua, mọi người không để ý phần Automation này, mà thường mọi người sẽ làm tay, manual actions rất là nhiều. Tại vì mọi người nghĩ rằng việc set up Automation nó rất khó và mất thời gian nên mọi người không có muốn xài ngay từ ban đầu. Tuy nhiên, với sự phát triển của DevOps culture ở thời điểm hiện tại, chúng ta có quá nhiều công cụ để giúp cho việc automation trở nên dễ dàng hơn với bất kỳ ai, không phải chỉ với DevOps engineer mà kể cả những người Software engineer bình thường như chúng ta cũng hoàn toàn có thể set up được những điều đó luôn. 

Công cụ chủ đạo trong việc tự động hóa các tiến trình của DevOps chính là CI/CD. Chúng ta sẽ có các platforms tiêu biểu và miễn phí như Github Actions, Gitlab CI, Jenkins ; mọi người hoàn toàn có thể tải về và sử dụng rất dễ dàng.

Một ví dụ là ở NFQ, mỗi dự án chúng tôi đều triển khai các CI/CD pipelines tùy vào scale mà cài đặt ở thời điểm ban đầu sẽ khác nhau. Tuy nhiên ở NFQ sẽ luôn ưu tiên làm việc đó vì đã aware rất kĩ rằng những bước đó cần được automate để rút gọn thời gian và tăng độ chính xác, vì với các manual actions thì các lỗi sai sót do con người hoàn toàn có thể xảy ra, và nó sẽ gây ra các vấn đề khá là nghiêm trọng, nhất là vấn đề liên quan đến deployment trên production environment.

Đối với một dự án PHP bắt đầu từ con số không, chúng tôi sẽ sử dụng PHPUnit cho unit/functional testing, PHPCSFixer để chuẩn hóa coding standard, thì chúng tôi luôn build những bộ Coding standard và share nó trong các dự án khác nhau. Ngoài ra thì chúng tôi có sử dụng SonarQube để quản lý chất lượng code tổng quát. Về mặt Deployment thì chúng ta có Capistrano hoặc AWS Code Deploy là công cụ giúp tự động hóa quá trình deployment và nó cứ lặp đi lặp lại như vậy, nó sẽ không có chuyện là ai đó gây ra 1 lỗi nào đó trong quá trình đấy, vì nó được thực thi bằng máy cả rồi.

Qua nhiều năm thực hiện với các automation tools như thế này, Dũng thấy 1 điều là hầu như các engineer họ không còn phải lo lắng và quan ngại về câu chuyện “Bây giờ code của tôi đã deploy lên rồi thì làm sao để đưa lên production để cho Tester hoặc là Product Owner của tôi nhìn thấy cái đó sớm được?”, thì điều đấy giờ đây đã được giải quyết khá là dễ dàng. Họ chỉ cần push code lên Repository và máy sẽ làm hết mọi thứ cho họ ở đó. Thật sự là điều này khiến cho tất cả mọi người đều happy, từ engineer cho tới các stakeholder, tới tester, vì code lên rất là nhanh.

Chị Ninh Phạm (Host):

Cảm ơn Dũng về những chia sẻ rất là cụ thể. Và hi vọng rằng các khán giả khi mà tham gia chương trình Webinar ngày hôm nay sẽ có những thông tin hữu ích về những công cụ Automation.

Và cùng liên quan tới tự động hóa quy trình, Ninh rất muốn lắng nghe những chia sẻ dưới góc nhìn là những người vận hành team và quản lý quy trình. Thưa diễn giả Tony Vũ, bạn có thể chia sẻ với các khán giả tham gia Webinar ngày hôm nay góc nhìn của mình về việc tự động hóa quy trình đã giúp gia tăng năng suất như thế nào với dự án phần mềm, dưới góc nhìn là 1 Quản lý và overview về mặt quy trình được không ạ?

Anh Tony Vũ (Hùng):

Cảm ơn chị Ninh. Gửi lời chào tất cả mọi người.

Thật ra phần Dũng chia sẻ nghe rất hấp dẫn và đã cover hết mọi thứ rồi. Thì khi xét về mặt business, nó cũng là về thời gian và chi phí thôi. Khi mình áp dụng những công cụ Automation như vậy, nó giúp giảm thời gian, mà giảm được thời gian làm việc của các bạn cũng có nghĩa là giảm chi phí cho doanh nghiệp. 

Nhưng mà ngoài ra mình còn quan sát thấy được 1 điều nữa, đó là giảm stress cho team QA chẳng hạn. Ví dụ như mình apply automation test, thì trước mình có 1 sản phẩm cho bên Úc, sản phẩm mobile mỗi lần launching là y như rằng sẽ có 1 lỗi nào đó mà khách hàng hay phát hiện ra. Nhưng múi giờ bên Úc và bên mình bị lệch, nên khi khách hàng phát hiện ra thường là 3-4h sáng bên Việt Nam, thì lúc đó mình sẽ bị gọi dựng dậy và bị sếp mắng là “Tại sao tụi em không phát hiện ra lỗi trước khách hàng?”. Điều đó khá stress vào mỗi lần release.

Sau đó team mới bắt đầu mày mò, apply được automation. Mình sẽ bắt đầu với những điều vô cùng đơn giản. Ví dụ như cứ 2 tiếng thì giả lập flow download app từ trên Appstore về rồi log in, test một số flow cực kỳ cơ bản, load thông tin về profile. Nếu có lỗi gì thì sẽ alert qua Slack, thì lỗi đó team sẽ biết trước và xử lý trước. Nói chung là mình sẽ biết trước nếu có lỗi trong phần mềm của mình, chứ không nên để khách hàng là người escalate lên. Thông qua việc áp dụng automation, các team, đặc biệt là team Development cảm thấy rất thoải mái và tự tin cho những lần release tiếp theo. Đó là 1 chia sẻ dưới góc độ làm việc trực tiếp với team, chủ yếu là về mặt mọi người cảm thấy đỡ stress hơn, đó là lợi ích thực sự của việc apply automation.

Chị Ninh Phạm (Host):

Cảm ơn Hùng.

Vậy Trung thì sao? Ở TymeX thì bạn thấy rằng việc tự động hóa quy trình đã mang lại những ích lợi và hiệu quả như thế nào trong việc vận hành team?

Anh Trung Nguyễn:

Cảm ơn chị Ninh và xin chào mọi người.

Thật ra nghe những chia sẻ của anh Hùng và Dũng thì cũng cover khá hết các ý mà Trung định chia sẻ rồi. Mình bổ sung thêm 1 cái ví dụ thú vị về Automation test ở TymeX. Bên TymeX của mình sẽ làm sản phẩm cho Banking, thì trong Banking sẽ có 1 khái niệm là Disaster Recovery. Đây là việc mà mình sẽ có 1 kế hoạch, 1 quy trình tổ chức để khi mình có 1 “thảm họa” thì mình sẽ cố gắng khôi phục hệ thống 1 cách nhanh nhất. Tại vì là mảng Banking nên mình không thể làm gián đoạn việc sử dụng của mọi người được. 

Trước đây khi mình chưa có Automation, thì mỗi khi làm Disaster Recovery, vì hệ thống của Banking rất lớn và mình phải đảm bảo tất cả các feature hay functions phải được test cực kỳ kĩ lưỡng trước – trong – sau khi mình làm Disaster Recovery. Trước đây khi không có Automation test thì bọn mình phải thực hiện bằng tay hết sức vất vả cực nhọc, nhưng bây giờ có Automation test rồi thì việc nó nhẹ nhàng hơn, mình cũng đỡ stress hơn và mình cũng tự tin hơn ở mỗi lần tiến hành công việc đó, một công việc rất là quan trọng trong hệ thống Banking.

Chị Ninh Phạm (Host):

Cảm ơn Trung

Như vậy là chúng ta có thể thấy được là qua những chia sẻ của các Diễn giả, vai trò của các yếu tố lựa chọn công nghệ, kiến trúc công nghệ cũng như là ảnh hưởng của tự động hóa quy trình mang lại những lợi ích rất lớn và từ đó, góp phần gia tăng năng suất cho các dự án phần mềm.

Cảm ơn các chia sẻ của các bạn.

Phiên Thảo luận – GenAI trong tối ưu năng suất team IT

Chị Ninh Phạm (Host):

Ngoài việc chúng ta lựa chọn công nghệ, cũng như là lựa chọn kiến trúc giải pháp và lợi ích của việc tự động hóa quy trình, việc ứng dụng các công cụ Generative AI cũng mang lại những hiệu quả rất lớn đối với quá trình phát triển phần mềm. 

Thưa các bạn, trong báo cáo Salary Report gần đây của ITviec: “Tại Việt Nam, các chuyên gia IT thể hiện sự quen thuộc đáng kể với AI, phản ánh xu hướng chấp nhận, sử dụng và hiểu biết rộng rãi với 50% chuyên gia IT sử dụng GenAI hàng ngày để đề xuất và hoàn thiện code, nghiên cứu, tổng hợp thông tin, cải tiến/tái cấu trúc code, v.v.”. Có thể thấy rằng xu hướng sử dụng các công cụ Generative AI gần đây đã trở nên dần phổ biến. 

Ninh rất muốn lắng nghe các chia sẻ của các Diễn giả. Các bạn đánh giá như thế nào về hiệu quả của các công cụ Generative AI sử dụng trong việc lập trình phần mềm? VD như các công việc review code, suggest code hoặc optimize code, và một số công cụ AI phổ biến hiện này mà các Software Engineer thường dùng như ChatGPT-4, GitHub Copilot, v.v. 

Xin mời Dũng có thể chia sẻ dưới góc nhìn của một người làm chuyên sâu về kỹ thuật về hiệu quả của các công cụ này được không?

Anh Nguyễn Bá Dũng:

Dạ vâng cảm ơn chị ạ. 

Về Generative AI thì Dũng cũng như các đồng nghiệp ở NFQ đang sử dụng ChatGPT để generate content tiếng Anh trong việc viết email, feedback, summary hay recap từ meeting notes. Tuy nhiên việc sử dụng ChatGPT chủ yếu dành cho content nhiều hơn là coding, thì nó cũng không trực tiếp ảnh hưởng đến năng suất làm việc của IT teams.

Tuy nhiên, khi mà ChatGPT phổ biến thì các bạn Engineer cũng đã có sử dụng thử để generate code, tuy nhiên kết quả không được như mong đợi cho lắm vì code của ChatGPT sinh ra không chạy được. Có trao đổi với các bạn thì nguyên nhân chính là các bạn vẫn chưa biết cách để làm sao tạo ra cái prompt, tức là 1 yêu cầu cho AI để AI có thể tạo đúng được như mong muốn của chúng ta. Và để đưa ra 1 code mà thực sự có thể chạy được và hiệu quả thì bên cạnh đó nó vẫn cón 1 vấn đề nữa, đó là model của GPT là model generic nên hiệu quả sinh code cũng sẽ không được cao cho lắm.

Một trong những client của NFQ cũng là client mà Dũng đang làm việc cho có mua Github Copilot bản business để cho đội ngũ kĩ sư của họ sử dụng, thì họ khá open với việc đó và mình có thể đăng ký để xài, và mình sẽ là người tự đưa ra đánh giá hiệu quả thôi. Tuy nhiên theo như Dũng quan sát thấy thì có vẻ kết quả cho thấy hiệu quả không được đáng kể lắm. Vì vấn đề đưa ra yêu cầu của nó vẫn là 1 thử thách khá là lớn. Những cái code được sinh ra cũng cần test đi test lại, cũng như là phải kiểm tra xem thực sự cái code đã đúng ý của mình hay là chưa. Nên hiện tại thì hiệu quả vẫn chưa thấy được kết quả rõ ràng cho lắm. 

Sau quá trình nghiên cứu 1 thời gian thì Dũng thấy có 1 model khác là Claude, nó có 1 khả năng chuyên biệt dành riêng cho việc sinh ra code. Thì Dũng đang tìm hiểu về hiệu năng của cái model này, vẫn đang trong quá trình tìm hiểu thôi, cũng chưa thực sự có thể khẳng định rằng là nó sẽ là 1 giải pháp tốt. 

Dũng có thể chia sẻ thêm 1 điều nữa là trong cộng đồng lập trình viên của chúng ta hiện nay, mặc dù là mọi người rất welcome cho việc sử dụng AI, mọi người cũng có aware về câu chuyện security khi mà sử dụng AI. AI nó có thể đọc code của mình thì code của mình có nguy cơ bị leak ra ngoài và có thể bị leak những cái sensitive information. Tuy nhiên, đội ngũ Engineer của chúng ta cũng rất welcome và muốn thử những công cụ ấy, vì nó thực sự rất hứa hẹn. Ngoài ra, có 1 điều Dũng thấy khá rõ là cộng đồng của chúng ta thật sự vẫn đang thiếu những khóa học, trainings giúp cho engineer quen thuộc hơn với việc sử dụng GenAI.

Hiện tại, việc dùng AI vẫn đang là tự phát cá nhân khá là nhiều, Dũng thấy trên Facebook có một số hội nhóm về AI và họ có thể đưa ra những chia sẻ, nhưng thật ra để có những nghiên cứu chuyên sâu hoặc là huấn luyện bài bản thì vẫn đang khá là thiếu thốn. Về mặt của Dũng thì Dũng vẫn đang khuyến khích kĩ sư của mình thử nghiệm AI nhiều hơn, luôn luôn nhờ 1 điều rằng là mình phải secure cái sensitive information, đảm bảo rằng các thông tin đó không được access bời AI, như vậy thì vẫn ổn. Còn lại thì hãy cứ trải nghiệm, mặc dù hiệu quả vẫn còn là một dấu chấm hỏi. Có thể  là trong vòng 1-2 năm nữa thì chúng ta sẽ có những cái dấu hiệu khả quan nhiều hơn

Chị Ninh Phạm (Host):

Cảm ơn Dũng với những chia sẻ. 

Vậy thì Dũng nghĩ sao về những nguyên nhân của việc kết quả mình nhận được chưa đúng? VD như dòng code không chạy chẳng hạn. Thì nguyên nhân có thể bắt nguồn do đâu?

Anh Nguyễn Bá Dũng:

Như hồi nãy em có đề cập, thì nguyên nhân chính vẫn là vấn đề đưa ra yêu cầu của chúng ta đang không biết làm sao để có thể đưa ra 1 yêu cầu cross-structure, và nó có thể được hiểu đúng được bởi AI. Thì đã có kha khá những tổ chức họ đưa ra những concept về prompt engineering, là lúc đó họ sẽ đưa ra những phần như là: đầu tiên mình phải đưa ngữ cảnh cho con AI đó để nó có thể hiểu ngữ cảnh của chúng ta cần generate 1 cái dự án mới được sử dụng Java, sử dụng Sprint Framework, v.v ví dụ như vậy.

Thứ 2 có thể là mong đợi của mình về cái code đó phải thực sự chạy được trên Java, version bao nhiêu, v.v, và mình có thể đưa ra thêm 1 số tiêu chuẩn nữa như số lượng code sinh ra không được vượt quá bao nhiêu đấy, thì mình sẽ phải đưa hết tất cả những thông tin mà mình muốn cho AI, thì AI mới có thể hiểu và nó sẽ cố gắng để optimize đoạn code mà nó sinh ra cho mình. 

Hầu hết thì mọi người sẽ không thực sự biết cách làm sao để mình structure được cái prompt engineering đấy. Hiện tại mặc dù prompt structure cũng có nhiều người đã đưa ra một số prompt structure, VD như tốt cho ChatGPT nhưng lại không tốt cho Claude, thì hiện tại vẫn đang là sự thử nghiệm. theo Dũng quan sát thì hiện tại vẫn chưa thấy được 1 cái nào mà “the best” cho 1 công cụ nào cụ thể. Mọi người vẫn đang thử nghiệm khá là nhiều ạ.

Chị Ninh Phạm (Host):

Cảm ơn Dũng vì những chia sẻ của bạn.

Và Ninh cũng muốn lắng nghe thêm ý kiến chia sẻ từ phía Diễn giả Trung Nguyễn. Bạn có những kinh nghiệm thực tế nào không và bạn có thể chia sẻ với khán giả về những kinh nghiệm thực tế trong quá trình mà bạn tối ưu cũng như khai thác các công cụ GenAI? Và 1 yếu tố nữa là tính bảo mật của các công cụ AI như Dũng cũng đề cập đến, thì dưới góc nhìn của Trung thì bạn đánh giá như thế nào về tính bảo mật của các công cụ Generative AI?

Anh Trung Nguyễn:

Cảm ơn chị Ninh.

Thật ra ở vai trò của Scrum Master thì mình cũng không có sử dụng AI nhiều trong công việc coding như các bạn Engineer. Nhưng cũng may mắn là mình có quan sát được ở nhà TymeX thì mình có 1 đội ngũ AI in-house, thì mọi người có xây dựng cho công ty 1 cái Chatbot riêng, nó cũng sẽ hỗ trợ cho mọi người đỡ phần lo lắng về mặt bảo mật là code của mình có bị leak ra ngoài hay không, thì hoàn toàn là in control hết. Cái Chatbot đó bên nhà TymeX mình cũng lấy chữ  “Tyme” và đặt tên là “Tyme Me”  cũng nghe cute cute, dễ thương á. 

Trong công việc hàng ngày thì mình thấy các bạn Engineer cũng tận dụng rất là nhiều, vì là build in-house thì Tyme Me có được access vào tập các source code của công ty cũng như được bổ trợ bởi tập data bên ngoài để training cho nó. Mọi người cũng dùng nhiều để sử dụng cho các task như unit test, hỗ trợ viết nhanh hơn, hoặc đôi khi mình thắc mắc về 1 best practice nào đó cần được giải thích thì Tyme Me có thể cung cấp thông tin cho mình 1 cách hiệu quả. 

Ngoài công việc lập trình thì yếu tố về mặt nhu cầu giải trí, đôi khi mình stress quá, code 1 thời gian dài quá thì mình cũng cần 1 người nào đó tâm sự, thì Tyme Me cũng là nơi mình có thể tương tác, nói chuyện trên trời dưới đất với nó. Cũng là 1 cách để sau 1 khoảng thời gian mình quá stress và có thời gian giải trí thì mình quay lại công việc nó sẽ tốt hơn. Ở Tyme Me, thì tụi mình cũng truyền tay nhau 1 cái gọi là “300 câu prompt thiếu nhi cần thiết” hoặc là những cái vui vẻ có thể chat với Chatbot để giúp mọi người có năng lượng nhiều hơn, quay trở lại làm việc tốt hơn.

Chia sẻ thêm, ở bên TymeX của mình sử dụng 1 ecosystem của nhà Amazon rất là nhiều, cho nên tụi mình cũng tận dụng rất là tốt tool Amazon Q Developer – công cụ AI của nhà Amazon. Trước đây nó được đặt lên là Amazon CodeWhisperer nếu như mọi người có từng sử dụng. Vì nó là công cụ Enterprise nên tụi mình sử dụng cũng rất an tâm và nó cũng hỗ trợ rất nhiều trong khi mình tương tác với các services của nhà Amazon. 

Chị Ninh Phạm (Host):

Cảm ơn Trung với những chia sẻ rất là thú vị và rất là tuyệt vời khi biết TymeX có xây dựng riêng 1 công cụ AI được sử dụng nội bộ để đảm bảo về mặt bảo mật thông tin. 

Và Ninh xin được hỏi anh Tony Vũ. Vậy thì chiến lược nào khi sử dụng các công cụ Generative AI để cân đối giữa chi phí chúng ta phải bỏ ra cho công cụ này và hiệu quả chúng mang lại như thế nào? Xin mời Diễn giả Tony Vũ có thể chia sẻ thêm được không ạ.

Anh Tony Vũ (Hùng):

Dạ. Thực ra HRS là công ty làm về booking dành cho B2B, phục vụ rất nhiều khách hàng lớn trong Fortune 500 như Airbus, Google, Siemens, v.v và là tập đoàn của châu Âu nữa nên những vấn đề liên quan đến privacy và security khi dùng AI rất được quan tâm. Nên thực ra đối với HRS thì không được sử dụng mấy các công cụ AI public, mà chỉ có AI nào có bản dành cho Enterprise mới được sử dụng. Đơn giản mình có thể hiểu là bản Enterprise như 1 box của doanh nghiệp và thông tin sẽ nằm trong đó không bị leak ra ngoài, và không bị dùng để AI học. Vì AI cần rất nhiều data để học thì những data của doanh nghiệp sẽ không bị học cho những công cụ public.

Về phase phát triển sản phẩm của HRS bao gồm 3 phần. Đầu tiên là Discovery, thứ hai là Development, cuối cùng là Automation. Đối với giai đoạn Discovery thì team sẽ sử dụng ChatGPT hoặc Perplexity để tìm idea, rồi sau đó sẽ sử dụng 1 công cụ là Invideo AI để generate các idea đó thành video để đi pitching cho khách hàng. Phần này là public AI thôi vì nó chưa liên quan nhiều đến data.

Sau khi pitching được, trong quá trình Development thì cũng sử dụng Copilot bản Enterprise để build code nhanh hơn rồi cover unit test tốt hơn, code review tốt hơn. Nhưng mà phía sau thì HRS phải xử lý rất nhiều receipt hoặc hóa đơn đến từ các đối tác cho nên mình có sử dụng Azure AI Document Intelligence để build 1 công cụ nội bộ để AI giúp đọc các text trên hóa đơn và đưa lên hệ thống 1 cách tự động. Riêng đối với việc này thì mình cảm thấy chi phí có thể tiết kiệm được so với manual work là có thể lên tới 80%, cho nên đối với doanh nghiệp thì đây là 1 mức tối ưu khá là tốt hoặc rất là tốt. Đó là góc nhìn của bên mình đối với AI.

Có 1 điểm đặc biệt nữa khi muốn áp dụng AI là HRS là 1 công ty khá lâu đời, khoảng 50 năm, cho nên có rất nhiều người đã làm đây 20-30 năm rồi, cũng như có workspace trải dài khắp thế giới, các thể loại team cũng rất là đa dạng, cho nên mình không thể nào đưa 1 công cụ AI hoặc là 1 công cụ mới vào mà ép buộc tất cả mọi người cùng sử dụng được, vì sẽ xảy ra hiện tượng chống đối nên bên mình sẽ cố gắng lựa ra 1 model team – là build 1 team áp dụng thử, rồi sau đó là chứng minh sự hiệu quả, xong rồi khen thưởng và đưa team đó thành như “star” vậy đó.

Sau khi các team khác nhìn thấy những hiệu quả đó thì họ mới có mong muốn cũng được áp dụng. Thì khi họ mong muốn như vậy rồi, việc áp dụng cho các team khác sẽ bắt đầu ở môi trường rộng hơn dễ dàng hơn. Đó là cái chia sẻ của em trong việc áp dụng 1 cái thứ hoàn toàn mới với công ty có scope khá lớn như HRS hiện tại

Chị Ninh Phạm (Host):

Cảm ơn Diễn giả Tony Vũ với những chia sẻ rất là chi tiết. Xin cảm ơn các Diễn giả đã có phần chia sẻ rất là chi tiết và bổ ích trong chủ đề vừa rồi.

Phiên Thảo luận – Cách tổ chức Scrum Team để tối ưu năng suất

Chị Ninh Phạm (Host):

Thưa quý vị khán giả, trong Webinar lần trước thì có 1 nội dung đã được chia sẻ rất là sôi nổi, đó là chủ đề yếu tố về con người. Trong các dự án phát triển phần mềm, thì yếu tố con người luôn là yếu tố động lực và thúc đẩy cho cả quá trình, góp phần rất lớn trong việc gia tăng năng suất. Và với cách tổ chức vận hành đội ngũ, nó ảnh hưởng rất lớn tới hiệu quả trong các dự án phần mềm. 

Trong dự án phần mềm, thì yếu tố hạt nhân chính là các Scrum team. Với 1 Scrum team, làm sao cấu trúc Scrum team như thế nào để có thể hoạt động được hiệu quả, làm sao để năng lực Scrum team được đồng đều, và làm sao để các thành viên trong Scrum team có được động lực phát triển, mọi người có thể phát huy tối đa tiềm năng, năng lực của mình. Điều đó cần một tầm nhìn quản lý để làm sao có thể phát triển được hết các yếu tố nội tại trong tổ chức.

Đến đây, chúng ta cùng chuyển sang chủ để về cấu trúc của Scrum team. Với chủ đề này, Ninh rất muốn được lắng nghe những chia sẻ của các diễn giả dưới góc nhìn chuyên môn technical. cũng như góc nhìn của những người quản lý và vận hành team trực tiếp. Câu hỏi đầu tiên, Ninh muốn dành cho diễn giả Nguyễn Bá Dũng. Dũng có thể chia sẻ cho khán giả về việc đo lường năng lực team trong 1 Scrum team sẽ được diễn ra như thế nào được không?

Anh Nguyễn Bá Dũng:

Ở NFQ thì hầu hết các team sẽ sử dụng Scrum, và cũng follow theo mô hình Scrum cơ bản thôi. Tuy nhiên có 1 tình hình thực tế là Scrum nó là 1 framework và mỗi team thì sẽ thực hiện framework đó theo cách khác nhau. Mình vẫn có những follow giống như Scrum làm như là meeting, sprint planning, vẫn có những back-up requirements, sprint review, v.v. Tuy nhiên mỗi team thì sẽ có cách mà họ adapt khác nhau vì mỗi team có những culture được customized 1 xíu về việc đưa Scrum vào trong team của mình. 

Một trong những điểm rất quan trọng để có thể tối ưu được năng suất của Scrum team, mình luôn đặt ra Scrum team cần phải đạt được tiêu chí “Cross-functional”. Có nghĩa là tất cả mọi người trong Scrum team đó đều có thể làm được nhiều loại việc khác nhau, chứ không phải chỉ có 1 người luôn luôn làm mãi 1 công việc, mãi 1 đoạn code hoặc 1 module nào đó trong source code của mình.

Việc họ chỉ làm chuyên 1 mảng nào đó trong system thì sẽ gây ra 1 vấn đề mà mình cũng thường xuyên gặp phải, đó là khi mà mình đã plan cho 1 sprint đầy đủ rồi, nhưng bạn đó lại đột xuất nghỉ, có thể do bạn bận hoặc gia đình bạn có chuyện gì đó, chuyện này cũng khá thường xuyên xảy ra, thì nếu bạn ấy là người duy nhất có thể làm được ở trong mảng đó, thì coi như tiến độ của sprint sẽ bị chững ngay thời điểm đó và không có cách nào mình có thể vượt qua. Thậm chí có trường hợp tệ nhất là các bạn đó đang cầm key (sprint goal), tức là nếu các bạn ấy không làm thì chắc chắn sprint goal của mình sẽ fail. Thì đó là 1 tình huống rất tệ đối với bất kỳ Scrum team nào. 

Phương pháp làm sao để mình có thể đạt được Cross-functional thì Dũng hay gọi là “Responsibility Exchange”, có nghĩa là mình trao đổi trách nhiệm lẫn nhau trong team. Dũng sẽ luôn khuyến khích mọi người thường xuyên trao đổi vai trò với nhau. Mỗi người đương nhiên sẽ bắt đầu ở lĩnh vực, ở mảng riêng trong hệ thống, trong sản phẩm của mình, tuy nhiên sau khi 1 người đã nắm rõ công việc của mình, VD như 1 topic A hoàn toàn có thể giúp đỡ 1 bạn hoàn toàn mới đang nắm 1 topic B để có thể làm quen với topic A đó. Và họ có thể trao đổi task với nhau, có thể cùng planning và involve lẫn nhau vào trong các solution discussion để cùng đưa ra những giải pháp có thể align được với tất cả những người khác ở trong team.

Trong các buổi daily Dũng cũng khuyến khích mọi người challenge lẫn nhau, đặt câu hỏi để tìm hiểu xem người kia đang vướng ở chỗ nào, để mình hiểu hơn là mình có thể giúp được gì cho họ hay là không. Khi mà mỗi người có thể làm việc ở trên nhiều mảng khác nhau thì việc challenge này cũng có thể hoàn toàn thực hiện được. Khi mà mình đã đạt được Cross-functional rồi thì kể cả 1 người chỉ chuyên 1 mảng nhất định trong team vẫn hoàn toàn có thể hiểu được công việc của các bạn khác trong team., và khi cần như trong trường hợp lúc trước Dũng nói thì mình hoàn toàn có thể tạm thời thay thế được. Ít nhất mình vẫn có thể đảm bảo sprint goal của mình sẽ đạt được như đã đề ra.

Tuy nhiên việc mình trao đổi trách nhiệm này cũng vấp phải khó khăn là vì hầu hết các engineer đều có xu hướng là tránh phần mình làm không quen, cái này cũng là do thói quen của mình thôi, ai cũng thích chuyện mình đã quen thuộc rồi. Dũng nghĩ là ở các trường hợp mà mình có thể tạo cơ hội cho các bạn được làm nhiều thứ hơn, VD như Front-end và Back-end có thể trao đổi task với nhau vì các bạn có thể tò mò về vị trí còn lại làm những việc gì, bắt đầu từ những task nhỏ thôi, thì dần dần các bạn sẽ quen và bắt đầu trao đổi các task khó hơn.

Thậm chí Dũng cũng mở ra những cơ hội cho các bạn làm quen với những task của DevOps, kinh nghiệm Dũng thấy là các bạn Software Engineer rất có hứng thú với DevOps task vì nó là 1 thứ khá là mới mẻ và không được dạy trong trường đại học. Ở đại học thì các bạn được dạy về programming language, framework làm software, nhưng thường trong trường đại học sẽ không dạy về infrastructure hay ops, nên các bạn rất tò mò. Cũng như bây giờ các Cloud platform như Amazon web services hay Google Cloud platform thì bây giờ phát triển rất mạnh, thì các bạn cũng rất muốn tìm hiểu những thứ mới mẻ đó, cho nên khi Dũng thấy các cơ hội như vậy thì Dũng rất khuyến khích mọi người thử trao đổi những cái đó với nhau, và thực sự các leader cũng cần phải mềm mỏng chút xíu khi cho mọi người trao đổi với nhau trên tinh thần chia sẻ và giúp đỡ lẫn nhau để cùng đạt được mục đích chung. Hầu như lúc đó thì mọi người sẽ gỡ bỏ được tâm lý là chọn làm những gì đã quen với mình rồi. 

Đó là chia sẻ của em về Scrum team ạ.

Chị Ninh Phạm (Host):

Cảm ơn Dũng, những chia sẻ rất là thực tế. 

Thưa diễn giả Tony Vũ, ngày nay việc quản lý các dự án phần mềm đã thay đổi rất nhiều so với việc quản lý dự án truyền thống trước đây. Việc các dự án được tự động hóa quy trình (automate) rất là nhiều và đưa đến 1 việc đo lường năng suất trong team cũng cần sự hỗ trợ của các hệ thống tool. Với vái trò là 1 người quản lý delivery tức là quản lý quy trình dự án phần mềm, thì làm sao để chúng ta có thể tracking được những yếu tố và chỉ số về năng suất của team qua quy trình và qua các hệ thống tool, và từ đó làm sao để chúng ta tìm được những mắt xích, lỗ hổng đang ảnh hưởng trực tiếp đến yếu tố năng suất của team? 

Ở đây Ninh muốn đặt câu hỏi cho Tony là: Theo bạn, năng lực quản lý cần có trong 1 Scrum team là như thế nào? Ninh mời diễn giả Tony Vũ chia sẻ thêm với khán giả được không?

Anh Tony Vũ (Hùng):

Ngoài những phần mà Dũng chia sẻ thì em muốn nhấn mạnh lại thêm một chút nữa. Đó là đối với các Scrum team thì chúng ta cần chú ý về Team size. Thường thì mình có recommendation là dưới 10 người, mình suggest khoảng 7-8 người là hợp lý. Lúc đó nó sẽ đảm bảo được chất lượng communication trong team.

Ngoài ra có 1 điều cực kỳ quan trọng mà mọi người hay bỏ qua đó là Self-organize. Có nghĩa là tất cả các member nên có mindset tự làm, chứ không chờ đợi leader. Mình có nghe 1 câu khá hay: “Leader không phải người có trách nhiệm với công việc mà là có trách nhiệm với những người thực hiện công việc đó”, tức là những member của mình. Thì leader phải đảm bảo được tất cả các member của mình có đủ không gian, năng lực để thực hiện công việc, và những công việc đó các bạn cần tự đưa ra giải pháp, các bạn là người quyết định và có trách nhiệm với nó, thì mình là người leader thì cần tạo ra không gian bao quát cho các bạn hoạt động. Đó là cái cần phải chú ý hơn, chứ không phải như hồi xưa mình cố gắng push nhiều người vào team nhất có thể, xong rồi các bạn chờ đợi mình để đưa ra một vài quyết định nào đó, cuối cùng blocker là mình chứ không phải các bạn, trong khi các bạn hoàn toàn có đủ năng lực để thực hiện các việc đó. VD các bạn chưa đủ năng lực thì có thể cho các bạn học thêm.

Như đối với Cross-functional như Dũng có đề cập thì team mình hay có nói đùa với nhau là “CV oriented”. VD 1 bạn Back-end đề xuất bạn đó học thêm về DevOps, thì project/product mà mình đang làm sẽ được hoàn thành tốt hơn, mọi người cover giúp nhau tốt hơn, nhưng mà cuối cùng value lại thuộc về member đó. Bạn có thể input thêm 1 skill nữa vào trong CV của bạn. Rõ ràng mình là người push bạn học nhiều nhưng mà thực ra value thuộc về bạn, bạn là người được hưởng. Cho nên đó cũng có thể là động lực mà mình có thể hỗ trợ các bạn học thêm.

Nói thêm chút là ở HRS mình có cung cấp tài khoản Udemy Business để các bạn có thể học thêm các skill cần thiết.

Chị Ninh Phạm (Host):

Cảm ơn Hùng đã chia sẻ về 1 bí quyết để tạo động lực trong team cũng như là tạo động lực cho các bạn tự có mong muốn được phát triển hơn về năng lực và thể hiện tốt hơn tiềm năng sẵn có của mình.

Câu hỏi tiếp theo Ninh rất muốn lắng nghe ý kiến của bạn Trung Nguyễn. Dưới vai trò là người trực tiếp vận hành Scrum team, thì Trung có thể chia sẻ với khán giả với 1 Scrum Master, thế nào là 1 cấu trúc tốt nhất cho Scrum team để team có thể đạt được hiệu quả năng suất tốt nhất trong công việc?

Anh Trung Nguyễn:

Em nghĩ phần chia sẻ của Dũng và anh Hùng vừa cover câu hỏi của chị Ninh rồi, đó là Cross-functional team là 1 cấu trúc best trong việc tối ưu năng suất. Tuy nhiên trong TymeX của tụi em thì ngoài Cross-functional team thì tụi em có 2 mô hình nữa cũng sẽ giúp mình tùy biến trong nhu cầu sử dụng. 

Mô hình đầu tiên là Communal team. Đây là 1 team tập trung hầu hết tất cả các bạn có cùng 1 bộ skill set với nhau, thì mình sẽ có những giai đoạn trong dự án/product mà mình muốn đẩy nhanh tiến độ một cách nhanh nhất, mà mình chỉ cần 1 bộ skill set đó thôi. VD như ở giai đoạn khởi đầu của product, mình chỉ có nhu cầu phát triển sản phẩm của mình trên nền tảng mobile thôi, nhưng sau khi mình launch sản phẩm rồi và nhận thấy nhu cầu ở các nền tảng khác rất lớn, thì mình đã có sẵn requirements và nền tảng về back-end rồi, bây giờ mình chỉ cần build 1 channel, front-end để phục vụ thêm 1 đối tượng khách hàng khác thôi. Thì giai đoạn này mình chỉ cần các bạn có các skill set đó tập trung trong 1 team để cùng làm việc và build ra nhanh nhất 1 sản phẩm adapt theo nhu cầu business của mình. Đó sẽ là 1 cách để mình sử dụng Communal team.

Mô hình tiếp theo nữa hầu hết ở công ty nào cũng có nhưng mình không biết mọi người có gọi tên hay không. Nó là Platform team. Những team mà đối tượng khách hàng của các team chính là các featured team, thì những team đó sẽ sở hữu những công cụ, các sản phẩm build ra cho các team khác sử dụng, để mà hỗ trợ họ trong quá trình mình phát triển phần mềm. Mình lấy VD là ở TymeX, team tập hợp các bạn có skill set mạnh về DevOps, các bạn sẽ manage hết mọi thứ liên quan đến DevOps và hỗ trợ tất tần tật mọi thứ, issue, problems mà các team khác gặp trong quá trình mọi người phát triển phần mềm.

Chị Ninh Phạm (Host):

Cảm ơn Trung với những chia sẻ vô cùng chi tiết của em. 

Thưa quý vị và các bạn, qua phần thảo luận vừa rồi, chúng ta đã thấy được tầm quan trọng của việc chúng ta lựa chọn công nghệ, kiến trúc giải pháp, áp dụng tự động hóa quy trình, ứng dụng các công nghệ GenAI, và tầm quan trọng của việc vận hành, quản lý Scrum team như thế nào. 

Phiên Thảo luận – Công cụ đo lường, các chỉ số tối ưu năng suất

Chị Ninh Phạm (Host):

Khi một dự án đã được tự động hóa quy trình rồi, có 1 yếu tố nữa mà các nhà quản trị dự án sẽ rất quan tâm, đó là đo lường các chỉ số năng suất. Với những dự án đã được tự động hóa quy trình, thì việc đo lường các chỉ số này ngày càng trở nên quan trọng hơn. Nó giúp cho người quản lý dự án sẽ đo được năng suất trung bình của dự án như thế nào, để khi có sự biến động một cách đột ngột thì chúng ta có thể dễ dàng nhận ra và tìm được, tracking được các mắt xích, lỗ hổng mà đang trực tiếp ảnh hưởng đến năng suất của dự án.

Ninh muốn được hỏi diễn giả Tony Vũ. Dưới góc nhìn của bạn thì việc đo lường năng suất sẽ dựa trên các metrics và những công cụ như thế nào?

Anh Tony Vũ (Hùng):

Hiện tại HRS đang sử dụng Azure DevOps để quản lý những task và sprint, v.v. Trong công cụ này thì gần như có thể đo lường được những chỉ số cơ bản mà Scrum team mong muốn VD như story point, số lượng công việc có thể hoàn thành, tốc độ, v.v. Nhưng ngoài ra thì bên mình còn sử dụng thêm SonarQube để đo lường về quality của code. Tool này sẽ scan code đó để xem là có vấn đề về security hay không, có bạn nào hack code password hay không, có có vulnerability hay không. Ngoài ra sẽ có một số suggestion để giúp code đạt chất lượng tốt hơn. 

Bên HRS còn measure thêm 1 cái là First time – Pass way. Có nghĩa là khi 1 bạn Dev tạo 1 pool request, thì request đó ngay lập tức được pass qua QC ngay lần đầu tiên, tránh trường hợp task đó bị rework lại thì mục tiêu ở đây là để cho bạn Dev cần phải chú ý kĩ hơn, phải tự unit test, tự kiểm tra mọi thứ trước khi đưa qua QC, tránh trường hợp QC tốn quá nhiều thời gian test đi test lại. 

Còn 1 cái nữa là Circle time, tức là thời gian từ lúc bên business có idea discovery cho tới lúc idea đó được đưa lên production, có nghĩa là mình đo được hiệu quả của các team làm việc với nhau thông suốt như thế nào. Thì đó là 1 KPI khá là quan trọng, mình cứ cố gắng tối ưu thì mỗi 1 lần có idea sau 1 thời gian ngắn là mình có thể ước chừng được sau bao lâu sẽ ra được production. Đó là những cách mà HRS đang sử dụng để đo lường ạ.

Chị Ninh Phạm (Host):

Cảm ơn những chia sẻ của bạn Tony Vũ. 

Còn với Trung, với TymeX thì sao? Với những dự án đã được automate thì những chỉ số cốt lõi của TymeX sẽ là những gì Trung có thể chia sẻ thêm với khán giả được không?

Anh Trung Nguyễn:

Thật ra bên mảng technical thì em sẽ xin phép được nhường phần đó cho Dũng nói thì nó sẽ chuyên sâu hơn, em sẽ có những chỉ số riêng về mặt con người. Tụi em sẽ có các metric core để tracking, tụi em đặt ra là Flow Tyme. 

Về circle time giống như anh Tony vừa share thì TymeX cũng có track cái đó, track xem là 1item từ lúc có idea cho đến lúc nó hoàn thành là bao lâu. Ngoài ra tụi em có track thêm velocity xem thử trong 1 khoảng thời gian thì mình có bao nhiêu item đã được hoàn thành. Flow Block – mình sẽ track thử xem trong cùng 1 thời điểm thì team đó đang work trên bao nhiêu item cùng 1 thời điểm đó. 

Cuối cùng là Flow Distribution là 1 trong những yếu tố em nghĩ là em quan tâm nhiều nhất, đó là em sẽ xem trong 1 khoảng thời gian, trong 1 sprint thì team mình đang mất thời gian, đang spend effort để làm việc trên bao nhiêu loại issue. Ở đây thì tụi em sử dụng Jira để quản lý các công việc hàng ngày, chắc như mọi người cũng biết là trên Jira nó có rất nhiều những phân loại về User story, thì tụi em sẽ sử dụng 4 phân loại chính: feature (mang lại business value), technical dev (mang lại technical value nhiều hơn), bug, và tasks.

Nếu mà mình dựa trên Flow Distribution, mình tracking nó qua từng string thì em lấy VD như string A mình thấy mình đang spend effort trên 4 user story về mặt business, 1 user story về bug thôi mà qua đến string tiếp theo mà mình thấy mình đang chỉ làm dựa trên 2 user story về business nhưng có đến 3 user story về bug, thì vấn đề nằm ở đâu. Lúc này mình sẽ quay ra câu chuyện là mình tìm hiểu xem trong process của mình nó đang có vấn đề gì không, hay là các bạn đang có vấn đề gì thì mình sẽ cùng nhau ngồi lại và giải quyết với nhau. Đó là các metric quan trọng về mặt process mà em sẽ phải tracking.

Chị Ninh Phạm (Host):

Cảm ơn Trung với những chia sẻ vô cùng chi tiết và thực tiễn. 

Dũng ơi Dũng có thể add on thêm những chỉ số cốt lõi nào mà dưới góc nhìn của 1 người làm kỹ thuật được không?

Anh Nguyễn Bá Dũng:

Em cũng muốn chia sẻ thêm một chút xíu về mặt tracking con người. Về mặt team performance thì bên khách hàng của tụi em cũng có sử dụng OKRs để set goals cho doanh nghiệp. Khi mà xuống đến team của tụi em, thì tụi em sẽ phải chịu trách nhiệm cho 1 objective hoặc 1 key result nào đấy. Cái metric của nó sẽ tùy thuộc vào cái thời điểm đó doanh nghiệp họ muốn làm cái gì, thì nó sẽ thay đổi theo quý, vì bên khách hàng của tụi em sẽ thay đổi OKRs mỗi quý 1 lần.

Với 1 OKRs như thế thì team sẽ bắt đầu tạo những initiatives là những sáng kiến tạo mới để mang lại business value. Bên tụi em cũng sử dụng Jira và tụi em dùng epic để dùng cho mỗi initiative, mỗi initiative sẽ tương ứng với 1 epic ở trên Jira. Whatever team làm như thế nào thì thực sự ở phía của high-level manager họ sẽ không quan tâm lắm, họ chỉ quan tâm đến các chỉ số của key result mà thôi. Cái đó là metric cực kỳ quan trọng đối với team. Họ sẽ không micromanage nhưng họ sẽ nhìn vào kết quả mình làm được phản chiếu lên key result đấy, đó chính là cái mà phía trên họ đang quan tâm, vì họ chỉ quan tâm 1 điều duy nhất là mình tạo ra được impact gì đối với business của họ.

Một số VD cho OKRs mà team cũng đang làm, cũng hơi khó để Dũng có thể chia sẻ vì phần này sẽ hơi detail quá trong mỗi doanh nghiệp, tuy nhiên mỗi 1 objective hoặc key result đều phải cân đo đong đếm được, nó vẫn phải có 1 con số cụ thể rõ ràng, và nó có 1 hệ thống đã monitor cái đó rồi. Thì ở bên khách hàng họ cũng có 1 data team để làm data analytic. Số luôn luôn có sẵn rồi còn mình sẽ làm mọi cách để có thể đạt được con số như mình đã agree ngay từ lúc bắt đầu quarter planning. Cái đó là về phía team performance.

Về individual performance, thật ra cái này nó sẽ không quá được chú trọng như lúc nãy Dũng cũng có nói là họ quan tâm về business impact nhiều hơn. Thì nếu cho từng cá nhân thì mỗi 1 leader sẽ quản lý kết quả của từng thành viên thông qua những buổi sprint review meeting. Sau khi mình đã nhìn lại xem có những gì đã hoàn tất được và cái gì còn đang vướng lại, kết hợp với những Jira management report, VD như Time tracking hoặc User Workload report, cái đó mình có thể export thông qua Jira được, và mình có thể nhìn được cho từng engineer trong team luôn. 

Ngoài ra trong team của Dũng cũng có nhu cầu so sánh performance và potential của các bạn engineer với nhau, nhất là những bạn chung level với nhau. Bên em có sử dụng công cụ là 9-box Grid, đây là 1 framework khá là phổ biến trong HR để quản lý performance và nhìn thấy potential của mọi người, ai là người đã phát triển tốt trong 1 khoảng thời gian nhất định, ai là người đã sẵn sàng để được promotion. 

Nãy anh Trung có mention về mặt technical là làm sao để có thể đo lường được các chỉ số kỹ thuật cũng như có 1 câu hỏi liên quan tới việc này, thì may mắn là ở thời điểm hiện tại thì chúng ta cũng đã có những công cụ để đo lường thông qua Git repository. Hiện tại hầu hết các công ty chắc là đều sẽ sử dụng Git để source code hết, cho nên những công cụ Git Analytics bây giờ cũng được phát triển khá là tốt. Mọi người có thể tham khảo một số công cụ như Git Analytics AI, Metridev, v.v thì những key metric mà mọi người có thể nhìn vào là độ thường xuyên của việc commit (các bạn đó có thường xuyên commit hay không) và cái size của cái commit đó như thế nào, nó sẽ có những metric tương ứng và xuất report cho mình. 

Một số metric nữa như code review effectiveness tức là 1 pool request hoặc merch request được mở ra, thì bao lâu nó sẽ được review và được approved rồi đến bước tiếp theo, thì nó cũng sẽ được reflect luôn. 1 cái nữa cũng khá thú vị là issue resolution time, tức là từ lúc mà cái issue được mở ra cho đến lúc nó hoàn tất thì mọi người cũng hay gọi nó là “lead time”, việc đó cũng được hỗ trợ thông qua những công cụ analytics như trên. 

Tuy nhiên có 1 vấn đề là những công cụ này không miễn phí và nếu là bản miễn phí thì cũng khá bị limited về features, nên là không phải công ty nào cũng sử dụng. Thêm 1 lý do mà Dũng thấy ít công ty sử dụng vì nó hơi kiểu micromanage mọi người, vì lúc đó nó sẽ nhìn trực tiếp vào những gì mọi người đang làm việc luôn, và có những lúc nó sẽ chỉ ra tại sao 2-3 ngày rồi mà không commit, lúc đó nó sẽ “khoai” cho engineer vì task đó họ cần research hay code đâu đó sẽ hơi lâu chút xíu, mà report đó chỉ ra là họ đang không performing. Chính vì thế mà các công cụ đó cũng chưa thực sự phổ biến. Nó chỉ phổ biến trừ khi chúng ta cần làm audit thôi, tức là khi có 1 team đang under-performing, thì lúc đó mình sẽ đưa công cụ này vào và chỉ ra trong quá khứ chuyện gì đã diễn ra, vì cái đó sẽ rất khó để nhìn ra được, do những cái mình quan sát hoặc những report của Jira thì qua thời gian mình cũng sẽ quên đi, mình không còn nhớ rõ nữa, chỉ có Git Analytics này sẽ luôn có history và mình luôn nhìn thấy được.

Chị Ninh Phạm (Host):

Cảm ơn Dũng với những chia sẻ vô cùng chi tiết

Phiên Thảo luận – Trách nhiệm khi năng suất đi xuống

Chị Ninh Phạm (Host):

Trong quá trình phát triển phần mềm, thì sẽ có những giai đoạn mà năng suất của dự án sẽ đi xuống. Đây là điều mà có lẽ không ai mong muốn cả, nhưng mà chúng ta vẫn phải đối diện với những giai đoạn như vậy. Vậy thì trong những giai đoạn năng suất đi xuống, thì câu hỏi lúc đó sẽ đặt ra là: trách nhiệm thuộc về ai?

Ninh rất muốn nghe chia sẻ từ các diễn giả, khi năng suất của team đi xuống thì lúc này trách nhiệm sẽ thuộc về ai? Xin đặt câu hỏi này với bạn Tony Vũ, dưới vai trò là 1 Delivery Manager thì bạn có chia sẻ gì và quan điểm của bạn về vấn đề này như thế nào?

Anh Tony Vũ (Hùng):

Dạ, nói thẳng ra khi năng suất team đi xuống thì trách nhiệm thuộc về leader, đó là điều chắc chắn. Tại vì leader là đã được cung cấp đầy đủ các công cụ và nguồn lực để có thể planning rồi leading team, nhưng đến khi hiệu suất của team đi xuống thì chắc chắn đó là người phải đứng ra nhận trách nhiệm. 

Còn về cách xử lý như thế nào, thì mình đang có rất nhiều các công cụ đo lường. VD như hồi nãy Dũng có chia sẻ, thông qua các công cụ đó mình có thể biết được performance của bạn đó đang như thế nào. Theo như em thấy thì cơ bản mình cũng chỉ cần chú ý 2 con: 1 là con số, 2 là con người.

Đối với con số, các công cụ có thể show ra được rồi, mình cũng có thể tìm được botnet ở chỗ nào rồi, nhưng ngoài ra mọi người nên quan tâm thêm con người nữa, tức là về cảm xúc của các bạn trong team của mình. Nhiều khi bạn đó đang bị giảm performance vì bạn đó đang có chuyện gì đó buồn chẳng hạn, hay là đang bị bệnh gì đó chẳng hạn. Câu trả lời ngược lại cho leader là leader có biết việc đó hay không. Làm thế nào để biết thì ít nhất là phải có health-check thường xuyên đối với member trong team của mình.

Bên HRS em thấy đang có 1 framework khá là hay, tức là “Sweet and Sour”, tức là VD thứ 2 gặp nhau, mình sẽ chia sẻ xem điều gì làm bạn hạnh phúc, điều gì làm bạn vui và điều gì làm bạn không được ổn, không được thoải mái. Thông qua các chia sẻ như vậy, cả team có thể nắm bắt được, kể cả về mặt cảm xúc của member đó và có thể đưa ra các hỗ trợ cần thiết. Cho tới khi nào member đó có thể sẵn sàng thoải mái nói lên “Tôi cần hỗ trợ”, thì lúc đó tức là bạn member đó đã cảm thấy hoàn toàn an tâm ở trong môi trường team của mình. Đó là chia sẻ của em trong việc trách nhiệm và tìm cách tạo động lực cho member.

Chị Ninh Phạm (Host):

Cảm ơn Hùng với những chia sẻ vô cùng thú vị. 

Vậy thì ở trong 1 Scrum team thì làm thế nào để truyền động lực cho team và tìm hướng khắc phục khi mà có issue, vấn đề xảy ra? Ninh muốn dành câu hỏi này cho Trung – 1 Scrum Master, Trung có thể chia sẻ với các bạn khán giả được không?

Anh Trung Nguyễn:

Thật ra theo em phương pháp truyền động lực hiệu quả nhất chỉ là đối thoại thôi.

Đầu tiên, mình phải đảm bảo là mình build được trust (lòng tin) giữa các thành viên. Nếu giữa mọi người trong team mà không tin tưởng nhau thì không có giải pháp nào nó hoạt động cả. 

Cái thứ hai là ở vai trò là 1 người Scrum master, 1 người leader thì mình phải bảo đảm là mình có được sự thấu hiểu (Empathy) với các bạn. Mình phải đặt mình vào trong hoàn cảnh, ngữ cảnh của các bạn thì từ đó mình mới đồng hành cùng các bạn để giải quyết vấn đề tốt hơn. 

Em nghĩ có rất nhiều practice mà Scrum đã đưa ra cho mình rồi và 1 trong những cái practice đó là Retrospective. Theo kinh nghiệm quan sát của em thì có nhiều công ty, nhiều team thường hay bỏ qua event này, mà em đánh giá event này rất quan trọng. Vì Retrospective là nơi mà mình tạo ra 1 không gian an toàn cho các bạn để các bạn speak up, các bạn nói hết các thứ mà các bạn nghĩ là nó không tốt, chúng ta cần cải thiện. Nếu mà mình tổ chức và mình làm tốt Retrospective cho team, thì em nghĩ issue hay problem nó sẽ được phát hiện sớm và sẽ không gây hậu quả nghiêm trọng nào. 

Chị Ninh Phạm (Host):

Rất là tuyệt vời. Rất cảm ơn những chia sẻ của Trung

Q&A

Câu hỏi 1

Lấy ví dụ một product vừa starts, quy mô trung bình, Microservices, khi tuyển mới một team developement. Xin hỏi diễn giả ưu tiên bao nhiêu % số lượng con người cho tầng cấp bậc junior, experience (5 năm kinh nghiệm), senior, tech lead?

Anh Nguyễn Bá Dũng:

Như đã đề cập ở phần đầu của buổi Webinar, Microservices sẽ không phù hợp với những team nhỏ nên nếu chúng ta đã xác định đi với Microservices thì ngay từ ban đầu chúng ta phải xác định cần có 1 team có quy mô trung bình ít nhất là 20 người, thậm chí là 30 người. Và sẽ chia thành các sub-teams khác nhau. Số lượng sub-team sẽ tùy thuộc vào số lượng services mà mình thiết kế, mình muốn xây dựng như thế nào. Một con số mình có thể cân nhắc ngay từ ban đầu là có thể 3-4 teams, và sau đó chúng ta sẽ scale dần lên, tùy theo nhu cầu của doanh nghiệp.

Về cấu trúc của mỗi team, thì mỗi team như anh Hùng có nói là nên dao động khoảng từ 7 thành viên, thì Dũng cũng đề xuất là nên dao động từ 5-7 thành viên để đảm bảo team có thể bắt đầu trơn tru được. Trong cấu trúc của team cần ít nhất có 1 bạn team leader, người đó có thể ở level lead hoặc senior cũng được, tùy vào sự sẵn có nhân sự của mình, cũng như là trách nhiệm team sẽ gánh vác. VD team đó không cần đảm nhiệm trách nhiệm quá lớn thì có thể để 1 bạn Senior lead team cũng được. 70-80% nhân sự nên là Software Engineer, từ Mid-level trở lên. 

Vì sao chúng ta không nên Junior cho sản phẩm này? Vì chúng ta đàn build 1 sản phẩm hoàn toàn mới, mình sẽ cần các Engineer mà có khả năng deal được với những yêu cầu còn hơi mơ hồ và không rõ ràng, vì thường những product mới sẽ có những chuyện như vậy dễ xảy ra, vì chính những người PO hay BA cũng đang chưa thực sự hiểu doanh nghiệp mình sẽ vận hành như thế nào. Bên cạnh đó thì những yêu cầu đó cũng sẽ rất dễ bị thay đổi nữa.

10-20% còn lại thì bạn hoàn toàn tuyển các vị trí hỗ trợ như BA, QC hoặc DevOps engineer, tùy vào nhu cầu của team.

Câu hỏi 2: 

Các Phương pháp/công cụ đo lường hiệu suất dễ triển khai và chi phí hợp lý?

Anh Tony Vũ (Hùng):

Thực ra hiện tại bên ngoài kia mình đang có rất nhiều công cụ rồi, chắc là các bạn tự so sánh về chi phí và lựa chọn thôi. VD mình có Jira, Asana, Monday.com, v.v ; hoặc free thì có Cello, v.v. Thì hầu hết các công cụ này có thể giúp mình đo lường được các thông số cơ bản như velocity, burndown, burnup, circle time, lead time, thậm chí cả critical path. Thì theo mình ở đây các bạn nên cân nhắc chi phí phù hợp với bên bạn thôi, muốn free thì mình cũng có free, muốn có chi phí để mọi thứ tốt hơn thì cũng có. VD như mình đánh giá khá cao Jira.

Câu hỏi 3

Giải pháp cho vấn đề:

  • Hiện trạng đang bị dồn việc ở testing
  • Thì có cách nào để giải quyết bài toán thường xuyên team k đạt dc tiến độ các task trong sprint
  • Các yêu cầu đầu vào khó và BA k phân tích được hết yêu cầu nên hay thay đổi hoặc bổ sung

Anh Trung Nguyễn:

Cho phần đầu tiên, vấn đề này cũng là 1 vấn đề khá phổ biến ở TymeX. Ở TymeX thì tụi em cũng sẽ có 1 QA trong Scrum team và bạn QA sẽ phải cân gần như là 5-6 bạn engineer. Thì có 1 giải pháp tụi em cũng đang thử nghiệm thôi, là share testing theo mindset Shift Left, tức là mình sẽ đẩy cái quá trình testing đó tới sớm hơn thay vì nó chỉ xảy ra trong giai đoạn mà các bạn nhận được các sản phẩm từ các bạn Dev. 

Có 1 practice rất hay đó là QA lúc này sẽ đóng vai trò là người cố gắng hỗ trợ nhiều nhất để đảm bảo về mặt chất lượng sản phẩm, sẽ cố gắng provide được mindset về mặt test case, còn phần công việc, các skill về test case đó mình có thể chia sẻ với nhau để làm để đảm bảo phần việc mà bị dồn ứ đọng ở 1 bạn QA đó sẽ được san sẻ ra các role khác. Thì đây là 1 việc mà bên TymeX bọn em đang thử nghiệm và practice rất nhiều. Cũng hứa hẹn là sẽ giải quyết được 1 phần nào đó cái vấn đề này.

Phần tiếp theo, cũng không có 1 công thức nào cả. Trong buổi sprint review, mình sẽ nhận thấy được 1 vấn đề là thường xuyên mọi người không đạt được sprint goal như mọi người đã commit ở trong planning, thì chắc chắn đâu đó mình sẽ phải ngồi lại, đừng để việc đó xảy ra quá nhiều lần thì lần thứ 2 mình đã phải ngồi lại với nhau trong cùng 1 team trong buổi Retrospective để mình cùng nhau tìm hiểu vấn đề là gì. Có thể vấn đề về việc mình over-commit trong buổi planning hay không, hay là bất kỳ vấn đề phát sinh về kiến thức hay trong suốt quá trình mình làm có khó khăn nào đó, thì mình có thể transparent nó ra 1 cách tốt nhất và đi tìm các giải pháp phù hợp cho từng vấn đề cụ thể.

Câu hỏi 4

Nếu một công ty có rất nhiều project nhưng resource không đủ nên phải switch qua lại cho các project và phải chạy song song thì có cách nào quản lý tốt hơn không?

Anh Nguyễn Bá Dũng:

Thứ nhất tình huống này là 1 tình huống khá là khó và nó thực sự không có nên kéo dài. Về mặt doanh nghiệp, phải làm sao có thể đốc thúc để giải quyết được vấn đề này sớm, vì khi đã thiếu resource rồi thì nó sẽ có nhiều hơn 1 vấn đề này chứ không phải chỉ đơn giản là chúng ta không deliver được. Khi thiếu resource thì những người hiện có đang phải gồng gánh 1 khối lượng công việc có thể sẽ khá lớn. Đứng dưới góc độ của business nên cân nhắc việc giảm workload của các bạn lại, thì cái này mình có 1 phương pháp để làm được, đó là quản lý tập trung tất cả các project trên cùng 1 nền tảng thôi, và chúng ta sẽ có phương pháp để prioritize lại công việc của tất cả các dự án đó luôn. 

Mình sẽ prioritize trên tất cả các task của tất cả các dự án chứ không phải chỉ prioritize các task trong 1 dự án mà thôi. Như vậy thì lúc đó mình sẽ có thể cắt bớt được những công việc mà thực sự có thể nó không quá cần thiết ở thời điểm này. Ở thời điểm khó khăn như vậy thì mình nên chỉ tập trung vào những công việc nào tạo được nhiều business value nhất và critical nhất đối với doanh nghiệp của mình ở thời điểm hiện tại thôi, vì việc mà mình chạy nhiều project song song với 1 áp lực lớn thì mình có thể chạy ngày 1 ngày 2 hoặc 1-2 tuần, thậm chí là 1 tháng, nhưng mà nếu chỉ cần qua tháng thứ 2 hoặc 3 thì thực sự rằng là chúng ta đang phải đối diện với 1 situation cực kỳ khó vì mọi người sẽ bị overload và hầu hết mọi người sẽ bị burn-out. Vì vậy đứng về phía của công ty thì nên có sự cân nhắc lại về priority, giảm workload lại làm sao cho hợp lý do mình cũng đang gói gọn nguồn lực của mình. 

Thực sự vấn đề này cũng khá là dễ hiểu trong tình hình kinh tế suy thoái hiện nay, các công ty cũng đang dần cắt giảm về mặt nhân sự. Tuy nhiên cũng phải thấu hiểu cho các anh em một chút xíu. Người thì ít đi nhưng task thì vẫn thế thì sẽ rất là khó để có thể duy trì tình trạng đấy.

Câu hỏi 5

Project hay bị scope creep (đã được approve từ PO), có nên sử dụng Burn Up Chart thay vì Burn Down Chart để thể hiện khôi lượng công việc bị add thêm không?

Anh Tony Vũ (Hùng):

Câu trả lời nhanh đó là có. Khi mình có một khối lượng công việc đã được định nghĩa trước ngay từ đầu sprint thì mình sẽ sử dụng Burn Down, nhưng khi công việc nó lên thì mình sẽ sử dụng Burn Up. Ngược lại mình cũng có câu hỏi ngược lại với bạn là; Trong Scrum thì mình cần phải protect team trước khi bắt đầu 1 sprint, thì câu hỏi được đặt ra ở đây là bạn PO có phải của Scrum team hay không, và bạn đó có tìm các protect Dev team hay không? Thì mình nên thay đổi từ việc đó. 

Thực ra 1-2 sprint bị việc này thì cũng không đến nỗi, nhưng nếu nó xảy ra quá thường xuyên thì nó hoàn toàn bị sai Scrum rồi, thì mình nên xem xét lại quy trình thống nhất công việc, priority công việc, thậm chí mình có thể rút ngắn sprint đấy lại chẳng hạn để đảm bảo priority hoặc khối lượng công việc nó diễn ra trong 1 thời gian ngắn (1-2 tuần) rồi sau đó lại thay đổi priority từ bên business thì nó sẽ dễ hơn đối với Dev team. Nhưng 1 khi đã bắt đầu chạ thì không nên thay đổi. Đó là ý kiến của mình.

Live Q&A

Câu hỏi 1

Có 1 team cross functional là 1 mục tiêu khi chạy Scrum. Tuy nhiên thường thì mình không có team như thế khi mình nhận transform 1 team qua Scrum. Vd phần test, thường thì QA nhận rất nhiều Story từ developer và workload của họ sẽ ít những ngày đầu, các ngày cuối Sprint rất nhiều. Hoặc có khi chỉ 1 bộ phận các bạn có task trong Sprint (e.g: BE), còn các bạn khác có rất ít task (e.g:FE, DB). Các bạn theo dõi và đảm bảo member full workload như thế nào?

Anh Nguyễn Bá Dũng:

Theo như em hiểu là transfer từ 1 team không sử dụng Scrum sang sử dụng Scrum thì có phần khó khăn là về phần test do bạn QA, thì hồi nãy anh Trung có mention về chuyện cuối sprint bạn QA mới có việc làm mà đầu sprint thì không có, thì vấn đề này cũng là situation sẽ hơi khó ở chỗ nếu bạn QA đó không có willing để take task của các bạn Back-end hoặc Front-end thì 1 trong những solution cho bạn đó là có thể apply như bên TymeX, là mình start cho QA càng sớm càng tốt. 

Còn về phía Back-end và Front-end thì thật ra em vẫn luôn recommend các bạn engineer có thể exchange task với nhau, không chỉ nên cố gắng stick với Front-end hay Back-end vì như vậy các bạn Front-end sẽ bắt buộc phải đợi các bạn Back-end làm xong thì các bạn Front-end mới làm được.

Câu hỏi 2

Cho mình hỏi, mình có 1 team IT In-house chuyên custom trên 1 nền tảng hệ thống ERP sẵn có, nên team size BA/Dev ko quá lớn tầm 7 bạn. Nhờ các diễn giả chia sẻ phương pháp/công cụ để đo lường hiệu quả và hiệu suất công việc. Hiện mình đang đo lường căn cứ trên thời gian hoàn thành task có đúng deadline so với kế hoạch (các bạn tự đề ra) và số lượng bug khi test và sau khi launching.

Anh Tony Vũ (Hùng):

Thực ra bạn đang đo lường cũng khá là đúng rồi, nhưng mà chỉ thêm 1 điểm nữa thôi là mình nên tìm cách đo lường theo story point nữa. Tại vì với story point thì mình sẽ có thể đo lường được việc phát triển của bạn đó, vì story point hiện tại mình đang đo lường theo mức độ khó của công việc đó, thì VD như khi cả team xác định độ khó là 5 điểm, thì bạn đó ở mức Junior mà tốn 5 ngày để thực hiện được 1 task 5 điểm, thì sau này cũng 1 task 5 điểm như vậy nhưng bạn chỉ tốn 3 ngày để thực hiện thì điều đó có nghĩa là performance của bạn đã tăng lên, level của bạn tăng lên. Thì ngoài việc đo lường thời gian, mình nên apply thêm story point theo độ khó của công việc là mình có thể nhìn thấy sự tiến bộ của các bạn đó. Còn bug hay sau khi launching thì nó quá hợp lý rồi.

Câu hỏi 3

Scale agile khi mình có nhiều scrum team, thì việc quản lý như thế nào để các team cùng phát triển, công việc align với nhau ạ?

Anh Trung Nguyễn:

Hiện tại ở TymeX, tụi em cũng đang hoạt động theo mô hình Scale Agile này. Có rất nhiều Scrum team cùng chạy song song và cùng contribute vào 1 sản phẩm. Tụi em sẽ có 1 practice là tổ chức thường xuyên các buổi Scrum-on-Scrum, là nơi các bạn đại diện đến từ các Scrum team sẽ ngồi lại với nhau để mình chia sẻ các thông tin trong Scrum team của mình xem nó có align, nó có cùng nhau hoạt động theo cái roadmap đã được mọi người agree trước khi bắt đầu product hay không. 

Cũng có các hoạt động tương tự như vậy để hỗ trợ các bạn giải quyết các blocker mà các bạn gặp phải mà mình có demand lẫn nhau trong suốt quá trình làm việc. Thì em nghĩ đó là 1 cách để mình có thể áp dụng. Và tất nhiên trong quá trình mà mình làm việc, mình sẽ cố gắng phân tích công việc, mình đảm bảo làm sao cho cái công việc của 1 Scrum team ít bị phụ thuộc vào các Scrum team khác nhiều nhất có thể, chứ không phải hoàn toàn không phụ thuộc. Em nghĩ đó là những điều mình có thể làm để phát triển tốt hơn hoạt động giữa các Scrum team.

Kết thúc.

Xem bản Full Recording tại đây

Bạn có thể truy cập bản Transcript và Recording của Webinar #1 và Webinar #2 tại: