Programacion finalice primero / Done first programming


Agile Programming
Chaos produced by not well managed agile programming

Cuando nos dedicamos a realizar software, se nos mide por la cantidad y calidad de programas terminados que tengamos en nuestro historial, ya sea como desarrolladores individuales o como empresa desarrolladora de software. Si queremos tener buena reputación, debemos tener en nuestra experiencia proyectos culminados de desarrollo en los cuales demostremos que conocemos el ciclo completo para desarrollos de software. De esta forma si es una empresa nueva que empieza a desarrollar, debe hacer el doble de esfuerzo, terminar su primer proyecto y hacerlo bien. Mientras no termine este primer proyecto, siempre va a seguir siendo una empresa novata y no va a lograr tener un alcance de mercado significativo. Recordemos, si no terminamos el software que iniciamos no tendremos buena reputación como desarrolladores de software.

El continuo uso del concepto de programación ágil ha cambiado la mentalidad de los clientes, mientras que la mayoría de las empresas de desarrollo que ofrecen este servicio siguen igual, haciendo internamente una gran cantidad de procesos que anulan la posibilidad de manejo ágil. El manejo ágil sirve para muchos proyectos, pero no todos los proyectos pueden ser manejados de esta forma. Normalmente un proyecto muy grande no puede ser manejado como un “super proyecto ágil” porque no quedaría bien. Lo más cercano sería manejarlo como muchos proyectos ágiles e irlos engranando a medida que se van finalizando, pero cada caso es particular. La experiencia del director de proyecto, el arquitecto, los desarrolladores y los probadores es fundamental para saber como se debe abordar cada caso. Se necesita siempre de un gran equipo para lograr excelentes resultados en cada proyecto. Debe existir una cadena de conocimiento que se aplique a cada proyecto para garantizar su feliz término. Una de mis propuestas como técnica de desarrollo ágil puede ser SAL (Software Assembly Line) / LES (Línea de Ensamblaje de Software)

No importa finalmente si se decida realizar programación ágil o programación no ágil, lo importante es terminar siempre cada proyecto. Basándonos en que el cliente siempre tiene la razón, debemos tener algo con que negociar siempre. Si hay al menos un prototipo, tenemos con que negociar. Así que necesitamos siempre algo tangible para poder tener un patrón de comportamiento a seguir, luego de cada reunión con nuestro cliente. Negociar con base en supuestos genera “incertidumbres infinitas”, mientras que negociar con un “bosquejo”, “prototipo”, etc. puede darnos certezas medibles y “ejecutables”.

Mas vale tener siempre un producto finalizado que se pueda modificar que una gran cantidad de ideas no realizables. Cabe añadir que no nos sirve tampoco tener un prototipo sin haber hablado con el cliente y aterrizado sus requerimientos. Esto si debe permanecer siempre si queremos que nuestro primer prototipo tenga el valor que hará que el cliente se sienta satisfecho.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s