Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente

0

El segundo principio del manifiesto para el desarrollo ágil de software se enfoca directamente en una cultura abierta al cambio. Es quizás uno de los cambios más rompedores con la visión clásica en la que fechas y alcance solían grabarse a fuego.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Hay dos partes claras en este principio:

  • Aceptar el cambio, incluso cuando es tardío.
  • El cambio no es un paso atrás, sino otra forma de entregar valor al cliente.

Abrazar la cultura del cambio

Creo que a estas alturas todos tenemos claro que en el mundo del desarrollo de software es muy difícil, y a veces imposible, tener claros los requisitos de una funcionalidad antes de empezar.

Tenemos también claro que lo importante es entregar software con valor, tal y como reza el primer principio. ¿Qué tiene de valor entregar lo que se ha pedido si luego no es realmente lo que se necesita? Ninguno. Esta claro que lo ideal es ir desde el principio a hacer lo que se necesita, pero eso es muchas veces imposible.

Si negocio pide cambiar algo eso puede significar rehacer parte del trabajo. Eso puede parecer tirar lo que hemos hecho, porque en el fondo lo es . Pero eso no es lo importante. Como comenté en «Evaluación de decisiones«, lo importante no es lo que tiramos o ya hemos gastado, sino lo que nos queda por gastar y lo que obtendremos.

Tenemos que meternos en la cabeza que no importa rehacer o descartar lo hecho, siempre que eso nos haga entregar más valor. Por supuesto que lo ideal sería haberlo detectado antes, pero no nos queda otra que resignarnos a la realidad que tenemos delante.

Y este es otro caso en el que la traducción, hace perder un matiz importante a la frase. Una mejor traducción es que los cambios son bienvenidos, no sólo aceptados. Es decir, deberíamos no sólo aceptar y resignarnos ante la realidad de que hay cambios, sino que deberíamos promoverlos cuando estos realmente aportan valor. Nos debería gustar cambiar, cuando esto nos hace apuntar a un mejor destino.

No implica cambio sin límite

Una cosa es aceptar el cambio y otra es correr como pollo sin cabeza.

Cada vez que nos piden un cambio debemos evaluar qué coste nos implica ese cambio y qué valor añadido se contempla. Si el balance es positivo, adelante con el cambio. Pero tener que invertir dos meses más, por hacer algo ligeramente mejor y que no justifique el retraso en tiempo y el aumento en coste, es absurdo.

Pero estas decisiones son las que deberían ser fáciles de tomar con negocio. Se alineará con el coste y el valor que esperamos. Al fin y al cabo ese retraso significa que el equipo no le podrá entregar otra cosa durante ese tiempo y el cliente será lo suficientemente listo como para decidir si quiere ese cambio o acabar antes.

El cambio proporciona ventaja competitiva

Este punto va directamente ligado al time-to-market. Es decir, a tener lo antes posible en el mercado nuestro producto o una característica de nuestro producto.

Los cambios pueden venir motivados por:

  • No poder definir de forma completa y acertada los requisitos.
  • Cambios de entorno rápidos.

El primer motivo es en el que me he centrado en los capítulos anteriores. Pero el segundo es también muy importante. El entorno cambia, y al cambiar, cambian las necesidades y las prioridades. Lo que antes proporcionaba mucho valor ahora es poco. Y nuevas necesidades con un valor altísimo aparecen.

Poder adaptarnos al cambio nos permite enfrentarnos antes a lo que necesita negocio.

No aplicar este principio

A continuación os pongo varios ejemplos claros de respuestas de equipos que no tienen este principio interiorizado:

  • «Acabemos una cosa y luego vamos a otra»: Aquí el equipo reacciona ante un cambio de prioridades. Negocio no suele hacer cambios de prioridad por gusto. Entendamos por qué nos lo pide, y si hay que abandonar una épica para comenzar otra, adelante.
  • «Pero esto es tirar meses de trabajo a la basura»: Lo dicho, la decisión de cambiar no depende de lo invertido, depende de lo que va a costar extra y del valor extra que se espera.
  • «El alcance del sprint está cerrado»: La mayoría de las veces la duración del sprint será menor de lo que está dispuesto esperar negocio. Pero hay ocasiones en las que esto no es así. Si hay cerrar el sprint y empezar otro con un objetivo completamente diferente, se hace. Cegarse en la metodología para no reaccionar al cambio, es restar valor a nuestros clientes.
  • «No puedo ir cambiando de foco todo el rato». El equipo está enfocado en algo. Cambiar de foco y dedicarse a otra cosa tiene un coste. Hay que asegurarse de que negocio entiende ese coste. Pero una vez lo acepta, no debe ser excusa para no hacer el cambio.

Conclusiones

Ya comentamos en el primer principio que la satisfacción del cliente es lo primero. Por mucho que nos pueda molestar, si las prioridades del cliente cambian, las nuestras también. Si lo que necesita el cliente cambia, o si lo que creíamos que el cliente necesitaba resulta ser otra cosa, debemos cambiarlo. Si no, estaremos entregando software sin valor.

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios