Todas las personas que intervienen, o tienen relación directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En círculos de Scrum es frecuente llamar a los primeros (sin la menor connotación peyorativa) “cerdos” y a los segundos “gallinas”.
Todas las personas que intervienen, o tienen relación directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En círculos de Scrum es frecuente llamar a los primeros (sin la menor connotación peyorativa) “cerdos” y a los segundos “gallinas”.
El origen de estos nombres está en la siguiente metáfora que ilustra de forma gráfica la diferencia entre “compromiso” e “implicación” con el proyecto:
El origen de estos nombres está en la siguiente metáfora que ilustra de forma gráfica la diferencia entre “compromiso” e “implicación” con el proyecto:
Line 10:
Line 19:
[[File:Comprometidos implicados.png|center]]
[[File:Comprometidos implicados.png|center]]
*Propietario del producto: es la persona respo¬nsable de lograr el mayor valor de producto para los clientes, usuarios y resto de implicados.
*Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.
Una observación en este punto, sobre el rol de scrum Master, por ser en ocasiones frecuente la duda de considerar si es un rol “comprometido” o “implicado”. Partiendo de que la división entre personas comprometidas y personas implicadas es más “conceptual” que “relevante”, lo cierto es que en las organizaciones en las que se emplea, el rol de Scrum Master, tiene su responsabilidad directa en el funcionamiento del marco Scrum en la organización. Su objetivo de responsabilidad directa es la mejora de la organización y la mejora o resultado de los proyectos es por tanto un objetivo o resultado indirecto a través de la mejora de la organización.
Por esta razón en el cuadro anterior no se considera el rol de Scrum Master, considerando, que en cualquier caso no es una cuestión especialmente relevante. Si hubiera que forzar una respuesta, desde el criterio de que no está comprometido en el proyecto (sino en la mejora de la organización) se debería considerar como un rol "implicado"
==Valores==
El marco estándar de Scrum es la “carrocería” de un vehículo que se asienta y tiene su motor en los principios ágiles. Es una ayuda para organizar a las personas y el flujo de trabajo, como lo pueden ser otras propuestas de formas de trabajo ágil: Crystal, DSDM, otros.
La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil no funciona, y éstos son:
*Delegación de atribuciones (empowerment) al equipo para que pueda autoorganizarse y tomar las decisiones sobre el desarrollo.
*Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
*Responsabilidad y autodisciplina (no disciplina impuesta).
*Trabajo centrado en el valor para el cliente y el desarrollo de lo comprometido.
*Información, transparencia y visibilidad del desarrollo del proyecto.
==El propietario del producto==
El propietario del producto o product owner es quien toma las decisiones del cliente.
Para simplificar la comunicación y toma de decisiones es necesario que las responsabilidades de gestión del producto las asuma una única persona.
Si el cliente es una organización grande, o con varios departamentos, puede adoptar la forma de comunicación interna que consideren oportuna, pero en el equipo de desarrollo sólo se integra una persona en representación del cliente, y ésta debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden.
En resumen, el propietario de producto es quien:
*Decide en última instancia cómo será el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qué se pone y qué se quita de la pila del producto, y cuál es la prioridad de las funcionalidades.
Se responsabiliza de la financiación del proyecto, y las decisiones sobre fechas y funcionalidades de las diferentes versiones del producto, y conoce las posibilidades y plan de inversión, así como el retorno esperado de la inversión del proyecto.
En los desarrollos internos para la propia empresa, suele asumir este rol el product manager o el responsable de marketing. En desarrollos para clientes externos: el responsable del proceso de adquisición del cliente.
Para ejercer este rol es necesario:
*Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se está construyendo.
*Tener la visión del producto, así como las necesidades concretas del proyecto, para poder priorizar eficientemente el trabajo.
*Disponer de atribuciones suficientes para tomar las decisiones necesarias durante el proyecto, incluidas para cubrir las expectativas previstas de retorno de la Inversión del proyecto.
*Recibir y analizar de forma continua retroinformación del entorno de negocio (evolución del mercado, competencia, alternativas) y del proyecto (sugerencias del equipo, alternativas técnicas, pruebas y evaluación de cada incremento).
Es además recomendable que el propietario de producto:
*Conozca Scrum para realizar con solvencia las tareas que le corresponden:
**Desarrollo y administración de la pila del producto.
**Exposición de la visión e historias de usuario, y participación en la reunión de planificación de cada sprint.
*Conozca y haya trabajado previamente con el mismo equipo.
==El equipo==
Se recomienda que los equipos que trabajan con Scrum tengan entre 4 y 8 personas. Más allá de 8 resulta más difícil mantener la agilidad en la comunicación directa, y se manifiestan con más intensidad las rigideces habituales de la dinámica de grupos (que comienzan a aparecer a partir de 6 personas).
No se trata de un grupo de trabajo formado por un arquitecto, diseñador o analista, programadores y testers. Es un equipo multidisciplinario, en el que todos los componentes trabajan de forma solidaria con responsabilidad compartida
Las principales responsabilidades, más allá de la autoorganización y uso de tecnologías ágiles, son las que se marcan la diferencia entre “grupo de trabajo” y “equipo”.
Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde por su trabajo.
El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.
Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y autoorganizada. No hay un gestor para delimitar, asignar y coordinar las tareas. Son los propios miembros del equipo los que lo realizan.
En el equipo:
*Todos conocen y comprenden la visión del propietario del producto.
*Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto.
*Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
*Todos los miembros participan en las decisiones.
*Se respetan las opiniones y aportes de todos.
*Todos conocen el modelo de trabajo con Scrum.
==Scrum Master==
Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos que la organización necesite según el conocimiento y experiencia con el modelo: Asesoría y formación al propietario del producto.
*Asesoría y formación al equipo.
Una observación en este punto, sobre el rol de Scrum Master, por ser en ocasiones frecuente la duda de considerar si es un rol “comprometido” o “implicado”. Partiendo de que la división entre personas comprometidas y personas implicadas es más “conceptual” que “relevante”, pero cuando se trabaja con este rol presente, su responsabilidad es el funcionamiento de un scrum técnico en la organización.
*Revisión y validación de la pila del producto.
Su responsabilidad directa, su misión, es por tanto la forma de trabajo, siendo por tanto el producto elaborado en los proyectos un objetivo de segundo nivel, o indirecto.
*Moderación de las reuniones.
Por esta razón en el cuadro anterior no se considera el rol de Scrum Master, aunque que en cualquier caso no es una cuestión especialmente relevante. Si hubiera que forzar una respuesta, desde el criterio de que no está comprometido en el proyecto (sino en la mejora de la forma de trabajo) se debería considerar como un rol "implicado"
*Resolución de impedimentos que en el sprint pueden entorpecer la ejecución de las tareas.
*Gestión de las “dinámicas de grupo” en el equipo.
*Configuración, diseño y mejora continua de las prácticas de Scrum en la organización. Respeto de la organización y los implicados, con las pautas de tiempos y formas de Scrum.
En implementaciones no estándar o académicas, basadas en responsabilidades (no en roles) es habitual no contar con un rol específico de Scrum Master, y la garantía de funcionamiento de Scrum las funciones propias del scrum Master las suele asumir un puesto específico para contar con esta garantía (Team Leader o Gestor Ágil).
Todas las personas que intervienen, o tienen relación directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En círculos de Scrum es frecuente llamar a los primeros (sin la menor connotación peyorativa) “cerdos” y a los segundos “gallinas”.
El origen de estos nombres está en la siguiente metáfora que ilustra de forma gráfica la diferencia entre “compromiso” e “implicación” con el proyecto:
Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al cerdo: “¿Quieres abrir un restaurante conmigo?”.
El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”.
La gallina respondió: “Jamón con huevos”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada”.
Una observación en este punto, sobre el rol de Scrum Master, por ser en ocasiones frecuente la duda de considerar si es un rol “comprometido” o “implicado”. Partiendo de que la división entre personas comprometidas y personas implicadas es más “conceptual” que “relevante”, pero cuando se trabaja con este rol presente, su responsabilidad es el funcionamiento de un scrum técnico en la organización.
Su responsabilidad directa, su misión, es por tanto la forma de trabajo, siendo por tanto el producto elaborado en los proyectos un objetivo de segundo nivel, o indirecto.
Por esta razón en el cuadro anterior no se considera el rol de Scrum Master, aunque que en cualquier caso no es una cuestión especialmente relevante. Si hubiera que forzar una respuesta, desde el criterio de que no está comprometido en el proyecto (sino en la mejora de la forma de trabajo) se debería considerar como un rol "implicado"
