Tras algunos años trabajando con metodologías ágiles recopilo todo lo que aprendido y los errores más comunes que solemos cometer. Están expuestos a modo de lista de ideas, sin matizar, con el objetivo de no hacerlo excesivamente largo.
General:
Las metodologías son una herramienta, un medio para hacer buenos productos.Son las personas las que hacen que las metodologías funcionen.Se pueden hacer buenos productos con metodologías tradicionales al igual que malos productos con metodologías ágiles.Las metodologías ágiles son las que mejor se adaptan a Internet, donde los proyectos son algo vivo.Las metodologías ágiles te permiten hacer algo diferente a lo inicialmente planteado, pero que aporte mucho más valor.Las metodologías ágiles, bien aplicadas, pueden aportar un punto adicional al trabajo de un buen equipo.Las metodologías ágiles no tienen la culpa de todos los males que ocurren en un proyecto (ni todas las soluciones).Metodología ágil no significa ausencia de metodología.La metodología es necesaria, se puede sustituir por el sentido común solo en proyectos pequeños y entornos muy controlados.Más gente significa “menos ágiles”.No se necesita poner nombre a las cosas para trabajar con metodologías ágiles.Las metodologías ágiles son transparentes para lo bueno y para lo malo.Las métricas de trabajo individuales son casi siempre innecesarias y van en contra de los principios de scrum.Pensar siempre en que estamos construyendo un producto, no entregables.Las metodologías ágiles no son solo metodologías de desarrollo de software.Las metodologías ágiles son metodologías de proyectos en su totalidad.Aplicación:
La teoría es importante, pero tu experiencia personal lo es más aún.El problema más común con las metodologías ágiles es que no se aplican correctamente.Tras un par de meses, un equipo coordinado rinde el doble que un equipo recién montado.Algo está fallando si tardas un día entero en una preparación de sprint.Si las metodologías ágiles te parecen complejas, es que algo estás haciendo mal.Algo está fallando si mantener el proceso te lleva más tiempo que avanzar en el producto.En proyectos grandes, debes incluir tareas de análisis-definición de funcionalidades futuras entre las tareas de desarrollo.No he encontrado ningún product owner que haga todas las funciones que se esperan de él, siempre hay que complementar de alguna forma su trabajo.La metodología se puede adaptar a las necesidades de tu proyecto y tu cliente.La mayoría de las adaptaciones se hacen por desconocimiento de la metodología.El scrummaster no debe ser el único que trate con el cliente, el equipo debe estar lo más cerca posible del negocio.Se necesita definir al principio del proyecto una visión global de todo sin entrar en detalles (arquitectura técnica y UX), para que después las piezas encajen bien.Scrum se adapta mejor a los cambios, pero los cambios que afecten a las bases del proyecto (arquitectura técnica y UX) son un problema. Esto pasa con scrum y cualquier otra metodologíaHay que evitar todo lo que no aporte valor al producto o ayude a su mantenimiento.Estimar es algo que no aporta al producto final, pero sirve para saber si un desarrollo será rentable antes de abordarlo.Metodologías ágiles no implica ausencia de documentación.Un sistema de documentación colaborativo con la última versión de las decisiones es mucho más útil que tener actas de todo con decisiones antiguas.A veces alguien externo al equipo, que aporte otro punto de vista, te ayuda a mejorar.Kanban encaja mejor que scrum en proyectos con correctivo-evolutivo.“Más reuniones” significa “Menos tareas hechas”.Las metodologías ágiles no encajan del todo con proyectos de I+D, pero tampoco conozco ninguna que encaje mejor.Todos los miembros del equipo, especialmente los encargados de definición y diseño deben permanecer en el equipo hasta el final.Consultoría:
Las metodologías ágiles son mucho más difíciles de aplicar en el mundo de la consultoría, donde hay una relación contractual con un cliente.Las metodologías ágiles son incompatibles con las RFP’s cerradas.El contrato ágil es un mito, las cosas solo funcionan si hay una relación de confianza.Las metodologías ágiles requieren la implicación del cliente y esto requiere tiempo, pero se nota en el resultado final.La formación es fundamental en los primeros proyectos con metodologías ágiles.La mejor forma de convencer es hacer una prueba y demostrar que funciona.Comenzar a trabajar con metodologías ágiles supone un cambio muy drástico para el cual no todo el mundo está preparado. Es imprescindible avanzar paso a paso.Algo está fallando si solo hablas con el cliente en las demos cada 15 días.“Metodologías ágiles” no quiere decir que haya “barra libre” de cambios y funcionalidades nuevas.El objetivo del cliente y del consultor debe ser siempre el mismo. Si no lo es, hay un problema.Lean UX:
Construir un equipo que mezcle perfiles de diseño con perfiles técnicos ayuda mucho a los proyectos.Tratar de diseñar un proyecto completo antes de empezar a programar es una pérdida de tiempo (a no ser que el proyecto sea muy pequeño).El expertise es importante, pero el feedback temprano y la respuesta de los usuarios lo es aún más.Define primero la estructura global a alto nivel y a partir de ahí ve detallando todo en cada sprint.Hay cosas que deben estar definidas antes de empezar a programar para que después todo encaje: objetivos del servicio y las pantallas principales.La UX de un sprint debe estar terminada antes de que empiece el sprint.A día de hoy no hay ninguna charla, libro o post que te dé una solución para este tema. Y si existiera, una solución que encaje a otro en sus circunstancias no tiene porque encajar en las tuyas.Calidad:
La calidad no es una persona, es un concepto que debe estar muy presente en cada miembro del equipo.Programar hasta el último minuto antes de la demo es lo más común, pero lo ideal es incluir menos funcionalidades y bien probadas.Se saca todo el partido a las metodologías ágiles cuando se combinan con prácticas de ingeniería como pruebas automáticas, TDD, control de versiones, integración continua, pair programming, etc.Tener tras cada sprint un entregable listo para subir a producción es un buen objetivo para un equipo de scrum.Comunidad:
En 2013 el 73% de las empresas se consideran ágiles, pero pocas lo aplican correctamente.¿Llamamos referente a una persona que destaca por su trabajo o por su capacidad de hacer ruido? ¿Sabrías distinguirlos?Las metodologías ágiles pueden servir de catalizador para cambiar la forma de trabajar de una empresa e incluso su estructura.Hay una creciente tendencia a pensar que metodologías ágiles sirven para hacer la sociedad mejor, creo que se esto se le ha ido de las manos a algunos.
José Ignacio Herranz es consultor en nuevas tecnologías con más de 8 años de experiencia en Internet. Comenzó su carrera creando aplicaciones para móviles en Zed y actualmente forma parte del equipo de Paradigma, donde lidera proyectos de Internet para grandes empresas españolas. Siempre en busca de nuevos retos, es un estudioso de temas tan diversos como las metodologías ágiles, las tecnologías móviles o el diseño de producto. Para hacer buenos productos, procura siempre crear un marco de trabajo que permita a las personas mejorar y dar su mejor versión.
Ver toda la actividad de José Ignacio Herranz Roldán