Estimación de software y metodologías ágiles (I)

Refelexiones sobre la estimación de los proyectos software y las metodologías ágiles


Estimación de software y metodologías ágiles (I)

Acabo de terminar de leer un artículo de un antiguo compañero sobre estimaciones en proyectos de software utilizando puntos de función y me ha recordado algunas cosas que siempre quise dejar por escrito sobre este tema.

Como diría Jack el Destripador "Vamos por partes" y antes de hablar de estimaciones comencemos hablando de ciclo de vida de un proyecto.

Creo que era Joel Spolsky quien comentaba en uno de sus libros que cuando la informática comenzó a introducirse en las empresas, observó al resto de las ingenierías para ver cómo gestionaban los proyectos. Así nació el ciclo de vida en cascada tan criticado por las tecnologías ágiles.

Imaginemos que estamos en uno de esos cócteles de los 70 reunidos con ingenieros aeronaúticos, ingenieros de caminos y expertos en empresa y que lo único que tenemos es nuestro título en Computación, la promesa de un futuro prometedor y algo de miedo escénico. Uno de los ingenieros reputados nos pregunta ¿y ahora qué vais a hacer ? Y nosotros le respondemos ¿qué hacéis vosotros ?

La contestación, mirándonos sin pudor por encima del hombro, sería algo así como: una vez que nos encargan un proyecto realizamos nuestras mediciones, calculamos cuanto nos va a costar en tiempo y recursos y emitimos una estimación. Una vez aprobada comenzamos a trabajar.

Así, en términos de imitación, nace la metodología en cascada y divide el ciclo de vida de un proyecto en análisis previo, análisis funcional, análisis orgánico, programación y pruebas. A tenor de la verdad, aunque se considera un proceso lineal, el primer gráfico que describe el ciclo de vida en cascada contiene líneas hacia atrás, de modo que, por ejemplo, desde la programación se puede volver al análisis funcional. Lo malo es que estas líneas se perdieron con el tiempo.

El caso es que este es un ciclo de vida acorde con el resto de las ingenierías, pero se ha demostrado inútil en la ingeniería del software.

Si deseamos construir un puente sobre un río medimos su longitud, calculamos el horrmigón necesario, el número de personas adecuado para llevar a cabo el proyecto a tiempo y comenzamos a trabajar

Es muy complicado, en este caso, que las orillas del río se muevan pero incluso podemos prever esto y dejarnos un margen de seguridad de unos cientos de metros. Lo malo en los proyectos informáticos no es sólo que las orillas del río se muevan si no que además es posible que lo que iba a ser un puente para coches necesite un doble perfil para ferrocarril y aceras para peatones y quepa la posibilidad que a mitad de proyecto nos pidan que sea levadizo. Además debemos estimarlo sin ver jamás el río. Ni siquiera sabremos dónde está la mayor parte de las veces. Si me dejan añadir algo: en ocasiones no estamos seguros que vaya a existir un río.

Sabiendo esto nos preparamos para lo peor y creamos metodologías como Métrica que de una forma "fácil" nos proporciona una visión global y estricta de lo que va a representar el proyecto, creamos esquemas UML con todas las funciones, llamadas y módulos de la aplicación, dibujamos diagramas de Gantt, calculamos caminos críticos, evaluamos riesgos, escribimos documentos de calidad y terminamos con toneladas de documentación de solo escritura que nadie va a llegar a leer. Jamás he encontrado un cliente capaz de entender realmente un diagrama de casos de uso y no sólo asentir con la cabeza, por poner un ejemplo.

Lo que intentamos realmente es construir un modelo y caemos en el mismo error de intentar reflejarnos en otras ingenierías. Pongamos el caso de la fabricación de un nuevo avión: diseñamos los planos y construímos una maqueta que pasamos a un túnel de viento para comprobar que nuestro diseño es correcto.

Lo que se nos olvida en esta ocasión es que después de crear nuestro modelo UML no hay ningún túnel de viento en el que probarlo. Lo que olvidamos es que el noventa por ciento de las decisiones que toma un programador en el desarrollo de una aplicación son precisamente decisiones funcionales que afectan al diseño y por tanto al modelo.

Pero dejemos por un momento todos estos prerrequisitos. Ya estamos acostumbrados a saber que nuestros diagramas tendrán que modificarse, contamos con ello. Centrémonos en la estimación.

Y comencemos con la primera falacia: si tenemos 20.000 puntos de función de dificultad media necesitaremos dos años de trabajo con cuatro programadores por X mil cada uno nos da un total de Y mil de presupuesto más imprevistos.

Así llegamos a otra de las particularidades de los proyectos de software: el mes hombre. Por no aburrirnos, digamos que indica el número de puntos de función que un programador puede terminar en un mes. Pero ¿qué programador ?

Cuando hablamos de construir una pared sabemos que un albañil construye veinte metros al día y que un albañil realmente bueno levanta treinta. Es decir, un albañil realmente bueno, trabaja un diez por ciento más rápidamente que un albañil normal.

El libro Fact and fallacies about software engineering refleja que un programador superior a la media trabaja 80 veces más rápido que un programador normal si medimos no sólo el número de puntos de función que escribe si no también el número de errores cometidos y la rapidez con los que se solucionan (coloquialmente: un programador realmente bueno se mete en menos charcos y se moja bastante menos).

Y una vez elegido el programador ¿qué mes ? En The mythical man month , Frederick P. Brooks, indica que los informáticos somos prácticamente los únicos trabajadores no artísticos cuya herramienta principal son las ideas. Fijémonos bien: nuestra herramienta no son en realidad los ordenadores, trabajamos con conceptos y relaciones que plasmamos en un lenguage que un ordenador interpreta, pero nada de lo que hacemos estaba ahí antes: todo ha salido de nuestro pensamiento. Con esta base suponer que un "mes hombre" de digamos enero va a ser exactamente igual que un "mes hombre" pongamos de marzo es, cuanto menos, aventurado.

Y así llegamos al último error de los relacionados con el "hombre mes" (también descrito en el libro anterior, toda una joya de hace más de treinta años, parece imposible que caigamos siempre en los mismos errores): si nuestro puente se retrasa basta con contratar más albañiles, si nuestro proyecto de software se retrasa emplear más programadores posiblemente provocará un retraso aún mayor. Por un par de razones sencillas: tendremos que emplear parte del tiempo de los programadores veteranos en explicar la situación del proyecto y sus decisiones y se aumentarán los flujos de comunicación y por tanto la posibilidad de error.

Y ya que estamos en ello, hablemos de errores: cada año la empresa Standish Group publica lo que se denomina el informe Chaos con estadísticas sobre proyectos de software. La estadística refleja entre otras cosas el número de proyectos acometidos durante el año y el número de proyectos erróneos entendiendo como erróneos aquellos que se han abandonado, los terminados fuera de plazo y los terminados a un precio superior al esperado o eliminando parte de los requisitos iniciales. Alegrémosnos: vamos mejorando. De un valor de casi el noventa por ciento de proyectos erróneos vamos llegando a sólo el treinta motivado sobre todo por mejores herramientas y personal más preparado.

Sin embargo, las razones de estos errores continúan siendo las mismas: mal análisis y mala gestión de los requisitos.

La mala gestión de los requisitos es endémica en nuestro negocio y tiene mucho que ver con la estimación y con la forma de entender al cliente. Eric Evans en su definición de Domain Driven Design habla del lenguage de dominio. Por simplificar, el lenguage de dominio describe el lenguage que habla nuestro cliente o la empresa para la que desarrollamos y prácticamente es diferente para cada empresa. Dado que las empresas de software un día trabajamos para una empresa de alimentación, otro para una farmaceútica, otro para una empresa de transportes... estamos constantemente cambiando de dominio, con conceptos diferentes a menudo expresados por las mismas palabras.

Si a eso añadimos que nosotros tenemos nuestro propio lenguage de dominio y que cada empresa incluso del mismo sector hace de su capa un sayo y trabaja como más le compensa con criterios que van desde la costumbre al porque sí, pretender que un analista aprenda su lenguage y capture todas sus necesidades en un mes es bastante irreal.

Además no es que el cliente no sepa lo que quiere es que el cliente tiene muy claro lo que quiere pero no sabe cómo hacerlo, ni sabe explicárnoslo ni en ocasiones entiende que no sepamos "esas cosas tan básicas" sobre el funcionamiento de su empresa.

Por eso la gestión de los requisitos se convierte en uno de los caballos de Troya más difíciles de abordar en la estimación del proyecto. Y no se hagan ilusiones: los requisitos cambiarán y no porque los clientes nos tengan manía y nos encierren en sótanos, simplemente las empresas cambian, evolucionan junto con el propio proyecto, descubren posibilidades e intentan aprovecharlas. Es lógico, es incluso deseable, pero da al traste con la estimación.

De este modo, un gestor de proyecto debe tener en cuenta que en un futuro las condiciones cambiarán y debe estar preparado para ello, incluso por contrato. Debe avisar al cliente de cualquier cambio que implique una modificación en el ámbito del proyecto y cuanto va a costar tanto en tiempo como en metálico.

Y sobre todo, un gestor de proyecto tiene que estar preparado para decir NO.

Por ejemplo, en uno de mis últimos proyectos tuvimos un problema al integrar una herramienta de generación de listados. Al incorporarla en un formulario los usuarios tenían que pulsar dos veces sobre el botón de imprimir. Era un error de la herramienta, molestaba pero no pasaba de ahí. Un día, uno de los usuarios protestó y sus quejas llegaron a los responsables que decidieron solucionarlo. El resultado fue una semana de trabajo pero conseguimos un botón que en un solo click lanzaba un proceso que enviaba la impresión. Costó mucha investigación, algún dolor de cabeza y miradas incrédulas a la planificación, pero lo conseguimos. El resultado: una semana, dos personas, un total de unos 2.000 euros y un retraso de 80 horas en el resto del proyecto a cambio de evitar un tiempo estimado de veinte minutos al día de un usuario. Lo más curioso es que un mes después, el usuario en cuestión abandonó la empresa para trabajar en otra parte y dos meses después apareció un parche de la herramienta que solucionaba el problema. Todo por no saber decir que no. Cosas veredes.

Volviendo al informe Chaos: una de las cosas que me parece más curiosa y prácticamente es una constante a lo largo de los años, es la que nos indica que el sesenta por ciento de las funcionalidades de un programa se utilizan en raras ocasiones o nunca. Funcionalidades que se han pedido, evaluado, planificado, desarrollado y pagado y nadie jamás va a utilizar. ¿Realmente os extraña que con estos mimbres los proyectos salgan mal ?

Hasta ahora hemos hablado de todo un poco pero aún no hemos dicho nada de metodologías ágiles y de cómo acometen la estimación. Pero es tarde. Discúlpenme y permanezcan atentos a sus pantallas. En breve continuaremos con el tema.

Páginas relacionadas