Si cojemos las practicas de XP vemos que hay muchas cosas que en absoluto son triviales de llevar a cabo. Por ejemplo:

- ¿estamos preparados para decirles a nuestros clientes que vamos ha hacer "planificación ágil" y no darles un presupuesto detallado y firmado antes de comenzar el proyecto?

- ¿estamos preparados para decirles a nuestros clientes que tiene que ser parte activa del desarrollo?.

-¿Realmente vamos a dar más importancia a las personas que a los procesos y contratar sólo a los mejores cualificados que podamos encontrar (sin escatimar en gastos claro) y no a becarios por tres duros?

- ¿En nuestro equipo todo el mundo (o una gran parte del equipo) es experto en areas como el TDD, integración continua, refactorización, patrones de diseño?, y digo EXPERTA, no que les suenen de oidas.

En realidad para poder seguir por ejemplo con todas las practicas del XP se necesita gente altamente cualificada tanto en la gestión del proyecto como en el desarrollo del mismo. Yo veo aqui el principal problema para la adopción de métodologias ágiles, es muy pero que muy dificil encontrar gente lo suficientemente capacitada como para ponerlas en marcha con exito.


Votes: +0

1.- La excelencia técnica de los equipos.
2.- Cultura organizacional más para el talento y menos para el proceso.

Juan Palacio Votes: +0

Por concretar un poco, simplemente mirando un poco alrededor en mi empresa se me ocurren varios puntos por los que integrar XP seria un suicidio:

- Nadie sabe hacer pruebas unitarias, conozco muy pocos programadores (y conozco muchisimos) que sepan hacer pruebas unitarias, diria más, conozco muy pocos programadores que entiendan correctamente que es una prueba unitaria (probar un método de forma aislada usando objetos mock es ciencia ficción para la mayoría).

- Nadie sabe que es integración continua, aqui llevan años compilando dandole al boton del visual basic y mandando por correo el ejecutable que sale. Pasar de esto a un módelo de integración continua es muy dificil. (si ni siquiera usan un control de versiones!!)

- La mayoría de la gente no comprende bien los conceptos de OO. Estos conceptos no son saber que es una clase y una propiedad, estos conceptos son entender que es diseñar clases con bajo acoplamiento y alta cohesion, entender el principio open-close, entender el principio de sustitución de liskov (yo cuando digo cosas de estas en mi curro parece que estoy hablando con guardias urbanos en lugar de con compañeros de profesión porque ni cristo me entiende).

- ¿Refactorización?, ¿cuantos programdores saben lo que esto significa?, ¿cuantos han leido el libro de M. Fowler?, lo mismo si digo el 10% me estoy pasando...

Esto respecto al punto 1, respecto al 2:

- Contratar a un buen analista con experiencia y amplios conocimientos que cobre 8 millones al año (nadie paga eso ya lo se) es infitamente más rentable que contratar 4 recien titulados o con un cursillo de ibm "programar es facil" que cobren 2 millones al año cada uno.

- No se fomenta la formación, esta debería ser una prioridad en una empresa de nuestro sector que avanza tan rapido, pero no, no se hace nada.

Yo realmente creo en las metodologias ágiles y coincido con casi todos sus puntos, pero si me dijeran que mañana empezamos tal proyecto usando XP les diria que si saben contar, pues que conmigo no cuenten, al menos no en un entorno como este. Votes: +0