Este documento describe un proyecto para crear un portal web sobre alimentación utilizando la metodología Scrum. Se propone dividir el equipo en tres equipos: un equipo de asesores de alimentación y dos equipos de desarrolladores. Los roles de Product Owner y Scrum Master serían asumidos por el responsable de producto y el responsable de proyecto respectivamente. Cada equipo trabajaría de forma independiente siguiendo el ciclo Scrum, con reuniones diarias y revisiones semanales coordinadas por el Scrum Master.

1. Proyecto: Portal web de alimentación
IEBS Business School
Postgrado en Agile Project & Product Management
Módulo 5: Metodologías

2. Introducción
Para poder trabajar en este proyecto, y dando por supuesto que los
expertos desarrolladores han trabajado antes con SCRUM y el resto
han recibido diversas charlas sobre dicha metodología, propongo
hacer tres grupos donde dos sean heterogéneos para el desarrollo de
software y maquetación del portal web y el otro equipo sea de los
asesores expertos en alimentación.

3. Recursos de los que dispongo
● Un responsable de producto.
● Un responsable de proyecto.
● 3 asesores expertos en alimentación.
● 2 diseñadores/maquetadores expertos en entornos web.
● 7 desarrolladores de software de los cuales 4 son expertos en
entornos web.

4. Transformación de equipos tradicionales a equipos
SCRUM

5. ¿Como reparto los roles PO y SM?
Product Owner → Responsable de producto.
Su objetivo es el mismo, es decir, que el resultado final sea el esperado por el
cliente, con el añadido de que se le vayan facilitando al cliente entregables que
contengan las funcionalidades que más valor ofrezcan al destinatario.
● Deberá recibir formación sobre el papel de PO.
● Scrum Master → Responsable de proyecto.
Acostumbrado a gestionar muchos aspectos a lo largo de un proyecto y de tratar
con equipos , con una formación adecuada de SM , es el perfil que debe
encargarse de asegurar que se cumplen determinadas normas de SCRUM para
que cada rol cumpla con sus responsabilidades.
● Deberá recibir formación sobre el roll de Scrum Master

6. ¿Como reparto en teams al resto de miembros?
● Team 1: Asesores de alimentación
– 3 asesores expertos en alimentación
● Team 2: Desarrolladores
– 1 experto en maquetar entornos web.
– 2 expertos en desarrollo sw.
– 2 desarrolladores sw junior.
● Team 3: Desarrolladores
– 1 experto en maquetar entornos web
– 2 expertos en desarrollo sw.
– 1 desarrollador sw junior

7. Team 1: Asesores sobre alimentación
He considerado que este equipo solo esté formado por expertos
sobre la alimentación para centrar todas las funciones de
asesoramiento en un team que debe estar coordinado
constantemente con el product owner y los otros dos team.
– 2 experto trabajarán apoyando a los team de desarrollo sobre
alimentación.
– 1 experto trabajará apoyando al product owner en la definición de US y
criterios de aceptación.
Anotar que nunca han trabajado con esta metodología pero han
recibido charlas de como usarla. Los primeros sprints serán muy
difíciles pero con ayuda del resto de teams irán mejorando.

8. Team 2 & Team 3: Desarrolladores
Estos dos team son hererogéneos para desarrollar la aplicación a
nivel de sw y a nivel de portal web con asesoramiento sobre
alimentación dado por el team 1.
– 2 expertos en desarrollo sw.
– 1 o 2 junior en desarrollo sw que aprenderá con ayuda de los expertos.
– 1 experto en maquetar entornos web.
Anotar que los expertos desarrolladores han participado
anteriormente en equipos de desarrollo usando la metodología
SCRUM, así que será una buena ayuda para los desarrolladores
junior y los expertos de maquetación que no tienen experiencia en
esta metodología.

9. Flujo de comunicación entre los implicados en el proyecto.
Scrum
master
Product
Owner
Team 3: 4 miembros
2 desarrolladores expertos
1 desarrollador junior
1 maquetador entornos web
Team 2: 5 miembros
2 desarrolladores expertos
2 desarrollador junior
1 maquetador entornos web
Team 1: 3 miembros
3 asesores alimentación
(1 asesorando al PO y
los otros dos asesorando
a los dos teams)

10. Funcionamiento del ciclo del proyecto (SCRUM)
El funcionamiento sería el mismo que describe la metodología, salvo que hay 3 equipos con el mismo P.O. y S.M.
Cada equipo trabaja sobre su propia SCRUM BOARD: historias, tareas, progresos...
Mecánica de trabajo:
SPRINT Planning:
● Team 2 & 3 participará (por separado) con el SM en su reunión de SPRINT PLANNING.
● Cada team seleccionará la historia a desarrollar según prioridad del sprint backlog del PO.
● Se distribuirán las tareas dentro de cada historia como el team estime necesario.
Daily Scrum;
● Los team 2 & 3 harán las reuniones conjuntas para ver los avances o posibles bloqueos ya que
sus funciones son similares.
● El team 1 deberá hacer la reunión posteriormente para que el SM pueda asistir tras recibir
feedback de los team 2 y 3.
Sprint Review:
● Los tres team participarán en la demo de las funcionalidades realizadas en el sprint.
Sprint Retrospecitve:
● Cada team por separado verá los puntos fuertes y débiles del equipo y de la metodología a lo
largo del sprint.

11. Diagrama de flujo del proyecto
Product Backlog
Sprint Backlog
¿Que historias van
a estar en este sprint?
¿Como de
completas son?
Scrum Board
de cada Team
(only US)
Sprint planning
Team 2
PO
SM
SPRINT N (entre 2 y 4 semanas)
Scrum Board
de cada Team
(Added Tasks
each team)Team 3
Daily meeting
¿Como vamos?
Team 1Team 2&3
Sprint Review
Drop n
Team
1&2&3SM PO
Retrospectiva
Team 1 Team 3Team 2
SMPO
Team 1
Team3
PO
Team 2

12. APENDICE 1
● He considerado separar al team de asesores en alimentación por la
similitud del team de arquitectura que tenemos nosotros en nuestro
departamento que nos ayuda al resto de team de desarrollo a tomar
decisiones en implementaciones. Además considero que al menos un
experto deberá estar coordinado con el PO para asesorarle en la definición
de las US y sus criterios de aceptación.
● Las retrospectivas las prefiero realizar por separado por posibles
problemas entre los teams. Mientras no exista una confianza entre ellos, lo
suficientemente grande, mejor hacerlas separadas y que el SM tome nota
de los puntos positivos, a mejorar, incluso si hay conflictos entre los
diferentes teams.