Vai trò của Business Analysts trong mô hình SCRUM là gì, tại sao QA lại là ứng viên tốt nhất cho vị trí này?

I, Business Analysts(BA) là gì? vai trò của BA trong SCRUM là gì?

Bussiness Analysts là chuyên viên phân tích nghiệp vụ, gọi tắt là BA. Đảm nhiệm vai trò là người “bắc cầu” cho các dự án, nên thử thách lớn nhất của BA chính là hiểu rõ được yêu cầu của khách hàng và đảm bảo sao cho quá trình vận chuyển thông tin đó đến với bộ phận phát triển được diễn ra suôn sẻ.

Có rất nhiều trường hợp khách hàng là những người không có am hiểu về công nghệ thông tin, thì lúc này BA sẽ vừa là người tiếp nhận vừa là nhà tư vấn, đôi khi có thể đưa ra quyết định giúp khách hàng. Vì thế, khả năng giao tiếp và niềm đam mê công việc công với tư duy logic, cùng khả năng nhìn nhận và suy luận vấn đề tốt chính là những từ ngữ để miêu tả một BA chuyên nghiệp.

BA đóng một vai trò rất quan trọng trong SCRUM. Hãy cùng tìm hiểu nhé!

Trách nhiệm của một BA

Một số vai trò và trách nhiệm của một BA cần phải được tuần thủ như:

• Trau chuốt cẩn thận cho Product Backlog(bản danh sách các tính năng mong muốn của sản phẩm) dựa vào độ ưu tiên của nó được cung cấp bởi Product Owner.
• Phân tích yêu cầu của khách hàng và tìm ra giải pháp để giải quyết chúng.
• Tạo các bản tài liệu đặc tả(requirement) mô tả chi tiết các chức năng của phần mềm theo hướng đi của người dùng với các tiêu chí phù hợp.
• Nếu trong trường hợp tài liệu đã được Product Owner tạo, thì hãy xem xét lại chúng để đảm bảo rằng mọi yêu cầu của hệ thống sản phẩm, và chắc chắn rằng tiêu chí của sản phẩm đáp ứng lại yêu cầu của người dùng sản phẩm đó.
• Làm việc với Product Owner và các bên liên quan để hiểu rõ phạm vi của sản phẩm, đề xuất các thay đổi, cải tiến nhằm nâng cao chất lượng sản phẩm.
• Chuẩn bị các tài liệu như Requirement, UI, Function flow, Design folow... lúc cần thiết.

Ngoài ra, chuyên viên phân tích nghiệp vụ(BA) là người quan trọng trong các buổi họp để thảo luận, phân tích các vấn đề tồn đọng trong giai đoạn nước rút. BA sẽ là người hướng dẫn nhóm hiểu rõ các yêu cầu của sản phẩm, thậm chí đôi khi có thể có quyền chấp thuận việc thực hiện các chức năng.

BA phải luôn luôn tiếp tục tìm hiểu về các xu hướng công nghệ mới, tiếp tục đổi mới và luôn cập nhật về các nghiệp vụ của các sản phẩm đã được tạo ra.

Business Analysts as a Product Owner

Tùy vào khách hàng và công ty, điều này có thể xảy ra ở một số công ty: Một BA có thể được xem như là một Product Owner. Trong trường hợp này, BA sẽ là người đứng ra trả lời cho mọi câu hỏi về sản phẩm. Một BA được coi như là một "người thương thuyết", đứng ra hòa giải giữa team phát triển sản phẩm và các bên liên quan.

BA phải nắm chắc được yêu cầu nghiệp vụ của sản phẩm, những suy nghĩ của khách hàng, đặt ra mục tiêu nên làm gì, và làm như thế nào để sản phẩm có thể tốt hơn. Sau đó dựa vào những yêu cầu đó, BA sẽ tạo ra các tài liệu mô tả chi tiết các luồng xử lý của sản phẩm. Sẽ là người đứng ra trả lời thắc mắc cho mọi người về nó.

Điều quan trọng ở đây khi một BA trong vai trò một Product Owner là không khuyến khích một BA có múi giờ khác với các thành viên của dự án.

Nếu một BA có múi giờ khác với mọi người, thì mỗi lần cần thiết không thể gặp mặt trực tiếp, mà cách duy nhất để liên lạc sẽ là qua email hoặc các cuộc gọi. Do đó điều này có thể dẫn việc thông tin sai lệch vào các thời điểm. Và để xác minh một việc gì đó thì sẽ gặp rất nhiều rắc rối.

Có một BA với tư cách là một Product Owner sẽ là một lợi thế, bởi vì các BA hiểu rất rõ về sản phẩm, độ ưu tiên các phần, phạm vi của nó nên rất dễ để có thể thương lượng.

Business Analysts as a Team Member

Một sự lựa chọn khác đó là một BA sẽ đóng vai trò như là một thành viên của team, bởi vì không phải lúc nào vị trí Product Owner trong một dự án cũng có sẵn. Khi một BA là một thành viên trong team, thì sẽ giúp được mọi người trong các buổi Backlog Grooming(hay Backlog Refinement Meeting: Buổi họp giúp Product Owner chọn ra các Product Backlog sẽ được thực hiện trong buổi họp Kế hoạch Sprint tiếp theo (Sprint Planning Meeting)).

Có một BA là một thành viên trong team sẽ có rất nhiều thuận lợi, bởi vì thành viên trong team kĩ thuật(technical team) sẽ dễ dàng và thoải mái hơn trong việc giao tiếp hoặc thảo luận với BA. Cùng với đó, BA sẽ làm việc chặt chẽ với team QA nên sẽ rõ ràng hơn trong những việc như là: phân tích các trường hợp khả thi, bao phủ những trường hợp xử lý của người dùng, những requirement không được quy định rõ ràng, phạm vi ảnh hưởng của chức năng..v.v.

Đôi khi những tiêu chuẩn tài liệu, requirement không rõ ràng hoặc mơ hồ thì với tư cách là một thành viên trong team - BA sẽ viết ra thành tài liệu mô tả, giải thích rõ ràng mọi nghiệp vụ của sản phẩm.

Trong các dự án lớn, nơi các module được chia cho nhiều team, thì việc có một BA cho nhiều nhóm cũng là một lợi thế. Nếu một BA làm việc giữa nhiều team, anh/cô ấy có thể sẽ biết về: độ tương tác giữa các module, các tính năng mới hoặc cập nhật thì sẽ ảnh hưởng tới những module nào...

Tầm quan trọng và vai trò nhiệm vụ của một Bussiness Analysts trong SCRUM team.

Vai trò của một chuyên viên phân tích nghiệp vụ(BA) trong SCRUM là rất quan trọng trong sự thành công của một dự án. Sự tham gia của họ được bắt đầu ngay khi hiểu được nhu cầu của khách hàng đối với Demo Sprint. Đó là điểm liên lạc đầu tiên cho nhóm kỹ thuật để làm rõ. Chúng thậm chí còn quan trọng hơn giai đoạn đầu của một dự án mới và những dự án có quy mô lớn.

Product Owner không phải lúc nào cũng là một người có thể truyền đạt tốt bằng văn bản, đôi khi họ có các nền tảng là chuyên về kỹ thuật. Nên lúc đó nó trở thành trách nhiệm của BA để viết nên: những User story, những điều kiện chấp thuận của dự án, mô tả chi tiết nghiệp vụ của từng module, wireframe...

Bạn có thể tưởng tượng điều gì sẽ xảy ra nếu không có BA hoặc Product Owner tạo nên user story, ví dụ: "Là một khách hàng, tôi muốn thực hiện tất cả các hoạt động ngân hàng cho tài khoản của mình" với các tiêu chí như:

• Khách hàng có thể đăng nhập
• Khách hàng có thể thực hiện các giao dịch trong tài khoản của mình
• Khách hàng có thể tải về các hoạt động giao dịch trong lịch sử.v.v.

Theo ý kiến của mình, tôi có thể chia user story này thành 34 user story khác nhau. Mọi thứ sẽ trở nên tồi tệ hơn đối với team kỹ thuật nếu như các sơ đồ diagram và giao diện UI của sản phẩm không được tạo. Điều này dẫn đến một thất bại trong sprint, dẫn tới một dự án thất bại. Trừ khi Product Owner đã được đào tạo về BA, nếu không sẽ phải có một người với vai trò BA ở trong nhóm.

II, Tại sao QA lại phù hợp nhất cho công việc này?

QA là người xác minh các giải pháp cho một vấn đề hoặc một yêu cầu bằng cách kiểm tra nó. Do đó BA/Product Owner/các bên liên quan rất háo hức muốn biết phản hồi của đội ngũ QA. Sự tham gia của một BA trong việc kiểm thử ít hơn so với những gì nó đang trong quá trình phát triển.

BA làm việc chặt chẽ với QA trong việc xem xét các trường hợp kiểm thử, các trường hợp bao phủ của testcase - cung cấp một cái nhìn tổng quan, sâu sắc về dòng chảy của sản phẩm. Do đó những kiến thức được chia sẻ từ BA làm cho họ(QA) hiểu các chức năng của sản phẩm, nghiệp vụ, nhu cầu của khách hàng của sản phẩm và mọi thứ.

QA luôn kiểm thử dựa vào quan điểm của một người dùng cuối, do đó QA sẽ giúp khách hàng cải thiện sản phẩm nhiều hơn(so với một developer). Những developer tạo ra và phát triển sản phẩm dựa vào những tiêu chí chấp nhận đã đưa ra, nhưng không phải lúc nào họ cũng nghĩ một cách khách quan khách hàng sẽ có những trải nghiệm như thế nào với sản phẩm.

Trong quá trình phát triển, việc thực hiện sản phẩm, các flow, quy tắc được xác định rõ ràng nhưng việc thực hiện kiểm thử thì lại hoàn toàn dựa vào tư duy logic, khả năng suy nghĩ, trải nghiệm từ quan điểm của người dùng cuối.

Một QA có thể tham gia vào vị trí của một Bussiness Analysts trong SCRUM vì có rất nhiều cơ hội được thể hiện bởi tính chất công việc hằng ngày của mình.

Là một QA, thật dễ dàng để bạn có những vai trò của một BA như:

• Học, tìm hiểu các tài liệu đặc tả(requirements) một cách kỹ càng và chuyên sâu và chỉ ra những lỗ hổng, điểm cần giải quyết trong các buổi họp hàng ngày. Cố gắng tìm kiếm những giải pháp tốt hơn và thảo luận với team và BA.
• Hãy chú ý đến Product Owner, đặt câu hỏi và chia sẻ những phát hiện của bạn. Điều này sẽ làm tăng sự tin tưởng của PO đối với bạn, nó sẽ thể hiện được sự quan tâm của bạn tới sản phẩm như thế nào.
• Phải cân bằng được bản thân giữa BA và developer team, bạn nên là điểm liên hệ cho developer trong trường hợp cần làm rõ vấn đề gì đó về sản phẩm.
• Thiết lập quy trình kiểm thử cho riêng mình, tiếp tục cải tiến, thay đổi nó để giúp đỡ trong Sprint bàn giao sản phẩm.
• Trong trường hợp những sản phẩm có giao diện người dùng ưa thích, hãy tìm hiểu các xu hướng mới, hot và đưa ra các đề xuất cải tiến.
• Nắm rõ hoàn toàn sản phẩm từ trong ra ngoài. Xây dựng một kiến thức vững chắc về các bên liên quan của bạn, những mong đợi của họ và chia sẻ kinh nghiệm của bạn với họ.

Điều này có nghĩa rằng để có được vị trí BA, bạn cần phải nâng cao kỹ năng của mình. Có rất nhiều tài liệu tham khảo trên Internet bạn có thể nghiên cứu, hoặc cũng có thể theo học những khóa học nghiệp vụ của BA từ cơ bản tới nâng cao tại các trung tâm đào tạo.

Bài viết đã được dịch và bổ sung một số thêm một số khái niệm: https://www.softwaretestinghelp.com/role-of-business-analysts-in-scrum/