63 lecciones trabajando con metodologías ágiles

Tras algunos años trabajando con metodologías ágiles, recopilo todo lo que he 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ía
  • Hay 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.

Mi rol es diseñar proyectos de Internet y hacer que salgan bien. Es lo que me gusta hacer y a lo que me he dedicado los últimos 10 años. Siempre en busca de nuevos retos, me interesan temas tan diversos como las metodologías ágiles, las tecnologías Cloud o el diseño de producto. Para hacer buenos productos, procuro 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

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

2 comentarios

  1. Ale del Pino dice:

    Excelente información. En mi blog http://www.aletecno.com.ar/noticias/metodologias-agiles-de-desarrollo-de-software-scrum-ejemplos-pdf-ebooks.php he creado una entrada con más info sobre SCRUM y Metodologías Ágiles que quisiera aprovechar para compartir. Saludos Cordiales

Escribe un comentario