4.3 Esto no es agilidad, es fatalidad (I)

Desde hace unos años está muy de moda el desarrollo ágil, que se basa en el desarrollo iterativo e incremental (a diferencia del desarrollo en cascada), donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto. Es decir, en vez de desarrollar todo el proyecto entero de golpe, se va desarrollando de forma incremental, validándolo con el cliente.

Estas metodologías de desarrollo ágil presentan muchas ventajas porque nos permiten desarrollar en ciclos cortos (llamados sprints en Scrum), donde el cliente también participa durante la fase de desarrollo del proyecto, aportando feedback y validando las funcionalidades a medida que se van implementando. Esto hace que introducir cambios no suela ser tan traumático. No es lo mismo tener que hacer cambios cuando ya has terminado que mientras lo estás haciendo. Además, al trabajar en ciclos cortos, evitamos tener que hacer predicciones y estimaciones a largo plazo, en las que asumiríamos demasiados riesgos al tratar de anticiparnos a un futuro cada vez más complejo, incierto y cambiante. Por estos motivos, las metodologías ágiles están ganando popularidad frente al desarrollo en cascada.

Este feedback continuo es muy importante y se convierte en especialmente valioso cuando podemos aprovechar descubrimientos locales para transformarlos en mejoras globales. En esos casos es muy importante documentarlo y comunicarlo al resto para que puedan aprovechar este nuevo conocimiento adquirido a medida que evoluciona el proyecto. Por supuesto, cuando ocurren errores, lo mejor que se puede hacer es detectar por qué han ocurrido, aplicar las medidas correspondientes para evitar que se vuelvan a producir y transmitir también ese conocimiento al resto del equipo. Todo esto en un ciclo que se va retroalimentando, a medida que el proyecto va progresando y la base de código va siendo cada vez mayor y más compleja.

No obstante, un abuso de agilidad puede llevar a la fatalidad. De hecho, una de las situaciones más recurrentes es tener que rehacer lo mismo una y otra vez, con la excusa de que se trata de «desarrollo ágil». Hay que tener presente que no es lo mismo un desarrollo ágil que un desarrollo indisciplinado. A continuación, explicaré algunos de los problemas más recurrentes que me he encontrado, relacionados con clientes y responsables de equipos de desarrollo, y que me han llevado a rehacer lo mismo cien veces como Penélope, la mujer de Ulises, que deshacía durante la noche lo que había hecho durante el día, mientras esperaba la llegada de su marido.

No saben lo que quieren

No saber lo que quieres es una de las peores cosas que te pueden ocurrir en la vida y en proyectos técnicos no es muy diferente. Si vas a pedir algo, pero no sabes qué es lo que quieres, lo que sí tienes que saber es que tienes un problema. Tal y como se suele decir, si no sabes lo que quieres, acabarás en otra parte. Es realmente difícil adivinar lo que quiere o lo que realmente necesita el cliente cuando ni él mismo lo sabe. Esta es una de las situaciones indeseables en las que te puedes encontrar (a la vez que bastante frecuente), ya que la toma de requerimientos para el proyecto puede alargarse mucho y ser extremadamente volátil.

En estos casos, puede ser mejor que te expliquen el problema y que seas tú el que propongas una o varias ideas o posibles soluciones. De este modo das al menos un punto de partida, que puede facilitar muchísimo el inicio del proyecto. Como decía Steve Jobs: «Muchas veces la gente no sabe lo que quiere hasta que se lo enseñas».

No saben expresar lo que quieren

En este caso el cliente sabe lo que quiere, pero le cuesta expresarlo. Esta situación suele ser mejor que la anterior porque el cliente al menos sabe lo que quiere, pero normalmente debido a falta de conocimientos técnicos no lo sabe explicar bien. Aquí es donde una buena toma de requerimientos es fundamental. Tenemos que saber identificar muy bien las historias de usuario, los distintos casos de uso, los escenarios, los actores, etc. En definitiva, se trata de concretar lo abstracto e identificar las reglas de negocio con las que vamos a tener que trabajar.

No entendemos lo que quieren

Este caso se da cuando el cliente expresa lo que quiere, pero no somos capaces de entenderlo, quizás porque parece no tener sentido. Esto puede suceder cuando el cliente cree que sabe de lo que habla, pero confunde tecnologías, metodologías, lenguajes, etc. A veces te pueden llegar a confundir, pero hay que tener claro que este no es su trabajo y no tienen por qué conocer las tecnologías, igual que nosotros podemos no conocer su mercado. Con lo cual, tenemos que saber separar el trigo de la paja y saber interpretar lo que realmente nos quieren decir.

Indudablemente, el hecho de que las personas técnicas encargadas de la toma de requerimientos, diseño, implementación, pruebas, etc., de los sistemas a desarrollar conozcan el negocio de sus clientes es una grandísima ventaja y puede contribuir a facilitar todo el proceso de desarrollo y puesta en producción de las herramientas porque entenderán mucho mejor las necesidades reales. Por ejemplo, si se está desarrollando un sistema para un banco y los técnicos tienen unos mínimos conocimientos del sector financiero, podrán entender mejor el trasfondo de lo que hay que hacer, así como detectar antes los problemas, incoherencias, etc., que puedan surgir. Lamentablemente, esto no siempre es posible y a veces se desarrollan sistemas con reglas de negocio totalmente desconocidas e incluso sin mucho sentido aparente, aunque realmente sí lo tengan. Así pues, es muy recomendable que al menos la persona o personas que interactúen con los clientes conozcan su negocio y sean capaces de entender qué quieren realmente para poder transmitirlo correctamente a las personas encargadas de la implementación.

No podemos o no sabemos plasmar lo que quieren

Esta situación se produce cuando el desarrollo no cumple con lo que quiere el cliente. Es decir, si el cliente ha pedido A le tenemos que ofrecer A y no B. En caso de no ser factible, lo que tenemos que hacer es hablarlo y explicarle los motivos por los cuales no se puede hacer lo que se había planificado. Quizás sea por falta de tiempo, dinero, recursos o porque la tecnología elegida no lo permite.

También cabe la posibilidad de que realmente no sepamos hacerlo porque no tenemos los suficientes conocimientos técnicos. En tal caso, siempre es mejor informar de que no hemos trabajado con esa tecnología, antes que entregar algo que no se corresponda con lo que nos han pedido.

Creen que lo que quieren es trivial o que somos superhéroes

En ocasiones hay gente que, sin tener ni idea, frivoliza con el trabajo de los demás diciendo cosas como: «son solo cuatro cambios», «solo tienes que añadir un botón», «esto lo harás en un momento», «esto es muy fácil», «pensaba que ya lo habrías hecho», etc. Cuando escucho alguna de estas frases mi reacción suele ser la de ponerme en alerta ante un marrón inminente, sobre todo dependiendo de la persona que la diga, del contexto y del tono de voz usado.

Por ejemplo, el hecho de añadir un botón «para que lo haga automáticamente» no significa que la implementación de la funcionalidad también sea automática, sino todo lo contrario, ya que estamos trasladando la complejidad dentro del propio sistema para que el usuario no tenga que hacer ni preocuparse de nada. Aunque lo peor de todo es que, una vez finalizado el esfuerzo titánico para conseguir tenerlo todo listo, te digan: «¿Ves cómo no era para tanto?».

Siempre quieren más cambios

Sin lugar a dudas, la indecisión crónica es uno de los grandes males del desarrollo de software. Es decir, quieren cambiar nuevamente lo que finalmente se había considerado correcto y además hay que hacerlo a la mayor brevedad de tiempo posible, con la excusa de que es importante. A veces se trata de cambios triviales, pero en muchas otras ocasiones no es así.

Suelen ser habituales las modificaciones en las interfaces como: colores, formas, fuentes de letra, iconos, disposición de los elementos en la pantalla, rediseño completo, etc. En otras ocasiones los cambios tienen que ver con la forma de ordenar los elementos de los listados. Por ejemplo, primero te piden ordenarlos alfabéticamente por nombre, luego por apellido, más adelante quieren introducir un campo nuevo y aplicar una lógica de ordenación complicadísima que tenga en cuenta estos tres campos, etc. Por supuesto, también son frecuentes los cambios en la lógica de las aplicaciones, es decir, lo que se supone que deben hacer. Otros ámbitos de cambios frecuentes suelen ser las API, teniendo que añadir, quitar, modificar y renombrar campos, endpoints o parámetros que pueden recibir. Por otro lado, tampoco hay que menospreciar los cambios de opinión acerca de la infraestructura y los procedimientos de despliegue que hay que usar.

En definitiva, cualquier aspecto es susceptible de ser cambiado y es lógico hasta cierto punto porque el proceso de desarrollo de software es algo dinámico. Lo que no debería ser normal es que cambien de opinión y de criterio cada dos por tres, dependiendo de cómo se hayan levantado por la mañana, y se tenga que implementar lo mismo por enésima vez. En ocasiones, los cambios de opinión son debidos a que el peticionario no es capaz de imaginarse el resultado y hasta que no lo ve terminado no se da cuenta de que quería algo diferente o incluso todo lo contrario a lo que había pedido. Sin ninguna duda, estos cambios infinitos pueden contribuir enormemente al retraso de los proyectos, su encarecimiento, al aumento de la deuda técnica y a la desmotivación del equipo.

Quieren (mucho) más de lo que querían

Otra situación muy habitual es aquella en la que se acuerda desarrollar un sistema con un presupuesto determinado, pero a medida que va avanzando el proceso de desarrollo los clientes van pidiendo más y más funcionalidades por el mismo precio. Esto es como si se hubiera presupuestado y diseñado un pequeño apartamento de una habitación, un baño y un salón con cocina abierta, pero te van pidiendo cambios durante su construcción para que acabe siendo un chalé de cuatro habitaciones, dos baños, un salón enorme y una cocina independiente. Por cierto, una vez terminado es probable que te digan: ¿dónde vamos a poner la piscina?

Aunque estén dispuestos a pagar todas estas nuevas funcionalidades no presupuestadas inicialmente, hay que tener muy en cuenta que el diseño y la arquitectura iniciales estaban pensados para un apartamento, no un chalé. Esto puede conllevar muchos problemas técnicos adicionales e incluso un encarecimiento notable del precio final porque va a haber más trabajo para adaptar la arquitectura inicial a los nuevos requerimientos. Gran parte de este esfuerzo extra se podría haber ahorrado si hubieran explicado de antemano lo que realmente necesitaban, en vez de pedirlo poco a poco con la excusa de que solo se trata de añadir algunos botones más.

Por último, relacionado con todo esto, muchas veces nos dicen: «Déjalo preparado por si más adelante queremos ampliarlo»; como si fuera tan fácil como dejar un espacio de la parcela sin edificar para que en un futuro se pueda ampliar la construcción. Sin embargo, a la hora de la verdad, es probable que te pidan una remodelación completa, e incluso quieran añadir una o varias plantas más.

Continuará...