¡Estuvimos allí para traerte lo mejor! PAM – Peopleware Agile Management (II)

Continuamos con nuestro resumen del evento PAM - Peopleware Agile Management realizado en La Escuela Técnica Superior de Ingeniería de Sistemas Informáticos de la Universidad Politécnica de Madrid. ¡El Laboratorio de las TI estuvo presente! y hoy seguimos trayendo lo mejor que nos llevamos de allí.

Después del primer café del día y primera sesión de networking, con fuerzas renovadas había que elegir a quién escuchar en directo, porque se realizaban dos ponencias de forma simultánea.

Rocío García Ramos ya había dejado su huella en El Laboratorio a través de la sección 7 Preguntas a... y tenía ganas de escucharla en directo.

El proceso de Design Thinking se basa sobre todo en una predisposición de la persona que toma parte del proceso. La persona que interviene tiene que tener una mentalidad, una actitud especial para poder aprovechar dicho proceso con éxito.
Realmente no es un actitud sino que son 7:

• Muestra, no Cuentes
• Céntrate en las personas
• Claridad
• Experimenta
• Ser consciente del Proceso
• Potencia el hacer sobre el pensar
• Colabora

Rocío en su ponencia nos explicó claramente el proceso seguido en Design Thinking.

• Empatiza
• Define
• Idea
• Prototipa
• Testea

Se trata de un proceso completo, el cliente obtiene un producto más cercano a la realidad que un papel o una presentación.

Diego Romera González de Intelygenz nos explicó su experiencia trabajando de forma ágil con proyectos de desarrollo de software a medida.

La contratación de proyectos llave en mano limita el alcance del desarrollo bajo metodologías ágiles, ya que entre los conocedores del negocio y los equipos de desarrollo hay una trinchera llamada “contrato”. Diego en su presentación expuso como afrontan sus equipos ágiles este reto, ya que el seguimiento del proyecto se realizaba a través de la planificación inicial.

Javier Garzás afrontó uno de los temas más conflictivos del día y sobre el cual, desde mi punto de vista, siguen existiendo más sombras que luces.

Cuando se inicia un proyecto de desarrollo software siempre hay alguien que lanza la pregunta: ¿cúando va a estar terminado?, pero como dice Javier: “Sino está claro qué hay que hacer, porque se descubre según avanza el proyecto, estará poco claro cuándo se va a terminar“.

Aquí encontramos el primer punto de decisión, si los requisitos no están claros ¿por qué empeñarse en desarrollar bajo una metodología predictiva?.

Desde mi punto de vista ¡No tienes que ser ni del Manifiesto Ágil, ni del PMI, ni de SCRUM, ni de PRINCE2, ni ITIL,… tienes que Conseguir el OBJETIVO! Hay que saber cuando utilizar una cosa y cuando otra, que ventajas y que inconvenientes encuentro por uno u otro camino.

¿Tiene sentido utilizar Puntos Función para estimar el tamaño del Product Backlog? ¿Tiene sentido utilizar Puntos Función para estimar el tamaño del Sprint Backlog?
Sí, si utilizamos la palabra estimar (no medir) y añadimos un margen de error a nuestro valor, teniendo en cuenta que los Puntos Función solo miden el tamaño de los requisitos funcionales.

¿Tiene sentido utilizar Puntos Función para estimar/medir el tamaño de una historia de usuario?
Sí se puede pero no tiene sentido. El método de puntos función puede aplicarse sobre una historia de usuario y ofrecer un resultado sobre su tamaño. Pero para valorar correctamente una historia de usuario es necesaria la participación de todo el equipo, tener en cuenta los esfuerzos de desarrollo y los esfuerzos de prueba que no necesariamente están siempre relacionados.

Desde luego este es un tema que abordaremos con más profundidad en futuros artículos en El Laboratorio.

Y casi sin darnos cuenta llegó la hora de la comida para recargar pilas e intercambiar opiniones con los ponentes.