Vai trò của các Business Analyst trong SCRUM và tại sao 1 QA phù hợp với vai trò này?

Vai trò nổi bật của các Business Analyst trong SCRUM

Business Analyst được gọi ngắn gọn là BA đóng 1 vai trò quan trọng trong SCRUM.

Người này là cầu nối giữa các owner/customer của sản phẩm và các team kỹ thuật viên IT. Mặc dù chúng ta đã gặp 1 vài hướng dẫn trên web về BA, tuy nhiên bài này theo cách nào đó sẽ là bài duy nhất sẽ giải thích cho bạn tầm quan trọng của BA trong SCRUM.

Trách nhiệm của BA

1 số vai trò của các BA trong SCRUM và có 1 số trách nhiệm nhất định mà BA phải tuân thủ.

1 vài trong số chúng được đề cập dưới đây.

• Chuẩn bị những tính năng mong đợi của sản phẩm dựa trên mức độ ưu tiên được cung cấp bởi các owner của sản phẩm.
• Phân tích nhu cầu của các khách hàng và tìm các giải pháp để giải quyết chúng.
• Tạo các yêu cầu dưới dạng user story với các acceptance criteria phù hợp.
• Nếu trong trường hợp các user story được tạo ra bởi các owner của sản phẩm (với acceptance criteria), thì cần xem xét chúng để đảm bảo mọi business rule được đảm bảo và các acceptance criteria đáp ứng các chức năng user story.
• Làm việc với khách hàng và các bên liên quan để hiểu phạm vi, đề xuất cải tiến các yêu cầu…
• Chuẩn bị các tài liệu như wireframe, design flow, UI…khi được yêu cầu.

Ngoài ra, 1 BA là 1 thành viên quan trọng trong các phiên thảo luận khi các team họp để thảo luận về các tính năng mong muốn của Sprint. Các BA hướng dẫn các team, giúp họ hiểu các yêu cầu và thậm chí đôi khi phải phê duyệt việc thực hiện.

Họ cũng làm việc chặt chẽ với các QA như phân tích phạm vi test, chuyển đổi các real-world use case vào trong các test case. Cung cấp cái nhìn sâu sắc để test các chức năng phức tạp… Các BA cũng tham gia vào các cuộc họp lập kế hoạch để giúp các team lập dự toán bằng cách giúp họ hiểu các flow, sự phức tạp và sự phụ thuộc.

BA phải luôn học hỏi về các xu hướng mới mà đang diễn ra trên thị trường, đối mặt và luôn cập nhập về các business area cho các sản phẩm mà đã được tạo ra.

BA đóng vai trò như 1 khách hàng

Tùy thuộc vào các khách hàng và các công ty, 1 vài công ty có các BA đóng vai trò là khách hàng. Trong các trường hợp này, các BA là các đầu mối liên lạc cho tất cả các query. Các BA trở thành trung gian hòa giải giữa các team và các bên liên quan.

Các 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 tiếp nhận các business và các business nào nên phát triển. Sau đó dựa trên các yêu cầu của các bên liên quan, các BA phải tạo các tài liệu, các user story, các story ưu tiên, giúp các team hiểu chúng, phản hồi các query về các điều tương tự…

Điều quan trọng nhất cần lưu ý ở đây là điều này được khuyến khích khi các BA luôn sẵn sàng và không có sự khác biệt về múi giờ để tránh các “khoảng cách giao tiếp”.

Nếu các BA đóng vai trò khách hàng có 1 mùi giờ khác biệt, thì không thể tiếp cận họ mọi thời điểm và cách duy nhất để giao tiếp với họ là các email hay chat hoặc các cuộc gọi, do đó điều này có thể dẫn đến thiếu sót, khoảng cách và thậm chí đôi khi thông tin sai lệch.

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

Có BA đóng vai trò khách hàng là thêm 1 lợi thế bởi vì các BA hiểu rõ các sản phẩm, và mức độ ưu tiên và phạm vi của các task có thể được đàm phán.

BA đóng vai trò 1 team member

Các tùy chọn khác là để có các BA đóng vai trò như 1 team member bởi vì khách hàng sẽ không sẵn sàng mọi thời điểm. Khi các BA là 1 team member họ có thể giúp các đồng nghiệp trong việc chuẩn bị các tính năng mong muốn.

Có BA đóng vai trò 1 team member có nhiều lợi thế vì các team kỹ thuật dễ dàng tìm kiếm và thoải mái trao đổi với các BA để làm rõ hoặc thảo luận. Các BA cũng làm việc chặt chẽ với các QA team cho việc test… phân tích phạm vi, các use case được đảm bảo, các yêu cầu tiềm ẩn hoặc độ tin cậy hay hiệu quả.

Đôi khi các acceptance criteria được viết bởi các khách hàng có thể mơ hồ và không rõ ràng, sau đó với vai trò team member, trách nhiệm của các BA là viết 1 acceptance criteria giải thích rõ ràng và chi tiết. Nếu các team cần thêm thông tin, thì các BA cũng tạo các tài liệu wireframe, các tài liệu flow… để giúp các team hiểu các yêu cầu.

Trong các dự án quy mô lớn, mà các module được phân phối giữa các team, có BA cho team cũng là 1 lợi thế. Vì các BA chung giữa các team, họ có thể suy nghĩ về khả năng tương tác của các module, cách thức mà các tính năng hoặc update mới sẽ ảnh hưởng đến các module khác…

Do đó điều này sẽ giúp rất nhiều để các team kỹ thuật xem xét các khía cạnh khi không phải làm các user story hay các acceptance criteria được đề cập.

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

Vai trò của các BA trong SCRUM là rất quan trọng trong sự thành công của 1 dự án. Sự tham gia của họ bắt đầu ngay từ khi hiểu được nhu cầu của các khách hàng đối với các Sprint Demo. Họ là đầu mối liên lạc đầu tiên cho các team kỹ thuật để làm rõ. Họ thậm chí còn quan trọng hơn trong các giai đoạn ban đầu của 1 dự án mới và cá dự án có quy mô lớn.

Khách hàng sẽ không phải luôn luôn là 1 good writer, đôi khi họ bắt nguồn từ 1 technical background nào đó và do đó, trách nhiệm của các BA là phải viết các story, acceptance, các wireframe…

Trong dự án của tôi, PO của chúng tôi thực sự không làm tốt tài liệu và thậm chí các user story được viết không bao giờ nhiều hơn 2-3 lớp trong khi các acceptance criteria chỉ 1 lớp. Chính các BA đã sửa chúng, làm chúng trở nên diễn giải và chi tiết hơn.

Thậm chí đôi khi, xảy ra việc mà PO của chúng tôi viết user story mà có tới 21 hay nhiều hơn 21 story point và do đó các BA phải dành thêm thời gian và nỗ lực giảm chúng xuống và đưa ra mức độ ưu tiên của chúng với các khách hàng.

Bạn có thể tưởng tượng điều gì sẽ xảy ra nếu không có BA và khách hàng của bạn tạo ra user story giống như “Khi 1 khách hàng, tôi muốn thực hiện tất cả các hoạt động của ngân hàng với tài khoản của tôi”, với acceptance criteria giống như:

1. Khách hàng sẽ có thể đăng nhập.
2. Khách hàng sẽ 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 sẽ có thể tải xuống các mục lịch sử của tôi…

Bây giờ, theo ý tưởng của tôi, user story này sẽ giữ thậm chí nhiều hơn 34 story point, do đó cần phải chia nhỏ nó hơn nữa. Mọi thứ sẽ trở nên tồi tệ cho các team kỹ thuật nếu các flow diagram phù hợp và các UI screen (đã được tạo) không được cung cấp.

Điều này sẽ dẫn đến 1 sprint lỗi, và theo đó, 1 dự án chắc chắn sẽ lỗi. Trừ khi các khách hàng là 1 BA đã được đào tạo/thực hành.

Tại sao 1 BA 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 được đề xuất cho 1 problem/requirement bằng cách test nó. Do đó các BA/các bên liên quan/các khách hàng rất mong đợi muốn biết về các feedback của 1 BA..

BA làm việc chặt chẽ với 1 QA trong việc xem xét các phạm vi của test case và cung cấp 1 cái nhìn sâu sắc về các flow hay requirement/effect. Do đó, kiến thức này được chia sẻ này (bởi các BA) làm cho họ hiểu các function của sản phẩm, các business rule, các kỳ vọng của khách hàng, các flow, các sự phụ thuộc và mọi thứ hoàn chỉnh.

QA luôn test từ quan điểm của khách hàng mà sẽ sử dụng sản phẩm, do đó có cơ hội giúp khách hàng cải tiến sản phẩm nhiều hơn (khi so sánh với 1 developer). Các developer phát triển các sản phẩm từ các user story và các thiết lập acceptance criteria có sẵn nhưng không phải lúc nào họ cũng nghĩ về việc 1 khách hàng sẽ sử dụng các sản phẩm như thế nào.

Trong phát triển, việc thực hiện 1 sản phẩm, các flow, và các rule được xác định rõ nhưng việc test hoàn toàn dựa trên tư duy logic và khả năng suy nghĩ từ quan điểm của các end user.

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

QA dễ dàng để có được các vai trò như:

Nghiên cứu các requirement rất sâu sắc và chỉ ra các lỗ hổng trong các cuộc họp review/phiên thảo luận… Cố gắng nghĩ về các giải pháp tốt hơn và thảo luận tương tự với team và các BA.

Hãy chú ý đến các cuộc gọi với khách hàng, đặt các câu hỏi và chia sẻ những phát hiện của bạn. Điều này sẽ thúc đẩy sự tự tin của khách hàng thể hiện sự quan tâm của bạn đối với sản phẩm.

Sẵn sàng đứng giữa các BA và các development , bạn nên trở thành đầu mối lên lạc cho các developer trong trường hợp cần làm rõ thông tin.

Thiết lập các quy trình test và tiếp tục đổi mới nó, thay đổi nó để giúp cung cấp các sprint thành công.

Trong trường hợp các sản phẩm với các UI đặc biệt, hãy tìm hiểu các xu hướng mới và để xuất các cải tiến.

Hiểu hoàn toàn các sản phẩm từ trong ra ngoài.

Xây dựng 1 kiến thức vững chắc về các bên liên quan, kỳ vọng của họ và chia sẻ kinh nghiệm của bạn với họ.

Điều này có ngụ ý rằng để có được vai trò của BA bạn cần nâng cao kỹ năng của bạn. 1 số khóa học bao gồm cả cấp độ cơ bản và nâng cao có thể tìm thấy trên thị trường.

Tham khảo: https://www.softwaretestinghelp.com/role-of-business-analysts-in-scrum/