Desde hace varios años, en Grup de Serveis Triangle hemos adoptado la metodología de gestión de desarrollos conocida como Scrum. Para aquellos que no estén familiarizados con este término, esta metodología propone una serie de buenas prácticas en los procedimientos de desarrollo de software, basados en actualizaciones incrementales del producto (en vez de una única entrega con el producto terminado), también conocidas como Sprints; y un conjunto de equipos autogestionados, con sus respectivos acuerdos y eventos, enfocados a mejorar el rendimiento y la producción. Para conocer más en detalle todos los roles, procedimientos o características concretas de esta metodología, podéis encontrar toda la información en la red, leer libros especializados, asistir en cursos, etc. ya que en esta entrada de blog quiero centrarme en los cambios que ha sufrido nuestra empresa desde que iniciamos la experiencia de trabajar con metodología Scrum.
Como ya he comentado al principio, tan solo estamos empezando a implantar este método, ya que el cambio en los roles, estructura u organización no es algo que sea fácil ni rápido de implementar, sino que necesita un tiempo de adaptación largo (y más con un ejemplo como el nuestro: una empresa que llevaba más de 30 años rigiéndose por otras metodologías de trabajo). Aun así, con lo experimentado hasta el momento, ya podemos detectar una serie de beneficios que compartimos a continuación.
Grandes proyectos
El primero de todos, y el más claro y evidente, lo hemos experimentado en la organización de los proyectos de más abasto en el calendario, es decir, los proyectos más largos como podrían ser migraciones, arranques, integraciones con aplicaciones externas, puesta en marcha de nuevos módulos y, en definitiva, cualquier proyecto cuya duración sea superior a 1 mes. En este tipo de proyectos, se definen los diferentes sprints que compondrán el proyecto y, dependiendo de la periodificación de los sprints, se entregan pequeñas partes incrementales del producto basadas en una priorización realizada previamente (Product Backlog).
Las entregas periódicas permiten que, desde una primera fase de desarrollo, el cliente final ya se puede familiarizar con el resultado, lo que le ofrece otro punto de vista y la posibilidad de realizar pequeños cambios o enfoques distintos al inicial, que si se tuvieran que llevar a cabo una vez el producto esté completado serían más costosos e ineficientes. Además, también le permite priorizar en función del presupuesto asignado al proyecto si la funcionalidad a desarrollar es muy extensa.
Gestión del equipo
Otro beneficio destacado lo encontramos en la autogestión de los equipos, principalmente en el del equipo de desarrollo (o al que nosotros nos gusta llamar DevTeam). Como es el propio equipo quien decide la carga de trabajo que puede entrar en cada Sprint, el estrés es menor y, por lo tanto, aumenta la productividad del equipo. Destacar que como el DevTeam asume un rol en el proceso (y no un rol cada persona que forma el equipo), todos remamos para conseguir un objetivo común de manera que se mejoran muchas dinámicas dentro del equipo de trabajo y se crea una buena compenetración y sintonía entre todos los miembros.
Product Owner: relación con el cliente
Por otro lado, el contacto directo con el cliente lo centraliza la figura del Product Owner, que es quien realiza un filtro y reduce la interacción directa de los desarrolladores con el cliente para que estos se centren en lo que principal de su trabajo: desarrollar. Además, otro beneficio para el cliente es que su Product Owner centraliza todo el conocimiento relacionado con su implementación y, por lo tanto, es su persona técnica de referencia en cuanto a nuevos proyectos y posible nueva funcionalidad a implementar.
Para finalizar, me gustaría reiterar que la puesta en marcha de todos los procedimientos que implica esta metodología puede ser compleja. Para Triangle el reto actual reside en encontrar una convivencia perfecta entre los Sprints y los proyectos pequeños (modificaciones de uno o dos días), y afinar algunas reuniones como la Revisión y la Retrospectiva del Sprint. Pero quizás si estás pensando adaptar esta metodología a tu empresa deberás ser un poco flexible y adaptar algún aspecto a los requerimientos y necesidades a la casuística de tu empresa, porque, aunque el Scrum sea específico para la producción de software, ni todos las empresas de software somos iguales, ni tampoco lo son los productos software que desarrollamos.