LUGAR DE ENCUENTRO
Ciudad: Valladolid
Hora: Desde 19:30 a 21:00
Punto de encuentro: Cafetería Zeus
- C/ Estadio, 2 (esquina c/ Las Mercedes) 47006 Valladolid
OBJETIVOS
- Conocer cómo aplicar SCRUM y los problemas diarios de su empleo.
- Compartir experiencias propias y trucos para salir adelante.
- Actualizar la lista de temas a tratar.
REQUISITOS
Ninguno, ganas de conocer cómo es el trabajo diario y los problemas de usar metodologías ágiles, concretamente el marco de trabajo SCRUM.
AGENDA
- Presentaciones individuales
- Debate “Dificultades del día a día en la aplicación de Scrum” (promovida por Jezabel González)
- Retrospectiva de la reunión.
ASISTENTES
- Jorge Jiménez Pérez
- Amalia Hernández García
- Jezabel González
- Isidro Merayo Castellano
- Eduardo Ferrández
- Olivier Salmon
- Susana Mielgo
- Susana
- Ignacio Cruzado (1ª vez)
- Jose Antonio Da Rocha (1ª vez)
RESUMEN
Como es habitual la reunión comenzó con la presentación de cada uno y su relación con las metodologías ágiles. En esta ocasión contamos con tres nuevos componentes del grupo que acudían por primera vez a nuestros encuentros ágiles.
Empezamos la charla preguntando por problemas que tenemos o casos que nos hemos encontrado y tratando esos temas para ver cómo entre todos llegábamos a algún tipo de conclusión.
Rol del Cliente - Product Owner
Nos encontramos con este caso en la mayoría de las situaciones, una de las herencias de tantos años de waterfallismo. El cliente no quiere conocer nada de metodologías ágiles y sólo espera tener el proyecto en las fechas concretadas en el contrato.
En este caso no contamos con un product owner proporcionado por la empresa cliente, de manera que en la mayoría de los casos en las metodologías ágiles este rol lo asume una persona de la empresa que desarrolla el proyecto. Normalmente el papel lo toma el jefe de proyecto que es el mas cercano al cliente y el que debe saber las necesidades del mismo para darle soluciones y ponerse en su papel. En caso de dudas siempre estará cercano al cliente para completar la información que le falte. Otra persona que puede asumir este rol es el consultor por el conocimiento que tiene del negocio para el que se desarrolla el producto.
Al final seguimos escondiendo la metodología ágil ante clientes con los que no tenemos confianza o seguridad para ser claros. Es algo que con el tiempo se debe superar, quizás explicando claramente las ventajas que para el cliente puede tener el desarrollar proyectos con estas metodologías, con un mayor conocimiento del trabajo desarrollado en ciclos más continuos y cortos.
Siempre se puede traer al cliente a estas metodologías sin necesidad de darles un nombre, porque al final nadie se opondrá en ver en qué invierte su dinero, o en aclarar cualquier duda en las reuniones de seguimiento de proyecto. Esto escuchado por un cliente “prefiero saber lo que se hace día a día o semana a semana que no esperar 3 meses y ver lo que se me entrega, teniendo la fecha de cierre de proyecto más cercana y sin tiempo de rectificación”.
Si el cliente está al alcance del equipo, involucrarle en los artefactos de scrum, tanto spring meeting como en la demo al final del sprint.
Es fundamental la comunicación entre product owner y equipo.
La priorización de tareas es fundamental que sea realizada por el cliente y no sustituido por otra persona. Hacerlo mal podría equivocar las prioridades del cliente y dar un resultado poco interesante para el cliente final cuando ejecute la demo del producto. Hay que aportar valor en cada iteración según las necesidades del cliente: dar más valor en las primeras iteraciones para aumentar el ROI del cliente.
Una persona desplazada en cliente puede asumir el rol de producto owner al tener conocimiento de lo que se necesita, sería una solución a la falta de involucración del cliente.
Hay una opinión generalizada de que no se pude tener al cliente de manera continua en contacto con el cliente o en todas las demos. Hoy en día hay solución para este problema, utilizando herramientas remotas como Skype o videoconferencia.
Estimaciones
Para realizar las estimaciones hubo un criterio casi general: estimar sólo por tareas extraídas de las historias de usuario, eso marca cuántas historias pueden meterse en el sprint. No hacerlo desde el punto de vista de estimación las historias del product backlog y una vez que se sepan las historias que entran en el sprint estimar sus tareas. Según se dijo era más fácil y a largo plazo se estima mejor que a corto plazo.
¿Qué hacer ante proyectos a precio cerrado? En este caso es complicado hacer estimaciones ya que siempre hay que terminar en un tiempo fijo para compensar los costes del proyecto. Puede que la estimación real te lleve a más tiempo que la estimación ideal realizada en preventa. Hay que intentar huir de ese tipo de proyectos
Existe un problema en las metodologías ágiles, donde parece que se está trabajando por complacer al cliente y esto puede provocar que haya clientes que se tomen “barra libre”. Hay que fijar claramente al inicio del proyecto su alcance, y para ello será necesario un documento donde estén reflejados los requerimientos del sistema pedido por el cliente.
Incidencias en un Sprint
Se aclara que Scrum no se ajusta a trabajar en mantenimiento de productos, al aparecer tareas nuevas a lo largo del sprint que hay que solventar en cuanto aparecen.
Estas tareas-incidencias son asumidas por el equipo y dependiendo de la importancia de la incidencia se ataca inmediatamente o se postpone para el sprint siguiente.
Siempre se deja un colchón al final del sprint por si no se llega para poder tener tiempo y solucionar este tipo de tareas emergentes.
Sprint Meeting
Las estimaciones se realizan mediante planning poker, siguiendo la serie de Fibonacci, pero siempre hay un vicio en estimar lo que uno terminaría, no lo que cualquiera del equipo podría tardar.
Si no hay claridad en la definición de la historia las estimaciones sufrirán.
Si dura mucho el sprint meeting y se sale del timeboxing fijado es un coste muy elevado para el proyecto. No discutir soluciones técnicas.
Daily Meeting
Se habló de la dificultad de trabajar en Scrum con equipos distribuidos pero los casos reales que se explicaron reflejan que no hay impedimentos la usar herramientas como IM o Skype para las reuniones de equipos, manteniendo una reunión dentro del sprint con presencia física de todos los componentes del proyecto
Conflictos personales
¿Qué pasa cuando el cliente pide sacar a alguien del equipo o desde la propia empresa se saca a gente del proyecto?
Es un problema que hay que resolver intentando mantener en lo posible al equipo mediante intento de negociación. Si hace tiempo hubo un problema con alguien hay que dar la oportunidad nuevamente por si ha cambiado y puede ser ahora importante para la resolución del proyecto.
Lo normal es lo contrario, es pedir que alguien en concreto se incorpore al equipo por el conocimiento y experiencia que puede aportar.
Hay que luchar con las gerencias para el mantenimiento de los equipos y que no se modifique su composición durante un proyecto o por lo menos durante un sprint, aunque el movimiento de personas en nuestro sector es muy común y es complicado hacer equipos estables.
La charla derivó a discusiones sobre técnicas de integración contínua, ramas, tags y desarrollo por features o por desarrollador que quedan fuera de este encuentro.
