Enseñando trucos nuevos a un perro viejo

Hace algunos días, Miguel Rodríguez hacía esta pregunta en su twitter:

¿Está Rails listo para las empresas? la pregunta correcta es ¿Las Empresas estan lista para el desarrollo AGIL en Rails?

Esto es algo en lo que llevo pensando los últimos meses, no específicamente con Rails, pero sí con el desarrollo ágil en general.

Paradójicamente la industria del software, que debiera adaptarse mejor que cualquier otra industria a los cambios teniendo en cuenta el producto que manufactura, es en cierto modo reticente a los cambios drásticos.
Pero cuando hablo de industria de software me refiero tanto a proveedores como a clientes.

Parece mentira que a día de hoy, sigan existiendo empresas que utilicen el desarrollo en cascada para desarrollar sus proyectos.

Esto está empíricamente probado que no funciona!

Entonces la pregunta que yo me hago es:

¿Qué impulsa a las empresas y a los clientes a usar metodologías viejas y obsoletas, blindarse con contratos de desarrollo y entregas definidas en fechas a priori sin tener especificaciones detalladas o en ocasiones, sin conocer realmente el producto que se desea desarrollar ?
Este tipo de proyectos y contratos suelen acabar en frases como esta por parte del cliente:
«Esto es justo lo que te pedí, pero no es lo que quiero»

El software desde mi humilde punto de vista, es como la materialización digital de una idea.
Pero trabajar con algo tan abstracto como una idea requiere agilidad, adaptación, imaginación… algo que desde mi punto de vista choca frontalmente con reglas fijas, diseños «grabados en piedra», documentos de funcionalidad intocables, etc.

Cualquiera que sepa algo de tecnología, o haya tenido algo de experiencia, por poca que sea, en el desarrollo de software debe saber que el software jamás queda «escrito en piedra», está en su naturaleza mutar, evolucionar (si, algo así como los pokemons) y en general estar sujeto a todo tipo de cambios.

Poco a poco han surgido diferentes metodologías, y frameworks que, una vez comprobado que lo rígido no funciona, han desarrollado una tendencia ágil para desarrollar software.

En general estas metodologías y frameworks, se adaptan en mayor o menor medida al desarrollo en espiral el cual es mucho más flexible en cuanto a incorporar cambios a nuestro producto.


Imagen cortesía de la Wikipedia

En concreto Rails, es un framework ágil para Ruby, uno de los lenguajes que considero que tiene más potencial de cara al futuro (flame wars aparte)

Rails es uno de tantos frameworks (Grails, Spring, Tapestry…) que ayudan a incorporarse en esta nueva tendencia del desarrollo ágil, pero de nada sirve tener un buen framework si no modificamos nuestra mentalidad en cuanto al desarrollo de software.

Documentación sobre desarrollo ágil hay a patadas, Extreme Programming, Scrum son sólo algunos ejemplos de los muchos que se pueden encontrar.

Pero mi punto es que, de nada sirve (o al menos de muy poco) la revolución ágil, si la industria (aka. proveedores y clientes) no cambian hacia lo ágil, y en mi opinión esta es una asignatura pendiente para las grandes corporaciones y en los programadores.

Poco a poco se está demostrando que pequeños grupos de trabajo entregados al desarrollo ágil, con clientes que apuesten por éste y se involucren en el proyecto, resultan mucho más productivos y sus productos mucho más satisfactorios que aquellos gestionados/implementado con viejos estándares, cláusulas, y documentos de funcionalidad «escritos en piedra».

Pasará como con los dinosaurios y las grandes corporaciones de software estarán condenadas a la extinción?

Cambiar hacia lo ágil está lleno de retos, hay q cambiar de mentalidad, eliminar la pereza de modificar las cosas ya realizadas y probadas, adaptarse a los cambios del cliente, e incluso incentivar a éste para que participe, se involucre, pruebe, haga y deshaga…
No hay nada escrito en piedra, todo está sujeto al cambio, es más, el cambio es el motor del mismo desarrollo…

Es la revolución ágil, te apuntas?

5 comentarios en “Enseñando trucos nuevos a un perro viejo

  1. vaya, que interesante se pone este post, casualmente yo estaba discutiendo eso el jueves pasado en mi clase de Gerencia de Proyectos, que hay 2-3 Ingenieros en Sistemas, y como planificar/desarrollar un proyecto que incluye programacion, jo jo creo que me robare el post de alguien para estudiarlo con mas detenimiento y fomentar el debate hehe

    Salu2

    Me gusta

Deja un comentario