¿Cómo maneja un equipo Scrum las responsabilidades tradicionales de BA?

Pregunta vinculada

Esta pregunta fue propuesta por los participantes de la discusión de la pregunta anterior, más general .

Pregunta

El trabajo del analista de negocios a menudo implica una especie de enfoque de diseño directo o en cascada. Debido a esto, supongo, se vuelve controvertido cuando se considera en el contexto de un entorno Scrum ágil.

¿Cómo maneja un equipo Scrum las responsabilidades tradicionales de BA?

¿Puede compartir lo que cree que son las "responsabilidades tradicionales de BA" para usted? Estaba escribiendo una respuesta, pero luego me di cuenta de que podría tener expectativas muy diferentes a las tuyas.
Me gustaría mantener la pregunta lo más general posible, para permitir que se capturen y discutan muchos enfoques diferentes.
Estoy de acuerdo con @Erik: a menos que defina qué son las "responsabilidades tradicionales de BA", esta pregunta es demasiado amplia para responder. Diferentes organizaciones tienen diferentes definiciones de lo que consideran que son las responsabilidades de un analista de negocios.
@ThomasOwens La pregunta fue propuesta por un participante de la discusión de la pregunta vinculada, así que dirijámosle su comentario. Sin embargo, describí (en esta pregunta) la principal preocupación relacionada con los BA: deben funcionar en forma de cascada, lo que significa que deben analizar el alcance, los requisitos ANTES de que los desarrolladores comiencen a trabajar en ellos.
Cuando pienso en el rol de un analista de negocios, no veo ninguna implicación de un "enfoque de diseño directo o en cascada", por lo que es esencial que defina cuáles son las "responsabilidades tradicionales de BA" y qué " el trabajo del analista de negocios" es.
@ThomasOwens Por ejemplo, en un campo complejo, como fintech o la banca, antes de que los desarrolladores puedan realizar una tarea en desarrollo, la tarea debe estar claramente descompuesta, claramente definida y esto es lo que suele hacer BA ANTES de la reunión de planificación de Sprint: BA trabaja antes de los desarrolladores Esto es lo que significa 'cascada-ish'. El BA y el desarrollador NO trabajan en las mismas tareas durante un Sprint.
Tener una descomposición clara del trabajo y unidades de trabajo claras es común en muchas industrias y lo consideraría una buena práctica. En Scrum, esto siempre se hace antes de la Planificación de Sprint en actividades de refinamiento como una colaboración entre el Dueño del Producto y los Desarrolladores. Nada de lo que describes es, en absoluto, "cascada".
@ThomasOwens Lo que me cuesta transmitir aquí es la suposición subyacente de que los desarrolladores están aguas abajo del análisis comercial, en lugar de ser colaboradores activos en el proceso. Esa es la parte de "cascada" a la que se refiere.
@ ToddA.Jacobs, esa terminología es un poco confusa. Es más de "todos los demás", no de "cascada" :) Solo Scrum insiste en tener reuniones (incluidos los refinamientos) con todo el equipo. El resto de metodologías no parecen preocuparse tanto por esto.
@StanislavBashkyrtsev Ve eventos similares en DSDM, aunque hay más roles, por lo que es posible que no tenga todos los roles en un solo evento, dependiendo de cómo se desglosen sus roles. Extreme Programming también tiene el concepto de equipo completo. Así que no es solo Scrum. Esto se expresa en el Manifiesto Ágil: Business people and developers must work together daily throughout the project.El alcance y la frecuencia de la colaboración de diferentes roles depende de la metodología específica.
@Daniel si uno de los requisitos es "no se le puede permitir hacer las cosas a la manera de Scrum", esa será la única respuesta que obtendrá. Dicho esto, uno de los proyectos en los que trabajo está en un campo complejo similar a la tecnología financiera, y no descomponemos ni definimos claramente las tareas antes del sprint, lo hacemos durante el sprint.
@Erik ¿Podría compartir el flujo de trabajo de su equipo? ¿Cuál es la definición de Listo para sus historias de usuario y tareas que no están claramente definidas?
Nuestra definición de listo es más o menos "Tenemos una idea decente de qué problema tiene y aproximadamente cómo lo solucionaríamos". La mayoría de las historias de usuarios que se incluyen en el sprint tienen alrededor de 5 líneas de declaración del problema y se han discutido con el equipo durante media hora. Eso es suficiente para saber si podemos resolver el problema dentro de un sprint o no. A partir de ahí, trabajamos en estrecha colaboración con el PO para resolver ese problema. Eso generalmente significa discutir con nuestro tipo BA sobre posibles soluciones, preparar un prototipo y luego mostrárselo al PO a medida que lo construimos.
Si el OP cree que va en la dirección correcta, lo construimos de verdad y luego, por lo general, el OP prueba la función por sí mismo en algunos escenarios de la vida real, o consigue que una parte interesada lo haga. A veces atraemos a una de las partes interesadas de la OP al sprint más directamente y trabajamos con ellos para construir la cosa con datos reales con ellos en la sala (o sala digital, dadas las circunstancias). Si estamos trabajando con un equipo de terceros, tratamos de mantenerlos en espera mientras trabajamos. Generalmente entre su conocimiento del dominio y la comprensión del problema, podemos trabajar sin ningún tipo de documentos formales

Respuestas (5)

¿Cómo maneja un equipo Scrum las responsabilidades tradicionales de BA?

Un analista experto es un activo útil para un equipo Scrum.

Lo bien que trabajan en un equipo Scrum se reduce a una cuestión de tiempo.

El desafío para el BA es hacer el análisis de una manera que le permita al equipo responder rápidamente al cambio. Deben evitar vincular al equipo a un enfoque particular demasiado pronto. También necesitan incorporar de manera efectiva los comentarios de las partes interesadas y de los clientes en un corto plazo.

No hay una respuesta única sobre cómo funcionará un BA en un equipo Scrum, ya que dependerá del equipo, el dominio y la organización. Al igual que con todas las cosas ágiles, es importante que el equipo tenga un buen ciclo de inspección y adaptación que les permita optimizar gradualmente la forma en que BA trabaja con el equipo.

Para responder a esto de manera efectiva, es importante dividir roles, títulos de trabajo y habilidades. Scrum no tiene absolutamente nada que decir acerca de los títulos de trabajo, por lo que podemos resolver eso con bastante rapidez diciendo: siempre que un "trabajo" en particular no entre en conflicto expresamente con Scrum, está "permitido" en el marco de Scrum. decir que trabajos particulares pueden causar con frecuencia disfunciones. Por ejemplo, un gerente está "permitido" en Scrum, pero si ese gerente se mide por su capacidad para impulsar el rendimiento del equipo y luego se respetan las reglas de Scrum, lo que dificulta la capacidad del gerente para hacerlo, esta es una receta para el desastre. .

Ahora, Scrum describe 3 roles (en realidad llamados responsabilidades en la revisión más reciente de la guía). El propietario del producto, el Scrum Master y los desarrolladores (piense en los desarrolladores de productos, no en los programadores). Existen algunas reglas sobre cómo interactúan estas 3 responsabilidades. Por ejemplo, el propietario del producto es responsable de ordenar el trabajo pendiente, mientras que los desarrolladores son responsables de crear el plan para el Sprint.

Ambos requieren ciertas habilidades y aquí es donde alguien que está acostumbrado a desempeñar el papel de BA puede tener algunos desafíos que superar. En muchas organizaciones, se espera que un BA trabaje con las partes interesadas, comprenda las prioridades, cree transparencia, etc. Estas son claramente habilidades requeridas por la OP y responsabilidades de la OP. Por otro lado, a muchos BA también se les pide que averigüen qué trabajo se debe hacer y cómo. Estas son habilidades y responsabilidades de los Desarrolladores. Aquí es donde tener un BA puede ser problemático en Scrum. Ahora, hay un punto en la Guía de Scrum que dice que el PO no tiene que hacer las cosas de las que es responsable. Entonces, se podría argumentar que un BA es simplemente un miembro del equipo de desarrollo que hace las cosas que pertenecen a la OP. Esto, sin embargo, se complica en la práctica. ¿Realmente la PO es la dueña? A menudo no. También, no hay subequipos en los Desarrolladores. ¿Todos los desarrolladores tienen una responsabilidad compartida por las cosas que hace el BA? No en la mayoría de los casos.

Al final del día, la pregunta sobre los BA para la mayoría de las empresas se reduce a esto: si está tratando de cambiar la mitad de su forma de trabajar y permanecer igual, se está preparando para el fracaso. Puede mejorar la forma en que desarrolla software sin adoptar Scrum. Incluso puedes adoptar algunas prácticas de Scrum si te gustan. Pero si dices que quieres practicar Scrum y obtener todos los beneficios de Scrum, tienes que comprometerte.

¡Bien dicho! Voté esto porque creo que su tercer párrafo llega al meollo del asunto. También creo que su último párrafo es esencial, aunque me inclinaría a hacerlo más fuerte que (énfasis mío) " tengo que comprometerme".
Con respecto a los roles, para futuros visitantes (énfasis mío): "Scrum define tres responsabilidades específicas dentro del equipo Scrum: los desarrolladores, el propietario del producto y el Scrum Master". scrumguides.org/scrum-guide.html#scrum-team
Esta es una respuesta fantástica dadas las ambigüedades en la pregunta. El último párrafo, que casi cambia la mitad de una forma de trabajar, realmente lo resume todo para mí.
"Pero si dices que quieres practicar Scrum y obtener todos los beneficios de Scrum, tienes que comprometerte". También puede comprometerse a adoptar otras metodologías ágiles de desarrollo de proyectos que podrían funcionar mejor para usted que Scrum.
No hay subequipos (formales) en Scrum, pero la idea de que todos los "desarrolladores" tienen habilidades idénticas para abordar cada problema de desarrollo que surge es obviamente una tontería. Un desarrollador que tiene conocimiento especializado en "cosas BA" (sin embargo, la organización del OP elige definir qué es eso) no es diferente de un desarrollador que tiene conocimiento especializado en diseño de bases de datos, nanotecnología o cualquier otra cosa.
@ nik012000 - ¡absolutamente! Y también indico a los equipos en Kanban, que en realidad no es una metodología, sino un enfoque para ajustar su metodología de la manera que desee.

En mi equipo de 12 personas hay 2 BA* y en este momento tenemos 24 tickets (errores, nuevas características, aspectos técnicos) en la cartera de pedidos. Así que no estoy de acuerdo con que tener un BA implique mucho trabajo por adelantado.

En cuanto a Scrum, como mencioné en los comentarios, no parece que permita BA:

  • Puede pensar en ellos como OP, pero la mayoría de las veces los BA no son partes interesadas
  • Si piensa en ellos como Desarrolladores, significaría que no trabajan en los objetivos actuales de Sprint, sino que preparan tareas para futuros Sprints.

Si bien puede que no sea Scrum, no creo que los BA le impidan ser ágil de ninguna manera.

* Para ser justos, no somos solo BA. También soy líder de equipo, y el otro BA a veces hace algunas pruebas. Y ambos asumimos actividades de apoyo. Pero aún así ambos creamos tareas futuras. No usamos Scrum, pero incluso si lo hiciéramos, haríamos lo mismo, simplemente no hay otra forma de trabajar para nosotros.

'en cambio, preparan tareas para futuros Sprints'. Es por eso que usé el término 'por adelantado'. ¿Por qué no estás de acuerdo?
@Daniel, porque 24 tareas no son mucho trabajo inicial. Necesita trabajo por adelantado en cualquier caso. Incluso en Scrum, tiene un PO que prepara la acumulación de productos, refina cosas para el próximo sprint: ese es el trabajo inicial que no puede eliminar. Pero ciertamente no queremos hacer mucho de eso. Y algunas personas, por alguna razón, asocian los BA con mucho trabajo inicial.
@StanislavBashkyrtsev Creo que ese es el meollo del asunto. Todo el Equipo Scrum participa en el Refinamiento del Backlog, pero los Desarrolladores son responsables de la Planificación del Sprint (énfasis mío): "Esto se hace a menudo descomponiendo los elementos del Backlog del Producto en elementos de trabajo más pequeños de un día o menos. discreción exclusiva de los Desarrolladores. Nadie más les dice cómo convertir los elementos de la Lista de Producto en Incrementos de valor " . scrumguides.org/scrum-guide.html#sprint-planning ), y los Desarrolladores son responsables de "cómo".
El objetivo es evitar mini cascadas y BUFD, y la responsabilidad del trabajo típico de BA se distribuye entre el propietario del producto y los desarrolladores. Si todo el equipo de Scrum no participa en la planificación del diseño y las especificaciones, perderá las mayores ganancias que Scrum tiene para ofrecer.
@ ToddA.Jacobs, bueno, "ganancias" es un término relativo. Scrum ofrece "ganancias" solo cuando se compara con equipos muy ineficaces. Simplemente introduce demasiado desperdicio. No quiero que todo el equipo participe en el tedioso diseño/planificación de especificaciones, ya que esto se puede hacer (lo más probable, mejor y más rápido) entre 1 y 3 personas. Me gusta que la gente se concentre y por lo general están agradecidos por eso. Para su segundo punto: Scrum es una mini-cascada ya que tiene incrementos basados ​​​​en el tiempo . La diferencia es cuantitativa, no cualitativa. Aunque las cascadas pueden ser muy diferentes, algunas de ellas también pueden diferir cualitativamente.
@ToddA.Jacobs ¿Cuál es la mayor ganancia? ¿Puede dar un ejemplo de la práctica?

Advertencia por adelantado... Tengo una experiencia ágil formal limitada (especialmente Scrum), sin embargo, he utilizado aspectos de los enfoques ágiles bastante ampliamente, y algunos de mis equipos han incluido personas con habilidades de BA. Anticiparía que un rol tipo BA podría usarse bastante dentro de un proyecto que se ejecuta utilizando principios formales ágiles (incluido Scrum).

En primer lugar, para apoyar el trabajo del Product Owner en la definición de productos y resultados específicos del sistema, lo que puede requerir investigación y análisis con aportes de los usuarios del sistema y los destinatarios de los productos del sistema. Es posible que la OP no tenga el conocimiento detallado específico de todos los aspectos de los requisitos, por lo que se beneficiaría de alguien que ayude a documentar estos requisitos en apoyo de las historias de los usuarios. (Disculpas si la terminología no es del todo correcta).

En segundo lugar, trabajar como parte del equipo de desarrollo, aportando los insumos de negocio en nombre del Product Owner y ayudando al resto del equipo a interpretar correctamente los requisitos, evitando así el retrabajo en sprints posteriores.

En tercer lugar, trabajar como miembro del equipo de desarrollo para ayudar a verificar los productos y resultados del desarrollo (definición, diseño y realización de pruebas y casos de prueba).

Echemos un vistazo más de cerca a las "responsabilidades tradicionales de BA" específicas:

  1. Aclaración de errores/análisis de requisitos de errores: los desarrolladores analizan/corregen los tickets de errores creados por los usuarios porque tienen el mayor conocimiento sobre cómo debe comportarse el sistema. Si agrega una capa adicional de análisis de tickets de errores de BA, según mi experiencia, a veces les lleva horas llegar a una aclaración que a menudo ni siquiera es correcta. Porque no conocen el código base. Los desarrolladores deben manejar los errores porque de esta manera también aprovecha el conocimiento y la creatividad de los desarrolladores. A los desarrolladores no se les deben dar "tareas de codificación", sino problemas comerciales. Al igual que las historias de usuario, deben brindar un valor comercial real al cliente del producto.
  2. Recopilación de requisitos para historias de usuarios/características: los desarrolladores trabajan junto con el propietario del producto para comprender los problemas de sus clientes y encontrar soluciones creativas. Hacer encuestas a los clientes, prototipos, etc. es más responsabilidad del PO, mientras que encontrar soluciones para problemas reales de los clientes o características que evaluó como útiles para los clientes es más el trabajo de los desarrolladores. Además, consulte el libro Inspirado por Marty Cagan, que brinda una excelente información sobre cómo trabajar dentro del marco Scrum .

Desde mi experiencia, estas son más del 90 % de las tareas de los BA y el hecho de que los BA se ocupen de estas tareas solo agrega complejidad y ningún beneficio. Tener BA en su equipo suele ser una señal de que (algunos) miembros del equipo no han descubierto los grandes beneficios de aplicar Scrum. Y como dice la guía de Scrum, puede aplicar Scrum al 100% o no. Además, eche un vistazo a las casillas de tiempo de los eventos de Scrum. La planificación del sprint, en la que tradicionalmente encuentra soluciones a los problemas y crea historias de usuarios, puede demorar hasta 8 horas, el más largo de todos los eventos de Scrum. Al mismo tiempo, en realidad, a menudo esta reunión (incluso si agrega reuniones de refinamiento durante el sprint) toma mucho menos tiempo. Esto se debe a que los desarrolladores y PO no toman la tarea de resolver problemas comerciales reales, sino que los BA u otras personas especifican qué "

¿Cómo maneja un equipo Scrum las responsabilidades tradicionales de BA?
RespuestasAquíPolítica de privacidad1y, 0v