archivo

Archivos diarios: octubre 12, 2013

Uno de los problemas más frecuentes que nos solemos encontrar cuando se realiza una estimación es que en la misma no se tiene en cuenta el tiempo que se necesita para hacer un testing de la funcionalidad implementada, que puede ir desde las pruebas unitarias automatizadas hasta pruebas que se tienen que realizar de manera manual.

Como no se suele tener en cuenta, la estimación de la funcionalidad parte ya con un valor negativo que al final tiene su repercusión económica y/o en la calidad del producto ya que de algún sitio se suele recortar para tratar de cumplir los plazos o para equilibrar el presupuesto.

¿Por qué no se tiene en cuenta? Pues porque la realización de un testing adecuado no se encuentra en la primera línea de pensamiento de quienes realizan la estimación, ya sea el propio equipo de desarrollo o un gestor apoyado o no en ese equipo. ¿Por qué? Porque siempre se piensa en construir, en avanzar rápido, pero se piensa mucho menos en verificar que ese avance es real.

Por tanto, lo que se tiene en mente es el tiempo que se tarda en desarrollar, que puede incluir o no, algunas pruebas básicas, pero no se tiene en cuenta un testing más riguroso, entendiéndose por riguroso, lo que la funcionalidad o el producto necesita realmente.

Este es uno de los principales problemas del desarrollo de software y da igual la metodología o estrategia que estés aplicando.

Los equipos y desarrolladores que saben que la calidad se obtiene en el día a día de tu trabajo y no mediante controles en momentos puntuales del proyecto, funcionan mejor y obtienen, en consecuencia, mejores resultados.

El problema es que se cree que de esta forma se avanza más deprisa pero no deja de ser una ilusión porque si te echan para atrás una entrega en reiteradas ocasiones todo lo que se adelantó se termina convirtiendo en retrasos y no se trata solo de plazos, sino de esfuerzo que se tiene que volver a invertir (más costes).

Tampoco se trata de problemas de índole funcional o de detección de defectos, se trata también de la propia calidad de la arquitectura y del código, de la deuda técnica. La refactorización consigue disminuir esta problemática y es una buena práctica pero lo ideal es que venga acompañada con intención en el desarrollo, es decir, de intentar que el código y las decisiones relacionadas con la arquitectura sea lo mejor posible de serie.

Hablo de mejor posible, no de perfección, hay un camino muy largo entre ambos conceptos, teniendo en cuenta que la perfección en el desarrollo de software no es más que un concepto abstracto y retórico.