Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Experiencias Ágiles personales 1 de n

0 comments
Experiencias Ágiles personales 1 de n

Esta vez , os traigo una nueva experiencia Ágil de la mano de Javier. Recientemente se ofreció a colaborar en este blog para explicarnos como aplica Agil en su dia a día.

Os extrañará la imagen asociada al artículo:  un paisaje y os preguntaréis . ¿ qué tiene que ver esto con lo que el post describe?. La respuesta es NADA, pero prefiero no perder el tiempo buscando fotos que tengan que ver o retocando con el Photoshop (  que me cuesta un montón… otra cosa por aprender … ) y publicar directamente y cuanto antes, pues… Lo que importa es el contenido . ¿ No?.  Y cuando se me acaben los paisajes, pues pondré “animales” :)   por ejemplo.

Sin más preámbulos, y dando por antemano las gracias a Javier, aqui van sus experiencias que es lo verdaderamente importante de este artículo. Y a ver si la “n” del nombre del post, va creciendo si me mandáis nuevas experiencias. 😉

 1.- ¿Desde qué fecha empleas un modelo Ágil de desarrollo de SW en tus proyectos?

Actualmente estamos inmersos en un proceso de mejora pasando de metodologías tradicionales a metodologías Ágiles por lo que mi experiencia es de aproximadamente 11 meses.

2.- ¿Cuáles son las barreras de entrada más importantes que te has encontrado al aplicar un modelo Ágil en los proyectos?

Creo que el cambio de mentalidad. Estamos acostumbrados a trabajar en modelos tradicionales donde el calendario del proyecto prácticamente está cerrado de antemano. Pasar de esto a uno basado en entregas a corto plazo definidas en Sprints de corta duración creo que es la principal barrera.

Cuántas veces he oído la frase de, pero donde está el diagrama de Gantt con todas las funcionalidades del proyecto y la fecha en la que finaliza cada una de ellas y por supuesto que incluya la fecha fin proyecto, y todo esto sin ni siquiera poder tener una valoración temprana de las funcionalidades a realizar. Pensamos que dando una fecha sin saber realmente lo que hay que hacer con un grado de incertidumbre enorme es mejor que tener una fecha realista de entregas basado en las funcionalidades incluidas en los Sprints.

3.-¿Qué modelo / metodología estás usando?

 Actualmente estoy utilizando Kanban y Scrum en fase piloto.

4.- ¿en cuántos proyectos se está usando el modelo y de qué manera?

  Actualmente estoy involucrado directamente en dos de ellos.

5.- ¿Cuántos equipos lo usan y cuantas personas de media los forman?. ¿son equipos internos, externos, mixtos ?

Actualmente hay varios equipos involucrados de distinta índole y tamaño, pero podemos decir que la media de los equipos rondan las 5 personas y están compuestos por equipos mixtos.

6.- ¿Usas tablero físico de tareas , virtual , los dos?. ¿Qué herramientas usas? 

Para todos los proyectos involucrados en la metodología ágil utilizamos tableros físicos. Lo que está claro es que al final todo esto es importante, pero más importante es poder medir tiempos y sacar métricas para poder realizar acciones de mejora o para poder detectar problemas tales como cuellos de botella. En mi caso no he utilizado ninguna herramienta con un tablero virtual para poder medir, ya que de los sistemas actuales puedo recuperar dicha información. La trazabilidad de la tarjeta física con los datos en los sistemas se realiza a través de la identificación única para cada una de las peticiones de los usuarios, en definitiva un número único para cada CR. El tablero físico es una foto del estado de dicha CR en nuestros sistemas.

7.- ¿Qué prácticas/procesos  de la metodología que usas encuentras más útiles y son más aceptadas por el equipo?

Daily scrum y retrospectivas, en definitiva todas aquellas que dan al equipo visibilidad sobre la marcha del proyecto.

8.- Para el seguimiento del grado de avance de los pytos: ¿qué técnica empleas?-

Aquí tengo dos tipos de seguimiento claramente diferenciado, uno enfocado al equipo de desarrollo y otro orientado a otro tipo de perfiles como es la dirección o las áreas de negocio.

En el caso de los equipos de desarrollo todas las mañanas se realiza la reunión de daily scrum donde se revisa en qué estado se encuentra el tablero a día de hoy, hay una revisión de las tareas que se tenían que haber realizado en el día anterior y su estado actual, se revisan las tareas que realizará cada uno de los miembros del equipo (compromisos) durante el día, se revisan los problemas encontrados y cuáles de ellos son bloqueantes respecto al avance de las funcionalidades en el tablero y para finalizar vemos como vamos con el Sprint y a donde apuntamos, es decir, cuanta desviación tenemos respecto al compromiso para decidir qué medidas tomar, para esto utilizamos la gráfica de Burn-down donde se ve de una forma visual y clara hacia dónde vamos.

En el caso de los reportes a la dirección utilizo la técnica del valor ganado (EV), en mi caso la utilizo tanto a nivel de funcionalidades como a nivel de presupuesto del proyecto dependiendo de las características de cada proyecto utilizo una u otra.

9.- ¿Cómo reportas a la Dirección?

Para el reporte a la dirección tengo reuniones quincenales donde se revisa el avance del proyecto a nivel de CRs o peticiones de usuario (Funcionalidades) asociadas a un proyecto en concreto. Aparte de revisar cómo estamos a día de hoy se revisa a donde apunta el proyecto a nivel global, en este caso me olvido de los Sprints y me centro en realizar una extrapolación en base al esfuerzo realizado hasta el momento.

 Burnup Chart

  Gráfico de Burn-Up.

 La línea morada representa el número de funcionalidades que tiene el proyecto. En este caso vemos que el número de Funcionalidades va cambiando conforme avanza el proyecto por lo que la fecha fin  prevista va variando en función de las Funcionalidades que van entrando o saliendo del mismo. Esto es porque se trabaja cambiando a la vez que creamos. La línea verde representael discurrir ideal,  optimo del proyecto, es decir, alcanzaría el total de Funcionalidades migradas en diciembre de este año, pero sin embargo, la realidad es distinta y la línea azul que representa lo que está instalado en  producción, nos indica que nos hará falta parte del año que viene para terminar el proyecto ya que apuntamos a tener 158 funcionalidades en producción al final de año. En Octubre tenemos un Valor  Ganado de 132 funcionalidades en producción. Basándonos en la velocidad de avance actual, al menos hasta Marzo del año siguiente no finalizaríamos el proyecto.

Si se detecta en la extrapolación que se produce un desvío respecto a la entrega del proyecto, tal y como se ve en el gráfico de Burn-Up del ejemplo anterior se revisa el esfuerzo que habría que realizar para corregir dicha desviación y poder tomar por anticipado medidas.

Para este tipo de reuniones aparte de otro tipo de gráficos y mediciones propias de cada proyecto utilizo principalmente la gráfica de Burn-Up para mostrar la extrapolación y un gráfico de barras mes a mes con el esfuerzo realizado, el previsto realizar y el umbral máximo que deberíamos de alcanzar para llegar al objetivo. (Ver gráficos adjuntos)

 Seguimiento Avance

 Gráfico con la velocidad de subida del proyecto (Esfuerzo). En azul se muestra el esfuerzo realizado mes a mes, en verde se muestra la línea que nos indica el ritmo óptimo y en Naranja se  indica el esfuerzo que habría que realizar en los meses restantes para alcanzar el objetivo de finalizar el proyecto en diciembre.

 En base a los datos obtenidos por las métricas y la extrapolación de estas se toman medidas para atajar las posibles desviaciones del proyecto, como puede ser aumentar el equipo de desarrollo, intentar  reducir el alcance del proyecto, eliminar cuellos de botella, etc…

10.- ¿Qué cosas crees que han mejorado desde que estás usando el modelo Ágil?.

Involucración por parte de todos los miembros del equipo del proyecto, visibilidad mayor y mayor capacidad para detectar problemas o desviaciones para poder realizar correcciones o propuestas de mejora.

11.- Si tuvieras que lanzar más proyectos : ¿seguirías haciéndolo así?. ¿Crees que hay proyectos que no se adaptan al modelo Ágil?. ¿Porqué?

Yo creo que una de las mayores ventajas de estos marcos de trabajo es su capacidad de adaptación a cualquier tipo de proyecto, por lo que sí que los seguiría usando, por las ventajas mencionadas en las respuestas anteriores.

Tengo que decir que el mayor problema y yo creo que el tendón de Aquiles es su utilización en equipos mixtos, es decir con gente deslocalizada. Hay varias pruebas de este tipo de equipos  que actualmente se estaban realizando para llevar las metodologías ágiles a equipos deslocalizados, como así pudimos ver en la última CAS2011, pero creo que hoy por hoy tiene una serie de complejidades de gestión, organización, cambio de mentalidad, etc.., que creo que sería en el único caso en el que yo dudaría en el uso de este tipo de marcos de trabajo para este tipo de proyectos. (Es mi opinión personal, claro está…)

12.- ¿Cuál es la frecuencia de las iteraciones que realizas?. Tras cada una, realizas una retrospectiva?

No utilizo una estándar para todos los proyectos, dependiente del tipo de proyecto, del impacto en negocio, del equipo asociado a dicho proyecto, etc… Estoy en un proyecto en donde las iteraciones se realizan semanalmente y en otro quincenalmente, depende.

Con las reuniones de retrospectiva pasa más o menos lo mismo ya que al final de cada iteracción tenemos la reunión de retrospectiva.

13.- ¿Haces seguimiento de las mejoras o acciones que se derivan de las retrospectivas de manera regular?

En las reuniones de retrospectiva se revisan todas aquellas acciones de mejora que se han recogido en la anterior reunión de retrospectiva, el/los facilitadores revisan el estado de estas y por supuesto se alimenta cada retrospectiva con las nuevas acciones detectadas.

En nuestro caso no sólo revisamos las acciones de mejora sino que también todo aquello que hemos hecho bien durante el periodo, para de esta forma recoger todas estas buenas prácticas y poder llevarlas a futuros proyectos.

14.- ¿Cuándo lanzas un nuevo proyecto, consultas los aspectos de mejora de las retrospectivas anteriores para asegurarte que no cometes los mismos errores?.

Sí, como ya he mencionado en la respuesta anterior tengo un catálogo de buenas prácticas que es revisado antes de comenzar un nuevo proyecto.

15.- En cuanto a la actitud del equipo:  ¿crees que ha cambiado la actitud ante los proyectos por el hecho de usar este ,modelo?. Destaca los puntos clave que han motivado este cambio.

Hay un cambio, sobre todo a nivel de involucración en el proyecto, destacando para ello los siguientes puntos: la visibilidad, la participación y la colaboración.

La visibilidad, porque todos los miembros del equipo conocen exactamente la marcha del proyecto y su estado diariamente.

La participación, ya que por ejemplo en la planificación de cada iteración la estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas, fomentando la involucración.

La colaboración, sobre todo cliente-equipo. Hay una estrecha colaboración entre el equipo y el cliente a la hora de definir las historias de usuario que entrarán en el próximo Sprint.

16.- ¿Quien desempeña el papel de Product Owner ? ¿Se le ha formado en su cometido de alguna manera? – ¿Cómo se realiza la definición de las historias de usuario?. ¿empleas alguna herramienta para su definición, seguimiento y control?

Actualmente lo desempeña el usuario Jefe de Proyecto se encargan de convertir las necesidades de negocio en historias de usuario. Como herramienta para la definición de las historias de usuario se utiliza Enterprise Architect y para el seguimiento de las mismas utilizamos el sistema existente actualmente basado en Lotus Notes.

17.- Hay Jefe de Proyecto en estos proyectos o se ha sustituido por un Scrum Master (si es que usas Scrum). Define brevemente que cosas hace el Jefe de Proyecto en un proyecto Ágil de los que conozcas.

Contamos con Jefe de proyecto, el cual realiza una serie de tareas como son: la protección del equipo frente a cualquier ingerencia externa que pueda alterar la buena marcha del proyecto, en nuestro caso al tener equipos de desarrollo en la modalidad de desarrollo con proveedores externos es el interlocutor con dichos equipos, además se encarga de allanar el terreno ante cualquier problema surgido como por ejemplo una incidencia detectada a nivel de software durante el desarrollo, etc…

Por otro lado contamos con la figura del coordinador de proyecto, que en aquellos proyectos con una entidad mayor donde hay varias áreas de negocio involucradas, se encarga junto con los Jefes de Proyecto de resolver cualquier problema surgido, se encarga además de generar las métricas y gráficos que indiquen el estado del mismo (Burn-up, extrapolaciones,esfuerzo realizado, etc…), es el interlocutor directo entre el equipo de proyectos (el cliente) y el equipo de desarrollo a través de los Jefes de Proyecto y se encarga de presentar a la dirección y a las áreas de proyectos (negocio) la marcha del proyecto.

Este cuestionario es mi pequeño grano de arena al uso de metodologías Ágiles en los proyectos, ni mucho menos he pretendido que sea una guía, sino que únicamente he querido contar mi experiencia personal en este mundo de las metodología o marcos de trabajo Ágiles.

Espero que esto sirva por lo menos a que a alguien le pique el gusanillo de adentrarse en este mundo tan apasionante como es el de la gestión de proyectos.

Por supuesto cualquier crítica o petición de aclaración sobre cualquier parte del artículo será bienvenida.

Javier Cañadilla Tarjuelo

Twitter: @jcannadilla

Linkedin: http://es.linkedin.com/pub/javier-canadilla-tarjuelo/13/24b/4b2

Email: javierctarjuelo@gmail.com

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*