Vai trò của BA trong dự án SCRUM và lý do tại sao QA lại là ứng viên tốt nhất cho vị trí này.

Vai trò nổi bật của các nhân viên phân tích nghiệp vụ (BA) trong SCRUM:

Một nhà phân tích nghiệp vụ, người được gọi tắt là BA, đóng một vai trò quan trọng và có tác động mạnh mẽ trong SCRUM.

BA là người liên kết giữa PO/ khách hàng và nhóm CNTT kỹ thuật. Mặc dù mọi người đã tìm hiểu và biết qua về nghề BA, nhưng trong bài này bằng một cách nào đó hướng dẫn và sẽ giải thích cho bạn tầm quan trọng của BA trong SCRUM.

Vai trò của BA

Một số vai trò của các nhà phân tích nghiệp vụ (BA) trong Scrum và trách nhiệm mà một BA nên tuân thủ.

Một vài vai trò và trách nhiệm được lựa chọn trong số đó được đề cập dưới đây.

• Chuẩn bị product backlog dựa trên mức độ ưu tiên được cung cấp bởi người chủ sở hữu sản phẩm (product owner).
• Phân tích nhu 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 yêu cầu theo dạng user stories với các tiêu chí chấp nhận phù hợp.
• Nếu trong trường hợp các user stories đã được tạo ra bởi chủ sở hữu sản phẩm (PO) (với tiêu chí chấp nhận), thì hãy xem xét để đảm bảo rằng mọi quy tắc nghiệp vụ doanh nghiệp đều được đề cập và các tiêu chí chấp nhận này đáp ứng được chức năng của các user stories.
• Làm việc với PO và các bên liên quan để hiểu phạm vi, đề xuất cải thiện các yêu cầu, v.v.
• Chuẩn bị các tài liệu như wireframes, design flow, giao diện người dùng, vv, khi được yêu cầu. Ngoài ra, một nhà phân tích kinh doanh là một người tham gia quan trọng trong các buổi thảo luận góp ý (brainstoming) khi họp nhóm để thảo luận về việc tồn đọng của sprint sắp tới. BA hướng dẫn nhóm, giúp họ hiểu các yêu cầu và thậm chí đôi khi phải xác nhận việc thực hiện.

BA cũng làm việc chặt chẽ với QA như phân tích phạm vi kiểm thử, chuyển đổi các use cases trong thế giới thực sang các trường hợp kiểm thử (test cases) , cung cấp thông tin chi tiết để kiểm thử các chức năng phức tạp, vv. BA cũng tham gia vào cuộc họp lập kế hoạch để giúp nhóm hiểu được flow của dự án, sự phức tạp và mức độ phụ thuộc.

BA phải liên tục tìm hiểu về xu hướng mới đang diễn ra trên thị trường, tiếp tục đổi mới và luôn cập nhật về lĩnh vực kinh doanh mà sản phẩm đã được tạo ra.

Chuyên viên phân tích nghiệp vụ (BA) với tư cách là chủ sở hữu sản phẩm (PO)

Về định nghĩa Product Owner là người sở hữu sản phẩm, hiểu rõ nhất về sản phẩm và các yêu cầu của sản phẩm. Thông thường vai trò này được đảm nhiệm bởi khách hàng. Nếu khách hàng không có người thực hiện việc này thì có thể người đóng vai trò BA của công ty phần mềm hoặc của đơn vị tư vấn sẽ thực hiện vai trò này. Product Owner chịu trách nhiệm về yêu cầu đầu ra của sản phẩm và là người chấp nhận sản phẩm.

BA phải hiểu các yêu cầu của các bên liên quan, suy nghĩ của họ về việc kinh doanh trước và những gì (và làm thế nào) doanh nghiệp nên phát triển. Sau đó dựa trên yêu cầu của các bên liên quan, BA phải tạo tài liệu, user stories, mức độ ưu tiên của các stories, giúp team hiểu chúng, trả lời các truy vấn của họ về các vấn đề tương tự v.v ...

Điều quan trọng nhất cần lưu ý ở đây là BA có thể chất sẵn có và không được định vị địa lý theo múi giờ khác nhau để tránh "khoảng cách trong giao tiếp".

Nếu BA đóng vai trò như PO bị ngăn cách bởi vị trí địa lý và thời gian thì cách duy nhất để trao đổi với họ là thông qua email hoặc thông qua chat hoặc gọi điện, do đó điều này có thể dẫn đến những thiếu xót, khoảng cách và thậm chí thông tin sai lệch vào các thời điểm.

Theo kinh nghiệm của tôi, điều này nên được khắc phục khi BA đang ngồi trong văn phòng của bạn, bên cạnh nhóm của bạn để công việc của bạn sẽ không bị cản trở và anh ta sẽ dễ dàng tiếp cận. Theo quan điểm của BA, họ thay mặt cho các bên liên quan / khách hàng, đưa ra quyết định phù hợp và thậm chí họ cần học các kỹ năng mới có thể bao gồm học một số kỹ thuật phát triển.

Một nhà phân tích kinh doanh với tư cách là một chủ sản phẩm là một lợi thế bổ sung bởi vì các nhà phân tích kinh doanh hiểu sản phẩm rất tốt, mức độ ưu tiên và phạm vi nhiệm vụ cũng nhưcó thể thương lượng được.

BA đóng vai trò như một thành viên trong nhóm

Một lựa chọn khác là có Chuyên viên phân tích nghiệp vụ làm thành viên nhóm vì Chủ sở hữu sản phẩm sẽ không có phải lúc nào cũng có. Khi các nhà phân tích kinh doanh là một thành viên trong nhóm sau đó họ giúp đỡ các đồng nghiệp trong việc chuẩn bị backlog.

Việc có một Chuyên viên phân tích nghiệp vụ làm thành viên nhóm sẽ thuận lợi hơn vì nhóm kỹ thuật có thể dễ dàng và thoải mái khi giao tiếp với BA để làm rõ các yêu cầu hoặc thảo luận. BA cũng làm việc chặt chẽ với nhóm QA để kiểm tra tức là phân tích mức độ phù hợp, các test case được tạo ra, những yêu cầu, mức độ phụ thuộc hoặc ảnh hưởng mà chưa được làm rõ.

Đôi khi các tiêu chuẩn chấp nhận (acceptance criteria) được viết bởi chủ sở hữu Sản phẩm (PO) có thể mơ hồ và không rõ ràng, do đó khi BA đóng vai trò như một thành của viên nhóm, trách nhiệm của BA là viết một tiêu chuẩn chấp nhận tỉ mỉ và được giải thích kỹ lưỡng. Nếu nhóm cần thêm thông tin, thì BA cũng tạo ra tài liệu wireframe, luồng nghiệp vụ của dự án vv để giúp nhóm hiểu được các yêu cầu.

Trong các dự án quy mô lớn, nơi các mô-đun được phân cho các đội, có BA là một lợi thế bổ sung. Khi tất cả các nhóm có cùng một BA, họ có thể suy nghĩ về khả năng tương tác của các mô-đun, làm thế nào các tính năng mới hoặc các bản cập nhật có thể sẽ ảnh hưởng đến các mô-đun khác, vv

Vì vậy, điều này sẽ giúp rất nhiều cho các đội kỹ thuật để xem xét các khía cạnh với tư cách làm những người sẽ làm những user stories hoặc các tiêu chuẩn chấp nhận được đề cập.

Tầm quan trọng và vai trò của BA trong nhóm SCRUM

Vai trò của các nhà phân tích kinh doanh trong SCRUM là rất quan trọng trong sự thành công của một dự án. Họ tham gia ngay từ khi hiểu được yêu cầu của khách hàng đối với Bản Sprint Demo. Chúng là điểm liên lạc đầu tiên cho nhóm kỹ thuật để làm rõ các yêu cầu của khách hàng. Chúng thậm chí còn quan trọng hơn trong các giai đoạn ban đầu của một dự án mới và các dự án có quy mô lớn.

Chủ sở hữu sản phẩm sẽ không phải lúc nào cũng là một nhà văn tốt, đôi khi họ xuất phát từ một nền tảng kỹ thuật và do đó nó trở thành trách nhiệm của các nhà phân tích kinh doanh để viết những stories, chấp nhận, wireframes vv

Trong dự án của tôi, PO của chúng tôi không giỏi trong việc làm tài liệu và thậm chí những user stories được viết không bao giờ lớn hơn 2-3 lớp (ví dụ: As a [User role], i want to [goal], so i can [reason] ) trong khi tiêu chí chấp nhận chỉ là một lớp. Nếu những user stories này đc viết bới BA thì chúng thường xuyên được sửa đổi, làm cho chúng chi tiết và tỉ mỉ hơn.

Thậm chí đôi khi, PO của chúng tôi đã viết các user stories có 21 hoặc nhiều hơn 21 story points và do đó BA phải dành nhiều thời gian và nỗ lực để chia nhỏ và ưu tiên chúng với PO.

Bạn có thể tưởng tượng điều gì sẽ xảy ra nếu không có BA và PO tạo ra các user stories như ‘Là 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 tiêu chí chấp nhận như:

1. Khách hàng sẽ có thể đăng nhập.
2. Khách hàng có thể thực hiện các giao dịch trong tài khoản của tôi.
3. Khách hàng có thể tải xuống các lịch sử báo cáo của tôi, v.v.

Bây giờ, theo ý kiến của tôi, user stories này sẽ giữ hơn 34 story points, do đó cần phải chia nhỏ hơn nữa. Mọi thứ sẽ trở nên tồi tệ hơn đối với đội ngũ kỹ thuật nếu không có sơ đồ lưu lượng thích hợp và màn hình giao diện người dùng (được tạo ra).

Điều này sẽ dẫn đến thất bại của 1 sprint, và kết quả là, một dự án thất bại. Trừ khi PO là một Chuyên viên phân tích kinh doanh được đào tạo / thực hành, cần phải có một người trong nhóm.

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

QA là một người xác minh các giải pháp đề xuất cho một vấn đề/yêu cầu bằng cách kiểm thử nó. Do đó các nhà phân tích nghiệp vụ/các bên liên quan/chủ sở hữu sản phẩm rất háo hức muốn biết về những thông tin phản hồi của một QA. Sự tham gia của một BA trong kiểm thử là ít hơn trong đội phát triển.

Nhân viên phân tích nghiệp vụ làm việc chặt chẽ với QA trong việc xem xét lại các trường hợp kiểm thử cái cung cấp một cái nhìn sâu hơn về luồng nghiệp vụ, yêu cầu hoặc mức độ ảnh hưởng chưa được làm rõ. Do đó, việc chia sẻ kiến thức này (theo BA) làm cho họ hiểu chức năng sản phẩm, quy tắc kinh doanh, kỳ vọng của khách hàng, luồng, yếu tố phụ thuộc.

QA luôn kiểm thử từ quan điểm của end user, người sẽ sử dụng sản phẩm, do đó cơ hội giúp khách hàng nâng cấp, cải tiến sản phẩm nhiều hơn (khi so sánh với nhà phát triển). Các lập trình viên phát triển sản phẩm cho user story và bộ các tiêu chí chấp nhận nhất định nhưng không phải lúc nào họ cũng nghĩ về cách khách hàng sử dụng sản phẩm.

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

QA có thể bắt đầu tham gia vào vai trò của BA trong SCRUM vì có rất nhiều cơ hội được trình bày trong công việc hàng ngày.

QA dễ dàng để có được vai trò như một BA:

• Nghiên cứu các yêu cầu rất sâu và chỉ ra những khoảng trống trong các cuộc họp đánh giá / các buổi thảo luận (brainstoming), vv Cố gắng suy nghĩ về các giải pháp tốt hơn và thảo luận tương tự với nhóm và BA.
• Hãy chú ý đến các cuộc gọi với PO, đặ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 thể hiện sự quan tâm của bạn đối với sản phẩm.
• Dung hòa được các quan hệ của mình giữa BA và nhóm phát triển, bạn nên là điểm liên hệ cho các lập trinh viên trong trường hợp làm rõ hoặc nghi ngờ.
• Thiết lập quy trình kiểm thử và tiếp tục đổi mới nó, thay đổi nó để giúp đỡ trong việc release Sprint thành công.
• Trong trường hợp các sản phẩm có giao diện người dùng ưa thích, hãy tìm các xu hướng mới và đề xuất những cải tiến như vậy.
• Hiểu toàn bộ sản phẩm trong và ngoài.
• Xây dựng kiến thức vững chắc về các bên liên quan, mong đợi của họ và chia sẻ kinh nghiệm của bạn với họ. Điều này cũng ngụ ý rằng để có được vai trò BA, bạn cần phải nâng cao kỹ năng của mình. Một số khóa học bao gồm cả trình độ cơ bản và trình độ nâng cao được tìm thấy trên thị trường.

Nguồn dịch: https://www.softwaretestinghelp.com/role-of-business-analysts-in-scrum/