Entradas publicadadas a lo largo del Abril, 2010

Esta semana hemos asistido a la universidad para dar una charla de introducción a Scrum.

La mejor manera de dar a conocer las metodologias ágiles es hacer ágil la clase, convertir a tu auditorio en partícipes activos. Los alumnos comentaron que en otras charlas los ponentes venían con un mensaje prefijado y no interactuaban apenas con él.

El planteamiento que se planificó para su primera lección introductoria  fue muy sencillo, una breve explicación sobre el manifiesto ágil, las herramientas y los roles, y luego a jugar con una estimación real entre todo los asistentes empleando Plannigpóker.

Los que mas le gustó fue este último aspecto, sentirse parte de la ponencia, saliendo al estrado a dar explicaciones sobre el por que afirmaban que una historia tenía un coste concreto, distinto del de sus compañeros.

El juego consiste básicamente en crear un proyecto sobre alguna tarea habitual que realicen los alumnos, por ejemplo, limpiar una casa. Se crean las tareas: Barrer el suelo de una habitación, fregar el cuarto de abaño, limpiar el polvo de una estantería,  etc. Los alumnos van creando las historias y luego las estiman. Lo mejor viene cuando tienen que explicar a sus compañeros por que ellos creen que algo cuesta el doble de lo que dicen los demás.

El tiempo en la universidad es escaso, pero con este rápido juego se fomenta el espíritu de colaboración, de trabajo en equipo, en verdad, la lección que aprenden es que es la comunicación es el éxito de los proyectos, mas que las herramientas o las metodologías.

Uno de los grandes errores que cometen muchas empresas al introducir Scrum como metodología de trabajo, es que confunden la sencillez de sus principios, con la complejidad de integrarlos en un grupo de personas.

En Slideshare podemos encontrar muchos cursos de Scrum. Destacamos este que nos permite explicar que es Scrum a un neófito en diez minutos, y son precisamente estos titulares los que le llevan a la confusión antes comentada.

Explicar Scrum es bastante sencillo, sus principios y sus herramientas no tienen una gran complejidad, por lo que en realidad con un curso que dure como mucho un día, cualquier empresa puede empezar a aplicarlo sin necesitar nada más. El coste de adquirir conocimientos sobre Scrum es bastante barato en tiempo.

El error se comete cuando se piensa que por disponer de un grupo de herramientas y de un sistema sencillo, la complejidad de integración es también sencilla. El problema no viene por las herramientas o por los sistemas, vienen por las personas que participan.

Los roles obligan a cada persona que está implicada a tener que asumir su papel sin interferir en el de los demás y a tener que pensar en equipo y no en uno mismo. Cuando se integra Scrum el cambio de mentalidad obliga a que las personas realicen un esfuerzo para adaptarse a él, un esfuerzo que requiere un gran sacrificio al principio, hasta que haya asimilado el cambio a la agilidad.

En conclusión, los titulares que propugnan que agilidad es igual a sencillez son un error y llevan a la confusión, las metodologías ágiles son fáciles de integrar pero igual de difíciles de gestionar al principio, aunque a diferencia de otras metodologías, una vez superada la primera fase de integración, la producción se hace más efectiva y eficiente, dado que la carga de gestión de los procesos es menor.

Los clientes primerizos demandan mucha información sobre los procesos de creación de  los proyectos y sus fases. Demandan sobre todo esta información por que quieren tener controlado tanto el proceso como el coste, sobre todo esto último.  El problema ante el que nos encontramos es más de concepto empresarial que de uso de una u otra metodología.  La agilidad debe ser una opción que toma el cliente por que crea en ella y sus fundamentos y no por que la quiera integrar en un entorno donde de no se quiere hacer ágil y no quiere aprender a delegar funciones y responsabilidades en el equipo de trabajo.

La mejor manera de representar a un cliente una planificación de costes es explicarle que esta se va realizando por bloques, que él mismo se marca unos objetivos parciales, sobre ellos se hace una labor de extraer las historias concretas hasta el último detalle, que son las tareas. Sobre estos detalles se realiza una estimación y se da el coste, así como el tiempo de desarrollo, llamado sprint para cada objetivo. Los equipos que estiman  tareas a corto plazo lo hacen mejor, con un nivel de detalles mas riguroso,  conociendo mejor la complejidad, el coste y el tiempo de desarrollo, dado que cada equipo conoce su velocidad.

Con el cliente se tiene que trabajar en un documentos de objetivos con requisitos generales, estos deben quedar claro, así el cliente tiene la garantía de conocer el orden de cumplimiento de objetivos y que aspectos principales tendrá, pero no se conoce el coste exacto, dado que este se irá fraccionando. Suele ocurrir que el cliente, para conseguir cada objetivo parcial, exige mas esfuerzos de los inicialmente estimados, por eso es mejor realizar para cada objetivo la estimación directa y añadir mientras vayan ocurriendo las tareas extras.

El enfoque de un coste cerrado por adelantado debe ser  cambiado por el de  ”Coste para cumplir unos Objetivos”.  Si un cliente quiere conocer el importe exacto de cada fase, lo mejor es darle una orientación, un rango, cuando mas complicado sea el objetivo mas amplio el rango. Hay que hacerle entender el beneficio de las metodologías ágiles aun teniendo una incertidumbre sobre el coste exacto del proyecto.

La Disección en los inicios del proyecto podría presentarse al cliente de la siguiente manera.

La experiencia del cliente le va llevando a conocer el coste aproximado de un objetivo en relación al número de sprints necesarios para conseguirlo, algo que le sirve de orientación, y con el paso del tiempo lo acaba asumiendo y entendiendo. Cerrar un precio es tan perjudicial para el equipo desarrollo como para el cliente, dado que no puede moldear el encargo cuando va viendo los resultados parciales.