En los proyectos más tradicionales en los que he trabajado, el gerente del proyecto (y, en proyectos más grandes, puede haber gerentes de proyecto asociados / adjuntos / asistentes si una persona no está disponible) es la persona responsable de comunicarse con el cliente y recibir el proyecto. actualizaciones de estado y salud, determinando la programación y el presupuesto, administrando el proceso, asegurando que el equipo tenga lo que necesitan para completar las tareas, etc.
Sin embargo, en Scrum, estas responsabilidades se dividen entre el propietario del producto y el ScrumMaster. El propietario del producto es la voz del cliente. Interactúan directamente con el cliente, crean historias de usuarios, organizan y priorizan la acumulación de productos y otros problemas que enfrentan los usuarios / clientes. ScrumMaster maneja el proceso, supervisa las reuniones (incluida la estimación y planificación), elimina los impedimentos y supervisa el estado general del proyecto, haciendo los ajustes necesarios.
He leído en múltiples fuentes, incluida Wikipedia , que el papel de ScrumMaster y Product Owner debe ser desempeñado por dos personas diferentes. No solo leí sobre, sino que trabajé en proyectos exitosos de estilo "tradicional" donde las actividades de ambos eran manejadas por un solo individuo. De hecho, tiene más sentido que una o tres personas sean responsables del manejo del proyecto (incluyendo recursos humanos / personal) y tareas de nivel de proceso, ya que a menudo van de la mano. Los cambios en el proceso tienen un impacto en la programación, el presupuesto, la calidad y otras metas a nivel de proyecto, y los cambios del proyecto tienen un impacto en el proceso.
¿Por qué Scrum llama a aislar estas actividades en dos roles? ¿Qué ventajas ofrece esto realmente? ¿Alguien ha estado en un proyecto Scrum exitoso donde el propietario del producto y ScrumMaster fueran la misma persona?
fuente
Respuestas:
Pueden (y a menudo son) combinadas y realizadas por una sola persona (no hay ninguna regla en contra de esto (su scrum después de todo)).
PERO debe equilibrar la responsabilidad de la diferencia con cuidado ya que los dos roles tienen competencias y agendas (y se necesita una persona especial para poder hacer ambas cosas simultáneamente). He visto muchos intentos, pero pocos lo logran durante un largo período de tiempo (es una posición estresante).
Para ser el SM, necesita más conocimiento técnico que el PO (ya que ayudará a organizar el equipo de desarrollo). Se necesita un conocimiento detallado del producto para poder extraer elementos de la cartera de pedidos del producto en la cartera de pedidos de primavera (a veces simplemente no puede extraer los elementos 'n' superiores, ya que esto puede ser contraproducente).
El PO requiere una mayor comprensión del usuario final de la ecuación que ellos SM. No es necesario que sea tan técnico, pero sí requiere conocimiento de cómo se utilizará el producto en el mundo real y la dirección en que el cliente quiere tomar el producto.
Si puede encontrar una persona que pueda hacer ambos roles, entonces no veo ninguna razón para evitar esto.
Pueden surgir problemas cuando el cliente está tirando de la orden de compra en una dirección que está causando conflictos importantes a los desarrolladores (porque primero necesitan construir otra infraestructura). El trabajo de SM no es seguir los caprichos del cliente, sino proteger a los desarrolladores de sus caprichos. Lograr esto objetivamente es difícil.
fuente
No soy un experto, pero creo que el Scrum Master debería ser el defensor / facilitador del equipo. La voz del cliente debe tener los intereses del cliente en el corazón. El Scrum Master debe ayudar a que el equipo obtenga lo que necesita para tener un sprint exitoso.
fuente
Además, tenga en cuenta la mayoría de las veces, no está trabajando en 1 cliente a la vez. Los propietarios de productos pueden administrar varios clientes y pueden concentrarse en esa parte del negocio, y ScrumMasters pueden concentrarse en el desarrollo de proyectos.
Como muchos han dicho, ambos roles tienen intereses distintos, pero un objetivo común y diferentes habilidades para adquirirlo.
fuente
Si la misma persona representa al equipo de desarrollo y a los usuarios / clientes, el único recurso que tiene en una disputa es mirar el contrato. Aunque eventualmente puede llegar a esto, es mejor que un representante de ambos lados con el mismo poder pueda llegar a un acuerdo.
fuente
Las personas en los roles de Propietario del producto y Scrum Master pueden tener deseos, objetivos, requisitos y limitaciones en conflicto, más de 2 programadores aleatorios. Los seres humanos pueden o no ser capaces de valorar igualmente los objetivos en conflicto, y es más probable que cometan errores de juicio cuando se enfrentan a objetivos en conflicto. Dos personas con enfoques o sesgos ligeramente diferentes pueden ser menos propensos a cometer juntos los mismos errores o el mismo grado de errores de juicio.
Dos personas también pueden asignar más horas-hombre totales para enfocarse en cada aspecto diferente del problema / proyecto (por ejemplo, los objetivos de los 2 roles diferentes).
fuente