Sigo leyendo que durante la preparación de la cartera de productos, el equipo de desarrollo se reúne con el PM y el propietario del producto y, como equipo, prioriza las características.
¿Es en última instancia el propietario del producto quien decide la prioridad (en qué se debe trabajar y lanzar primero)?
¿Dónde entra el Business Analyst en esto? Pensé que era el trabajo del BA construir relaciones con las partes interesadas del negocio, conocer la visión, conocer las necesidades de los clientes y trabajar con el negocio para determinar la prioridad y los requisitos.
¿Alguien puede aclarar, gracias!
Business Analyst trabaja con el propietario del producto y le brinda información valiosa sobre el valor y la importancia de las historias de usuario, pero el PO sigue siendo la persona que establece la prioridad del trabajo pendiente. Lo mismo se aplica a la participación del Equipo. Los miembros del equipo brindan información utilizable a nivel técnico a la OP y la OP debe poder comprender esta información y usarla al priorizar la acumulación.
La respuesta directa es que el propietario del producto prioriza la acumulación. Es, por supuesto, un poco más matizado que eso. En un mundo ideal, el PO simplemente clasificaría los elementos pendientes por esfuerzo y valor para crear su prioridad, y eso es lo que suele suceder al principio. Sin embargo, el equipo proporcionará mucha información sobre cómo el pedido seleccionado afecta su capacidad para entregar incrementos de productos. Por ejemplo, el equipo puede decir que poner un elemento delante de otro les permite entregarlos con menos esfuerzo general.
El analista de negocios está en una posición interesante. Notará que no hay un rol de BA en scrum. La función tradicional de BA se extiende tanto a la función de OP cuando se trata de involucrar a las partes interesadas e identificar el trabajo que debe realizarse, como también se extiende a la función de equipo cuando se trata de profundizar en los detalles técnicos, el diseño de la base de datos y la pantalla, y otras implementaciones. detalles específicos. El enfoque de scrum puro diría que debe elegir ser el PO o un miembro del equipo y luego seguir ese rol, pero con muchos equipos comenzando, eso no es posible ni práctico por varias razones. Si continúa ocupando un puesto de BA que se extiende a ambos roles, le haría dos sugerencias:
1) Sepa qué sombrero está usando en cada momento y use solo uno. Por ejemplo, si está tratando de preparar algunas historias de usuarios para el refinamiento de la cartera de pedidos, está usando su sombrero de PO, así que tenga cuidado de no entrar en detalles de implementación. En primer lugar, tendrá verdaderos problemas para mantener el trabajo pendiente por delante del equipo y, en segundo lugar, quitará la solución de las manos del equipo, lo que reducirá su propiedad del trabajo y su sentido de la responsabilidad. Del mismo modo, si está trabajando en el diseño o la creación del software, mantenga el sombrero de su equipo puesto. Cambiar de nuevo a PO sin querer envía un mensaje al equipo de que sus pensamientos superan los de ellos y, nuevamente, pierde su propiedad (la excepción obvia es si el equipo le hace una pregunta de PO).
2) Tradicionalmente, se espera que el BA en proyectos lleve el análisis y el diseño mucho más allá de lo que requiere Scrum. Todo el equipo debe diseñar y crear la implementación de la historia de usuario. En muchos casos, usted puede ser la persona que lo haga, pero el equipo en su conjunto debe ser el dueño y, si no tiene tiempo, otros miembros del equipo deben intervenir. El equipo de desarrollo nunca debe presionarlo y decir que no puedes trabajar en algo porque no has terminado los detalles del diseño.
La respuesta es Sí, No, Depende, de una manera verdaderamente ágil. :)
Así que he tenido suerte o mala suerte según sea el caso y nunca he trabajado en una empresa con el rol de Business Analyst. Entonces no puedo comentar sobre la respuesta de Zsolt.
Lo que sí sé es que en la comunidad ágil estamos viendo cada vez más el concepto del Product Owner Team . Y el concepto de lo que llamo Pyramid Planning sigue siendo muy válido en ágil.
Planificación piramidal: La idea de varias etapas de planificación con mayores niveles de detalle. El modelo ágil a gran escala, SAFe, utiliza esto ampliamente. Al más alto nivel, la priorización la realiza un equipo comercial/estratégico. En mi compañía actual (AOL) usamos esto regularmente. A medida que se acerca al trabajo de desarrollo real, las personas involucradas en la planificación específica cambian. Los vicepresidentes y ejecutivos deciden las cuatro grandes cosas que se harán este año, el equipo decidirá qué se hará para la iteración el próximo mes. Lo que nos lleva a la idea de...
Equipo de propietarios de productos: después de haber sido gerente de productos, en una vida anterior, puedo decir sin lugar a dudas que pocos gerentes de productos, si es que hay alguno, pueden tomar todas las decisiones por sí mismos. Por lo general, son poco más que el vaquero que intenta desesperadamente agarrar al caballo que corcovea y guiarlo en la dirección correcta. El equipo de propietarios de productos (POT)lo reconoce y lo formaliza. El POT está compuesto por las personas clave que pueden proporcionar al PO todos los datos para tomar una decisión informada. Un POT a menudo tendrá, además del PO, un arquitecto, un representante del equipo de desarrollo, Ops/IT, atención al cliente y BA si la empresa los tiene. Como equipo, revisarán las Historias de usuarios y las priorizarán en función de la imagen completa, no solo de una visión comercial limitada que a menudo sucede si un Gerente de Producto intenta trabajar en el vacío.
Y es importante tener en cuenta que siempre debe comprometerse con el equipo para obtener al menos una estimación de alto nivel para el nivel de esfuerzo. Usted, el propietario del producto, puede pensar que teletransportarse a los automóviles es la función más importante que existe. Y puede que tenga razón, solo el equipo de desarrollo le dirá que no importa cuán valioso sea, tomará 100 veces más que fabricar un nuevo automóvil autónomo. Siempre debe tener en cuenta el tiempo en su priorización y solo el equipo puede darle una estimación realista.
En un equipo de scrum tradicional, el propietario del producto es responsable de garantizar que se priorice el trabajo pendiente. No hay un rol de BA en un equipo de scrum puro.
El equipo es responsable de garantizar que todos entiendan y estén de acuerdo en que las prioridades son correctas.
El equipo y el PO juntos son responsables de priorizar el trabajo pendiente.
En realidad, hay BA's. Lo importante es que todo el equipo esté de acuerdo y entienda quién es responsable (se asegura de que se haga) para asegurarse de que se priorice el trabajo pendiente frente a quién es responsable (lo hace).
Hay equipos donde el BA es responsable y en combinación con el resto del equipo responsable. Hay equipos en los que el BA solo es responsable y el PO aún debe rendir cuentas. Depende de su organización y de lo que funcione mejor para su equipo.
Desea evitar situaciones en las que 1 persona sea responsable, ya que la priorización es un problema complejo que se beneficia de tener numerosos ojos/cerebros para garantizar una prioridad óptima.
¡Algunas respuestas realmente excelentes aquí!
Como estamos hablando de propietarios de productos, voy a asumir Scrum, me gustaría agregar un enlace: Guía Scrum de la alianza Scrum.
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next;
- Ensuring the Development Team understands items in the Product
Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it.
However, the Product Owner remains accountable.
Como esto indica, el propietario del producto PUEDE hacer que el equipo de desarrollo haga este trabajo. Pero el propietario del producto es responsable: este es el factor importante: la responsabilidad.
Depende del proceso elegido para ese proyecto.
En Scrum real, el propietario del producto es el que prioriza la acumulación de productos. Sin embargo, es el Equipo de Desarrollo el que decide cuántas de las historias priorizadas puede incluir en el próximo Sprint.
Por lo general, eso sucedería en la primera sesión de Sprint Planning, cuando el PO presenta su elección de historias para el Sprint. Luego, el equipo de desarrollo estima y renegocia, si es necesario, el orden y la cantidad de historias en las que acuerda trabajar en ese mismo Sprint.
Por lo tanto, es el PO el que prioriza, pero es el equipo de desarrollo el que tiene la última palabra sobre lo que sucede en la acumulación de sprints.
El PO y el equipo de desarrollo se reúnen y discuten. PO presenta el orden de todas las historias en la cartera de productos que quiere ver en el próximo Sprint. Equipo de desarrollo
PO & Dev.Team han acordado el número y el orden de las historias en las que se trabajará durante el sprint (han definido el Sprint Backlog). El Dev.Team decide cómo trabajar en cada historia. En ese momento ya no necesitan el PO en la reunión.
Realmente no importa quién prioriza el trabajo pendiente. Lo que realmente importa es cómo se hace eso: analizando el riesgo, el beneficio y el impacto de cada mejora. El papel real de la persona que hace este análisis es de importancia secundaria en el proceso.
jason.t.knight