1.1.- El Reto - Resolviendo el correcto problema correcto

1.1.- El Reto - Resolviendo el correcto problema correcto

El objetivo del desarrollo de software es apoyar las operaciones y negocios de una organización. Nuestra misión como desarrolladores de software es ayudar a mejorar la eficiencia y rendimiento, que reduce costos operativos y así sucesivamente.

Década atrás , cuando los desarrolladores de software realizaban grandes literaturas en documentación, podemos concluir que la mayoría de las organizaciones podía hacer mucho mejor las tareas de entrega de sistemas que apoyan a sus negocios. En definitiva , estamos construyendo sistemas que no funcionan del todo bien, incluso si estamos escribiendo código que no cumple con las necesidades reales.

A continuación veremos cómo crear código mal escrito para ofrecer una solución al problema de traabajo correcto.

1.1.1 Creación de código mal escrito.

Incluso después de varias décadas de avances en la industria del software, la calidad de software producido sigue siendo un problema. Se debe tener en cuenta que el la vida de un software se somete a tiempo en el mercado, crecimiento en el volumen de software a desarrollar y la corrientes de nuevas tecnologías para absorber, no es de extrañar que el desarrollo de organizaciones de software han seguido para hacer frente a problemas de calidad. Existen dos partes que apoyan a los problemas de calidad: las altas tasas de defectos y la falta de
mantenibilidad.

Lleno de defectos

Los defectos crean costos no deseados, sistemas inestables, imprevisibles, potencialmente o totalmente inutilizable. Esto reduce el valor del software creando más daño. Una forma de deshacerse de los defectos es a través de las pruebas. Comprobamos primero si el software funciona y luego tratamos de que no funcione de alguna manera. En el fondo la prueba actúa como un ingrediente crítico en el desarrollo de software. Tradicionalmente las pruebas se realizan después que el código está en estado congelado. Como ejemplo tenemos que el costo de reparar los defectos, quedan atrapados durante las pruebas no dejando espacio para las mejoras. Si existen defetos no seremos capaces de realizar una entrega. Seremos menos capces de encontrat errores y corregirlos. Encontrar defectos puede ser el problema más obvio con el código mal escrito, y tal código se transforma en una pedasilla para mantener.

Pesadilla para mantener, desarrollado con lentitud

Lo correcto es : un código bien escrito con un buen diseño y requerimientos bien equilibrados , sin duplicación, es lo ideal.
Un código mal escrito no cumple con las características señaladas y se convierte en una pesadilla en muchos aspectos. Uno de ellos es que el código es difícil de comprender y, por tanto, dificil de cambiar. Como si esto no fuera poco, al realizar cambios , éstos afectan a otras funcionalidades del sistema caudando estragos en la duplicación y así la lista es interminable.

La frase "Yo no quiero tocar ese código. Va a tardar una eternidad, y yo no sé qué va a corromper si lo hago."

Este es un problema frecuente y real. Tenemos que ser capaces de construir sobre lo que tenemos, reescribir cada vez que se necesita cambiar un código existente o agregar código nuevo. Esto es lo que tiene que ver con Mantenimiento y es una necesidad cambiante en una empresa. Un código inmantenible nos mueve a ser más lento de lo que nos gustaría y nos conduce a presiones cada vez mayor y dando pié a nuevamente código mal escrito.

Es un círculo vicioso y que debe terminar, si queremos ser capaces de ofrecer un buen servicio, sin considerar cumplir con las necesidades reales que luego hablaremos.

1.1.2 El no poder satisfacer sus necesidades

A nadie le gusta que le vendan un cerdo y se los cambien por dos liebres. Sin embargo, los grupos de desarrollo de software han sido constantemente obligado a hacer precisamente eso a cambio de un pliego de condiciones. Los desarrolladores de software han puesto en marcha la construcción según el pliego de condiciones que se ha descrito, para descubrir que en 12 meses después los requerimientos no coinciden mucho con lo que el cliente prentende. Por no hablar de qué, en un mundo de negocios agitado y que finalmente las necesidades actuales del cliente, son significativamente diferente de lo que estaban en el año pasado.

Como resultado a los constantes incumplimientos reiterados a las necesidades del cliente, se han ideado nuevas formas de dirigir proyectos de software, creando pliego de condiciones más difíciles, que mueven a hacer cosas aún peores, en un tiempo prolongado antes de que el mundo cambie el sistema. Es como armar un castillo de naipes, los pliegos de condiciones pueden bajar el proyecto, construyendo supocisiones en lugar de hipótesis.

Nuestra industria hace que tengamos una pista sombría. Pero esto no debe ser motivo para caer en una depresión total. Existe una cura conocida para estos problemas. El Desarrollo Ágil de Software, incluye 3 métodos como Extreme Programming (XP) y Scrum, ellos representan el antídoto más eficaz que conozco. El resto de esta documentación dará un conocimiento profundo de un ingrediente clave de la agilidad porporcionada por estos métodos, basado en pruebas.