Por Borja García
Durante mi corta experiencia como desarrollador, me he dado cuenta de que tengo cierta tendencia a valorar el “picar código” sobre otras cosas. Probablemente porque es lo que más divertido me parece de este trabajo, la sensación de resolver un reto de lógica, y también, porque ver como toma forma el código de una aplicación da una sensación directa de avance.
Aun así soy consciente, y trato de recordarme a menudo, que el objetivo final no es programar sino aportar valor. Y aportar valor puede no ser tan obvio a priori, de hecho, depende de muchas variables del contexto en el que estás trabajando.
Tengo la suerte de que el equipo en el que estoy ahora mismo, está compuesto casi en su totalidad por gente recién incorporada a la empresa colaboradora. Esto significa que además de tener poco contexto del dominio de negocio, aplicaciones internas, sus modelos de datos, etc., somos un equipo que no se conoce y está experimentando y ajustándose a la forma de trabajar que mejor encaje con nosotros. Esto me ha hecho apreciar la importancia de las Metodologías de Gestión de Proyectos (PM - Project Management), especialmente durante las últimas semanas.
Desde que empecé hemos estado usando Kanbanize, una herramienta online para gestionar el flujo de trabajo, y hemos estado hablando de sprints, dailies, planning, retros, backlog, WIP, etc. Terminología que me resultaba familiar, de asignaturas relacionadas con la gestión de proyectos que cursé en el grado, y a la que no daba demasiada importancia.
Pero a medida que pasaba el tiempo, se unía más gente al equipo, los requisitos del desarrollo cambiaban y las stakeholders se preocupaban por la falta de visibilidad de nuestro trabajo y un deadline muy marcado por cambios legislativos acercándose. Cada vez se hacía más evidente la necesidad de ser metódicos en nuestra forma de trabajar y dejar de hacer las cosas de forma “intuitiva” (incluso llegando a ignorar nuestro tablero de Kanbanize).
Esta necesidad es la que me ha dado curiosidad por leer un poco sobre el tema, refrescar conceptos y escribir este artículo, donde repasaré las metodologías Scrum y Kanban, que son las que trata de usar mi equipo.
La idea del Scrum es crear equipos autogestionados con diferentes roles, de 10 personas como máximo, que dividen el desarrollo en iteraciones y llevan un seguimiento constante del mismo en cada una, mejorando así la comunicación, el trabajo en equipo y la velocidad a la que se entrega valor al cliente.
Sus características principales son:
Es similar a Scrum pero plantea una forma más flexible de trabajar, sin roles ni ceremonias predefinidos, centrándose en dar visibilidad al trabajo que se está haciendo y tratando de no abarcar demasiado a la vez.
Sus características principales son:
Parece que es tan popular combinar Scrum y Kanban que es común encontrarse el término “Scrumban” como una tercera metodología. Consiste básicamente en aplicar la flexibilidad, visibilidad y foco en el WIP de Kanban a la estructura de Scrum:
Aunque es útil tener una base teórica como guía para estandarizar la forma de trabajar, y Scrum y Kanban son metodologías populares con un planteamiento sencillo e intuitivo, en la práctica todo puede cambiar y la comunicación no es algo tan trivial como puede parecer.
Yo mismo, he experimentado en primera persona la necesidad de un mínimo de comprensión mutua y comunicación fluida con el cliente -stakeholders en mi caso- para llevar a cabo correctamente metodologías ágiles como estas.
En casos de gran incertidumbre y requisitos no definidos del todo, las metodologías más flexibles parecen funcionar mejor para evitar perder tiempo y recursos en desarrollos que luego acaban desechados porque no casan con los cambios de última hora. Pero adoptar esta mentalidad no sirve de nada si se hace de forma unilateral y el cliente adopta una postura más clásica, en la que cada iteración debe acabar entregando en bloque todo lo desarrollado para que pueda validarse, o todo lo contrario, que se tome la flexibilidad como el poder aplazar la definición concreta de los requisitos.
Es por eso que, aunque parezca una conclusión obvia, lo esencial es comunicarse. Y no se trata de tener razón, sino de escuchar y llegar a un acuerdo que nos beneficie a todos, ya que volviendo al principio: el objetivo final es entregar valor.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
