En este artículo vamos a tratar de explicar nuestra experiéncia implantando Scrum y prácticas ágiles en general en nuestro proceso de desarrollo de software. Hemos divido el artículo en diferentes capítulos que explican cada una de las fases por las que hemos pasado. Esperemos que nuestra experiéncia os ayude de alguna manera. Nos gustaría remarcar que hablamos en nombre de todo el grupo de trabajo, que ha sido el que, trabajando todos unidos en una misma dirección, ha tirado adelante esta história.
ANÁLISIS
Después de un par de años trabajando en nuestra empresa, vimos que necesitábamos una manera mejor de trabajar. El equipo era demasiado especializado, cada persona tenía conocimiento sobre áreas muy concretas del sistema y esto penalizaba mucho las ausencias de algunas personas. Además a pesar de que al principio se trabajaba de manera relativamente tranquila poco a poco, a medida que los clientes aumentaban, la dinámica fue degenerando hasta convertir el trabajo diario en un “apaga fuegos”, solucionando bugs de anteriores versiones, dando asistencia, y intentado desarrollar nuevas funcionalidades en tiempo récord. Además existía una paralelización excesiva de las tareas (se empezaban muchas de golpe y pocas se acababan en un tiempo razonable ), los requisitos cambiaban con facilidad al igual que las prioridades y había poca comunicación entre el equipo, tanto de las tareas que realizaba cada uno cómo del conocimiento. Algo que si que teníamos era un seguimiento del trabajo exhaustivo por parte de nuestra responsable, que también estaba preocupada por mejorar nuestra manera de trabajar.
DESCUBRIMIENTO
Una vez que vimos que teníamos que buscar otra manera de trabajar, fuimos investigando por foros de internet, páginas web, experiéncias de conocidos hasta encontrar un documento que cambió completamente nuestra visión del desarrollo. El documento es el conocido “Scrum y XP desde las trincheras” y en él descubrimos conceptos tan importántes como Scrum, Integración Contínua o testeo unitário. Algunos de estos conceptos era nuevos para nosotros, otros ya los conocíamos pero no eramos conscientes del impacto que podían tener en nuestro día a día. El echo de conocer la experiéncia de gente que trabajaba en proyectos grandes e importantes y que consideraban esto vital, nos dio el empujón definitivo para emprender esta aventura.
PRIMEROS PASOS
Cuando tuvimos claro por donde tirar empezamos ha hacer una prueba piloto con un grupo reducido de personal, en concreto tres personas. Lo primero que hicimos fue montar un repositorio de código (con Subversion) y empezar a utilizar Scrum para nuestra organización interna, todo esto a espaldas de nuestros jefes. Antes de llenarle la cabeza con ideas “extrañas y novedosas” que pudieran provocar su rechazo creímos conveniente experimentar por nuestra cuenta un tiempo, para intentar mostrarles algo sólido, con técnicas ya probadas y con resultados que respaldaran nuestra idea.
Nuestros primeros pasos con Scrum consisitieron básicamente en aglutinar una serie de tareas (o historias) que teniamos en cola (¿product backlog?) , priorizarlas , realizar la división en subtareas , hacer una estimación (utilizando planning poker) y la realización de las reuniones diarias.
Aunque era todo muy “precario”, nuestra primera impresión con Scrum fue muy positiva. De tener a un equipo al que tan sólo se le controlaba la faena a intervalos relativamente grandes de tiempo, con la consiguiente tardanza en aplicar cambios de diseño o requerimientos y la lentitud en detectar errores, pasamos a tener un equipo que cada día compartía la información del trabajo realizado y al que era muy fácil orientar a resultados. Por otra parte, la utilización de un repositorio de código hacía que se eliminaran las tediosas sesiones de juntar versiones de diferentes programadores, ejercicio que era un generador de bugs terrible.
EXPANDIENDO LA SEMILLA
Una vez vimos que ibamos por la senda correcta, y que Scrum podia ayudarnos a mejorar nuestro trabajo, nos dispusimos a introducir el gusanillo de las metodologías ágiles al resto del grupo de desarrolladores, todavía a espaldas de nuestros responsables. No queríamos decirles nada hasta ver que esta técnica era válida para un grupo grande de personas, aunque nuestra responsable directa ya supiera algo de todo esto, pués es complicado esconder ciertas cosas. Cómo queríamos que el grupo se sintiera implicado en la toma de la decisión y no queríamos imponer nada, hicimos una presentación al grupo mostrándoles la manera de trabajar que teníamos ahora con nuestros diferentes gestores y a la vez explicando cómo contrapunto la gestión que se podría llevar a cabo con una metodología ágil (en concreto Scrum). Una vez acabada la presentación les preguntamos si creían que la manera actual de trabajar era una buena manera y, obviamente, la respuesta fue negativa; todo el mundo creía que se podían hacer las cosas mejor, que nuestra gestión del tiempo era deficitária y que el hecho que la toma de decisiones se centrara en nuestra responsable, que por su parte tenía un exceso de trabajo, hacía que el desarrollo se viera penalizado. Por suerte nuestra, esto coincidió con la decisión de nuestra responsable de delegar todo el trabajo que tenía que ver con desarrollo en nuestras manos, decisión que vino apoyada por el hecho que viera que teníamos capacidad para autoorganizarnos. Así que decidimos proponer al grupo un cambio en la manera de trabajar, básicamente centrandonos en dos aspectos:
ANÁLISIS
Después de un par de años trabajando en nuestra empresa, vimos que necesitábamos una manera mejor de trabajar. El equipo era demasiado especializado, cada persona tenía conocimiento sobre áreas muy concretas del sistema y esto penalizaba mucho las ausencias de algunas personas. Además a pesar de que al principio se trabajaba de manera relativamente tranquila poco a poco, a medida que los clientes aumentaban, la dinámica fue degenerando hasta convertir el trabajo diario en un “apaga fuegos”, solucionando bugs de anteriores versiones, dando asistencia, y intentado desarrollar nuevas funcionalidades en tiempo récord. Además existía una paralelización excesiva de las tareas (se empezaban muchas de golpe y pocas se acababan en un tiempo razonable ), los requisitos cambiaban con facilidad al igual que las prioridades y había poca comunicación entre el equipo, tanto de las tareas que realizaba cada uno cómo del conocimiento. Algo que si que teníamos era un seguimiento del trabajo exhaustivo por parte de nuestra responsable, que también estaba preocupada por mejorar nuestra manera de trabajar.
DESCUBRIMIENTO
Una vez que vimos que teníamos que buscar otra manera de trabajar, fuimos investigando por foros de internet, páginas web, experiéncias de conocidos hasta encontrar un documento que cambió completamente nuestra visión del desarrollo. El documento es el conocido “Scrum y XP desde las trincheras” y en él descubrimos conceptos tan importántes como Scrum, Integración Contínua o testeo unitário. Algunos de estos conceptos era nuevos para nosotros, otros ya los conocíamos pero no eramos conscientes del impacto que podían tener en nuestro día a día. El echo de conocer la experiéncia de gente que trabajaba en proyectos grandes e importantes y que consideraban esto vital, nos dio el empujón definitivo para emprender esta aventura.
PRIMEROS PASOS
Cuando tuvimos claro por donde tirar empezamos ha hacer una prueba piloto con un grupo reducido de personal, en concreto tres personas. Lo primero que hicimos fue montar un repositorio de código (con Subversion) y empezar a utilizar Scrum para nuestra organización interna, todo esto a espaldas de nuestros jefes. Antes de llenarle la cabeza con ideas “extrañas y novedosas” que pudieran provocar su rechazo creímos conveniente experimentar por nuestra cuenta un tiempo, para intentar mostrarles algo sólido, con técnicas ya probadas y con resultados que respaldaran nuestra idea.
Nuestros primeros pasos con Scrum consisitieron básicamente en aglutinar una serie de tareas (o historias) que teniamos en cola (¿product backlog?) , priorizarlas , realizar la división en subtareas , hacer una estimación (utilizando planning poker) y la realización de las reuniones diarias.
Aunque era todo muy “precario”, nuestra primera impresión con Scrum fue muy positiva. De tener a un equipo al que tan sólo se le controlaba la faena a intervalos relativamente grandes de tiempo, con la consiguiente tardanza en aplicar cambios de diseño o requerimientos y la lentitud en detectar errores, pasamos a tener un equipo que cada día compartía la información del trabajo realizado y al que era muy fácil orientar a resultados. Por otra parte, la utilización de un repositorio de código hacía que se eliminaran las tediosas sesiones de juntar versiones de diferentes programadores, ejercicio que era un generador de bugs terrible.
EXPANDIENDO LA SEMILLA
Una vez vimos que ibamos por la senda correcta, y que Scrum podia ayudarnos a mejorar nuestro trabajo, nos dispusimos a introducir el gusanillo de las metodologías ágiles al resto del grupo de desarrolladores, todavía a espaldas de nuestros responsables. No queríamos decirles nada hasta ver que esta técnica era válida para un grupo grande de personas, aunque nuestra responsable directa ya supiera algo de todo esto, pués es complicado esconder ciertas cosas. Cómo queríamos que el grupo se sintiera implicado en la toma de la decisión y no queríamos imponer nada, hicimos una presentación al grupo mostrándoles la manera de trabajar que teníamos ahora con nuestros diferentes gestores y a la vez explicando cómo contrapunto la gestión que se podría llevar a cabo con una metodología ágil (en concreto Scrum). Una vez acabada la presentación les preguntamos si creían que la manera actual de trabajar era una buena manera y, obviamente, la respuesta fue negativa; todo el mundo creía que se podían hacer las cosas mejor, que nuestra gestión del tiempo era deficitária y que el hecho que la toma de decisiones se centrara en nuestra responsable, que por su parte tenía un exceso de trabajo, hacía que el desarrollo se viera penalizado. Por suerte nuestra, esto coincidió con la decisión de nuestra responsable de delegar todo el trabajo que tenía que ver con desarrollo en nuestras manos, decisión que vino apoyada por el hecho que viera que teníamos capacidad para autoorganizarnos. Así que decidimos proponer al grupo un cambio en la manera de trabajar, básicamente centrandonos en dos aspectos:
- Desarrollo: Les propusimos empezar a utilizar buenas prácticas de programación de manera conjunta y coordinada -> Instauranado el repositorio de código y enseñando cómo utilizarlo, creando una guía de estilo para homegenizar el código de todo el departamento, instaurando el testeo unitario, configurando un servidor de integración contínua, etc.
- Gestión: Les propusimos instaurar Scrum como nuestra metodología de trabajo.
De esta manera empezamos nuestros primeros sprints. Al principio nos centramos en las reuniones de inicio de sprint, en los seguimientos diários y en pequeñas retrospectivas muy básicas. La reacción del grupo fue muy positiva y poco a poco empezamos con las demostraciones internas, aunque esto todavía tenemos que mejorarlo.
IMPULSO DEFINITIVO
El impulso definitivo ha sido la participación de nuestra jefa en todo el proceso de Scrum, principalmente en la reunión de inicio de sprint y en las demostraciones y retrospectivas. Esto ha sido muy importante para poder definir de manera más detallada las tareas a realizar, para la decisión de que entra y que no entra en cada sprint y, sobretodo, en que viera que somos un grupo que trabaja unido para obtener resultados. Ha sido también vital hacerle ver que la parelización de tareas es contraproducente y tan sólo lleva a tener muchas tareas sin acabar al final del sprint ( que es lo que nos pasaba en los primeros sprints ). Ahora todo el equipo se centra en una historia de usuario ( a lo sumo dos ) y a final de sprint siempre podemos mostrar un producto con incremento de valor sobre la iteración anterior.
IMPEDIMENTOS
Son muchos los impedimentos que nos hemos ido encontrado a lo largo de nuestra aventura, y seguramente nos encontraremos muchos más. Vamos a intentar exponer en forma de lista los que consideramos más importantes:
- Dificultad a la hora de estimar: Aunque cada dia afinamos más, todavía nos falta un buen trecho para llegar a hacer buenas estimaciones de las histórias de usuario. Esto normalmente se vé reflejado en que conseguimos realizar menos histórias de las previstas. Afortunadamente, el hecho de que ultimamente el equipo se centre en menos histórias a la vez ha hecho que se minimice el impacto de este impedimento.
- El equipo no sólo se dedica a programar. Nuestro equipo no es un equipo de desarrollo al 100%. También hace testeo, instalación en el cliente, resolución de incidencias, etc. Esto hace que nuestras estimaciones se vean penalizadas por una carga de trabajo no previsto que retrasa el desarrollo.
- Incompresión por parte de otros gestores. La respuesta de nuestra jefa a nuestra propuesta ha sido espléndida, nos apoya al 100% e intenta colaborar en todo lo posible, pero no sólo trabajamos con ella. El hecho que haya en nuestra empresa gente con mentalidad tradicional respecto al desarrollo de software (o incluso sin ninguna mentalidad), hace que a veces choquemos frontalmente con su forma de dirigir los proyectos y que sea complicado realizar nuestro proceso productivo tal cómo nos gustaría.
- Respeto a las iteraciones: En ocasiones no hemos podido llevar a cabo sprints completos, debido a “grandes marrones” que llevaban tiempo aparcados y que de golpe se deben solucionar, cambiando de un día para otro (a veces justo al dia siguiente de la reunión de inicio) todas las tareas programadas.
- Grandes aprendizajes. Todos nosotros somos nuevos en el mundo de la gestión de proyectos informáticos y, aunque intentamos aplicar todas las técnicas de manera razonable y a pasos pequeños, hay muchas cosas que aprender, tanto técnicas ( a configurar un servidor de integración continua, a programar con testeo unitario, a relizar testeo funcional, etc ) como metodológicas. Por suerte, cada vez tenemos más experiéncia y vamos dando pasos más grandes y seguros.
- Reticencia de algunos desarrolladores. Algunos desarrolladores veían algunas de estas técnicas como algo que disminuía su velocidad de trabajo, cosa que se veía reforzada por el hecho de trabajar con los gestores tradicionales que antes comentábamos. Aquí nuestra tarea “evangelizadora” ha sido importante, haciendo charlas, propiendo lecturas, analizando artículos, etc. Al final, hemos podido convencer a todo el mundo y esto se ha notado en el dia a dia.
- Dificultad para realizar algunas prácticas: Aunque parezca increíble, practicas básicas de Scrum cómo poder estar sentado todo el equipo junto, o tener una sala con el panel de scrum donde poder realizar las reuniones diarias son “difíciles” de llevar a cabo en algunas empresas.
EL FUTURO
Creemos que el futuro que nos espera va a ser mucho mejor. Todavía tenemos muchas cosas que mejorar: demostraciones, retrospectivas, reuniones de incio… La preparación de las demostraciones nos llevan mucho tiempo (ganar experiéncia con nuestra herramienta de ALM nos ayudará mucho ) y tenemos poco tiempo para hacer buenas retrospectivas.
Esperamos también aumentar la visibilidad de nuestro proceso y hacerlo extensivo a toda nuestra sección, hacer más públicas nuestras demostraciones ( por ahora internas ), dar permiso a todo el mundo para que vean el avance de nuestro proyecto via web con los diferentes reportes ( tablero de scrum, burndown, tasa de resolución de bugs, etc ) e intentar impregnar al resto del departamento o incluso de la empresa de nuestra filosofía de trabajo.
También esperamos que nuestros desarrollos sean cada vez más estables gracias a la incorporación masiva del testeo unitario, la integración contínua, mejora en los procesos de testeo, etc. Esto hará que las interrupciones en el desarrollo por la irrupción de bugs también sea menor. El hecho de tener sistemas más estable también hará que podamos delegar trabajo de instalación y mantenimiento a otras secciones de nuestra empresa, ganando así tiempo para desarrollar más y mejor.
CONCLUSIONES
Cómo conclusión podemos decir que nuestra experiencia con las metodologías ágiles en general y con Scrum en particular está siendo muy positiva, tanto en el ámbito personal cómo en el profesional (mejora en el trabajo diario al disminuir los impedimentos, alineación con el cliente para alcanzar objetivos, focalización en incremento de valor…). También es importante tener claro que Scrum y las metodologías ágiles en general no son una bala de plata. Son metodologías que requieren de un esfuerzo “extra” a corto plazo por parte de todos los roles implicados en el desarrollo del proyecto (esfuerzo que es posible que algunas personas no estén dispuestas a pagar) y que requieren de un contexto apropiado para su buen funcionamiento (hay tipos de proyectos que difícilmente encajarían en Scrum). Cómo dice Rodrigo Corral en este artículo “nadie dijo que no exigiera un esfuerzo”.
Por nuestra parte os animamos de manera entusiasta a que hagáis el esfuerzo de conocer Scrum porque el esfuerzo vale realmente la pena.
No hay comentarios:
Publicar un comentario