archivo

Archivo de la etiqueta: no probado pero finalizado

Este antipatrón surge en aquellos casos en los que los desarrolladores (o el equipo de desarrollo) dan por correctas determinadas funcionalidades sin haber pasado el suficiente número de casos de prueba que permitan testearlas teniendo en cuenta diversas casuísticas en los juegos de datos, en la interacción con terceros sistemas o en la propia operativa del usuario.

El testing de fogueo es una de las causas que provocan que un mayor número de defectos se detecten más tarde de lo que debieran, como por ejemplo en la integración con otros módulos, con otros sistemas o incluso en producción.

Aplicando testing de fogueo se obtiene una imagen del estado del proceso de desarrollo que no se corresponde con la realidad, por eso insisto mucho en que las funcionalidades tienen que estar bien probadas porque de lo contrario se crean expectativas en cuanto al avance de los trabajos que pueden provocar que, cuando nos demos cuenta de los problemas, sea demasiado tarde para reaccionar.

No se debe confundir con el antipatrón: “No probado pero finalizado, ya que este tipo de prácticas no son necesariamente provocadas por la necesidad de cumplir unos plazos más o menos complicados, sino que vienen “de serie” con los desarrolladores.

Ya lo decía Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido“.

Un nombre más apropiado me parecería el de “Aceleración con dirección al precipicio”.

Este antipatrón se produce cuando ante la presión del área usuaria o del cliente se toma la decisión de aplicar medidas desesperadas para intentar cumplir plazos prácticamente imposibles:

– Reducir los controles de calidad del software tanto en testing como en la propia calidad del código (deuda técnica), priorizando la ejecución de los trabajos por encima de todo. Esta circunstancia es la que da nombre al antipatrón.

En este caso, en el caso de que se lleguen a cumplir los plazos no será más que un espejismo porque probablemente el producto se encuentre inestable durante un tiempo, sea necesario seguir trabajando en el mismo y lo que se quería tener con tanta urgencia siga sin estar al 100% disponible.

– A lo anterior se le suma en la mayoría de los casos el overtime al que se someterá al equipo de proyecto, que en muchos casos no se tratará de un pico de trabajo puntual, sino que será sostenido durante bastante tiempo. Esto impactará también en la calidad de los resultados y la productividad del equipo, dando lugar a que en ocasiones, algunos de ellos, decidan buscarse otras opciones fuera de la empresa, impactando su marcha en la evolución de los trabajos.

– En otros casos, se recurrirá a meter más personal en el proyecto, produciéndose antipatrones como el de “programador con productividad neta negativa“, “otro programador más“.