Menú

Rol de los analistas de negocios en SCRUM y ¿Por qué es mejor un control de calidad para este rol?

  • Principal
  • Pruebas Ágiles
  • Rol de los analistas de negocios en SCRUM y ¿Por qué es mejor un control de calidad para este rol?

role business analysts scrum

cómo seleccionar el botón de radio en selenium webdriver

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Papel destacado de los analistas de negocios en SCRUM:

Un analista de negocios que se conoce en breve como un BA juega un papel muy drástico e importante en MELÉ .

Esta persona es el vínculo entre el propietario / cliente del producto y el equipo técnico de TI. Aunque hemos encontrado varios tutoriales en nuestro sitio web sobre BA, este tutorial de alguna manera será único y le explicará la importancia de BA en SCRUM.

¡¡Vamos a explorar!!

=> Consulte TODOS los tutoriales de Business Analyst aquí.

Rol de los analistas de negocios en SCRUM y por qué un control de calidad es mejor para este rol_

Lo que vas a aprender:

Responsabilidades de un BA

Hay varios roles de Business Analysts en Scrum y hay ciertas responsabilidades a las que un BA debe adherirse.

A continuación se mencionan algunos selectivos entre ellos.

  • Preparar la acumulación de productos en función de la priorización proporcionada por el propietario del producto.
  • Analizar las necesidades del cliente y encontrar las soluciones para atenderlas.
  • Crear los requisitos en forma de historias de usuario con los criterios de aceptación adecuados.
  • Si en caso de que las historias de usuario ya hayan sido creadas por el propietario del producto (con criterios de aceptación), revíselas para asegurarse de que se cubran todas las reglas comerciales y que los criterios de aceptación cumplan con la funcionalidad de la historia de usuario.
  • Trabajar con el propietario del producto y las partes interesadas para comprender el alcance, sugerir mejoras a los requisitos, etc.
  • Preparar documentos como wireframes, flujo de diseño, UI, etc., como y cuando sea necesario.

Aparte de esto, un Analista de negocios es un participante importante en las sesiones de lluvia de ideas cuando el equipo se reúne para discutir el trabajo pendiente del próximo sprint. El BA guía al equipo, lo ayuda a comprender los requisitos e incluso a veces tiene que aprobar la implementación.

También trabaja en estrecha colaboración con los QA, como analizar la cobertura de prueba, convertir casos de uso del mundo real en casos de prueba, proporcionar información para probar funcionalidades complejas, etc. El BA también participa en la reunión de planificación para ayudar al equipo en las estimaciones ayudándolos a comprender el flujo, la complejidad y la dependencia.

BA tiene que seguir conociendo las nuevas tendencias que se están produciendo en el mercado, seguir innovando y estar actualizado sobre el área de negocio para la que se ha elaborado el producto.

licenciado en Letras

Analista de negocios como propietario de un producto

Dependiendo del cliente y la empresa, sucede que algunas empresas tienen al Analista de negocio como propietario del producto. En estos casos, el BA es el punto de contacto para todas las consultas. El BA se convierte entonces en el mediador entre el equipo y las partes interesadas.

El BA debe comprender los requisitos de las partes interesadas, su forma de pensar sobre cómo llevar el negocio adelante y qué (y cómo) debería crecer el negocio. Luego en base a los requerimientos de los Stakeholders, el BA debe crear los documentos, historias de usuarios, priorizar las historias, ayudar al equipo a entenderlas, responder sus consultas sobre las mismas, etc.

Lo más importante a tener en cuenta aquí es que esto es aconsejable cuando el BA está disponible físicamente y no está geolocalizado en una zona horaria diferente para evitar la 'brecha en la comunicación'.

Si el BA como el propietario del producto está geolocalizado en una zona horaria diferente, entonces no es posible acercarse a él cada vez y la única forma de comunicarse es por correo electrónico o chats o llamadas, por lo tanto, esto puede resultar en falta, brecha e incluso falta de comunicación a veces.

Según mi experiencia, esto debe seguirse cuando el BA esté sentado en su oficina, al lado de su equipo, para que su trabajo no obstaculice y sea fácilmente accesible. Desde el punto de vista de un BA, son dueños del producto en nombre de las partes interesadas / clientes, toman las decisiones adecuadas e incluso necesitan aprender nuevas habilidades que pueden incluir aprender algunos aspectos técnicos del desarrollo.

Tener un analista comercial como propietario de producto es una ventaja adicional porque el analista comercial comprende muy bien el producto y también se puede negociar la priorización y el alcance de las tareas.

BA-PO

Analista de negocios como miembro del equipo

La otra opción es tener al analista comercial como miembro del equipo porque el propietario del producto no estará disponible siempre. Cuando el analista de negocios es un miembro del equipo, ayuda a los compañeros a preparar el trabajo pendiente.

Tener un analista de negocios como miembro del equipo es más ventajoso porque el equipo técnico encuentra fácil y cómodo comunicarse con el BA para aclaraciones o discusiones. El BA también trabaja en estrecha colaboración con el equipo de control de calidad para realizar pruebas, es decir, analizar la cobertura, los casos de uso cubiertos, los requisitos ocultos, la confiabilidad o los efectos.

A veces, los criterios de aceptación escritos por el propietario del producto pueden ser vagos y no claros, luego, como miembro del equipo, es responsabilidad del BA redactar criterios de aceptación elaborados y bien explicados. Si el equipo necesita más información, el BA también crea documentos de estructura alámbrica, documentos de flujo, etc. para ayudar al equipo a comprender los requisitos.

En proyectos a gran escala donde los módulos se distribuyen entre equipos, tener un BA para más de un equipo también es una ventaja añadida. Dado que el BA es el mismo en todos los equipos, puede pensar en la interoperabilidad de los módulos, cómo las nuevas funciones o actualizaciones afectarán a los otros módulos, etc.

Por tanto, esto ayudaría mucho a los equipos técnicos a considerar aspectos como los que no siempre lo mencionan las historias de usuario o los criterios de aceptación.

Miembro BA_Team

Importancia y rol de los analistas de negocios en el equipo SCRUM

El papel de los analistas de negocios en SCRUM es muy importante para el éxito de un proyecto. Su participación comienza desde comprender las necesidades del cliente hasta la demostración de Sprint. Son el primer punto de contacto del equipo técnico para aclaraciones. Son incluso más importantes en las fases iniciales de un nuevo proyecto y los proyectos que son de gran escala.

El Product Owner no siempre será un buen escritor, a veces provienen de una formación técnica y, por lo tanto, es responsabilidad del Business Analyst escribir las historias, la aceptación, los wireframes, etc.

En mi proyecto, nuestro PO no era tan bueno con la documentación e incluso las historias de usuario escritas nunca tenían más de 2-3 líneas, mientras que los criterios de aceptación eran solo una línea. Era el Business Analyst quien solía modificarlos, hacerlos más explicativos y elaborados.

Incluso a veces, sucedió que nuestro PO escribió historias de usuarios que tenían 21 o más puntos de historia y, por lo tanto, el analista de negocios tuvo que dedicar más tiempo y esfuerzos para desglosarlas y priorizarlas con el propietario del producto.

Puede imaginarse lo que sucedería si no hubiera un analista de negocios y el propietario de su producto hubiera creado una historia de usuario como 'Como cliente, quiero realizar todas las operaciones bancarias para mi cuenta', con criterios de aceptación como:

  1. El cliente debería poder iniciar sesión.
  2. El cliente debería poder realizar transacciones en mi cuenta.
  3. El cliente debería poder descargar mis declaraciones históricas, etc.

Ahora, en mi opinión, esta historia de usuario tendría incluso más de 34 puntos de historia, por lo que es necesario desglosarla aún más. Las cosas empeorarían para el equipo técnico si no se proporcionan los diagramas de flujo y las pantallas de interfaz de usuario adecuadas (que se crearán).

Esto conduciría a un sprint fallido y, a su vez, a un proyecto fallido. A menos que el Product Owner sea un Analista de Negocios capacitado / practicado, es necesario tener uno en el equipo.

¿Por qué un control de calidad es mejor para este trabajo?

QA es una persona que verifica la solución propuesta para un problema / requisito probándola. Por lo tanto, los analistas de negocios / las partes interesadas / los propietarios de productos están ansiosos por conocer los comentarios de un control de calidad. La participación de un BA en las pruebas es poco más que lo que está en desarrollo.

Un analista de negocios trabaja en estrecha colaboración con un control de calidad para revisar la cobertura del caso de prueba, lo que proporciona una idea de los flujos ocultos o los requisitos / efectos. Por lo tanto, este tipo de intercambio de conocimientos (por parte del BA) les permite comprender la funcionalidad del producto, las reglas comerciales, las expectativas del cliente, los flujos, las dependencias y todo por completo.

El control de calidad siempre prueba desde el punto de vista del cliente final que usaría el producto, por lo tanto, las posibilidades de ayudar al cliente a realizar mejoras, mejoras en el producto son mayores (en comparación con un desarrollador). Los desarrolladores desarrollan el producto para la historia de usuario dada y el conjunto de criterios de aceptación, pero no siempre piensan en cómo un cliente usaría el producto. .

En desarrollo, la implementación de un producto, el flujo y las reglas están bien definidas, pero las pruebas se basan completamente en el pensamiento lógico y la capacidad de pensar desde el punto de vista de los usuarios finales.

QA puede comenzar a asumir el rol de Analistas de Negocios en SCRUM debido a la gran cantidad de oportunidades que se presentan en el trabajo diario.

Lectura recomendada => Cambio de carrera de un examinador a un BA

Es muy fácil para un QA entrar en roles como:

  • Estudie los requisitos muy a fondo y señale las lagunas en las reuniones de revisión / sesiones de lluvia de ideas, etc. Intente pensar en mejores soluciones y discuta las mismas con el equipo y el BA.
  • Esté atento a las llamadas con el propietario del producto, haga preguntas y comparta sus hallazgos. Esto aumentará la confianza del propietario del producto que muestra su interés en el producto.
  • Colócate entre el BA y el equipo de desarrollo, debes ser el punto de contacto de los desarrolladores en caso de aclaraciones o dudas.
  • Configure el proceso de prueba y siga innovándolo, cambiándolo para ayudar a entregar sprints exitosos.
  • En el caso de productos con interfaces de usuario sofisticadas, busque nuevas tendencias y sugiera tales mejoras.
  • Comprenda el producto por completo.
  • Desarrolle un conocimiento sólido de sus partes interesadas, sus expectativas y comparta su experiencia con ellos.

Esto también implica que para acceder al puesto de BA es necesario mejorar sus habilidades. En el mercado se encuentran varios cursos que incluyen tanto el nivel básico como el avanzado.

¿Eres BA / QA? ¿Hemos señalado correctamente todo sobre su papel? O crees que nos hemos perdido algo que realizas de forma única? Estaremos encantados de recibir noticias tuyas. ¡¡No dudes en compartirlos con nosotros en la sección de comentarios a continuación !!

=> Visite aquí para ver la serie Business Analyst para todos.

Lectura recomendada

^